From ArchWiki

propose to add to automatic startx

When combine automatic startx + automatic login to console, it may come to infinite loop/crash if (a) ~/.xinitrc goes wrong somewhere, after editing; or (b) after pacman -Syyu and Xorg crash. I propose to check if the last GUI session (startx session) really last long before start a new one.

if [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]]; then
	if [[ -f /tmp/login-check-startx.flag ]]; then
		rm /tmp/login-check-startx.flag
		echo -e "\nFile '/tmp/login-check-startx.flag' found, maybe the last GUI session did not last long!\n"
		## do nothing, start automatic console login
		touch /tmp/login-check-startx.flag
		( sleep 120; rm /tmp/login-check-startx.flag ) &
		exec startx
## Change '/tmp/login-check-startx.flag' to '$HOME/login-check-startx.flag' if you want that check also valid after reboot.

Triplc (talk) 20:42, 20 April 2016 (UTC)

You might do that without the temporary file by simply looking at the age of the log file:
if [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]]; then
	if [[ ! -e ~/.local/share/xorg/Xorg.0.log || $(find ~/.local/share/xorg/Xorg.0.log -mmin +2) != "" ]]; then
		exec startx
Or even more simply, don't exec startx, check its return code and drop to interactive shell on errors:
if [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]]; then
	startx && exit
-- Lahwaacz (talk) 21:10, 20 April 2016 (UTC)
Thanks Lahwaacz. But (a) so the age of a file is based on it's creation time, not update time. OK, i did not know that. (b) about the startx exit code, i am not sure that it will correctly set if i edit something wrong in ~/.xinitrc which make GUI session crash
I just tried to change the resolution of X (xrandr...) and ~/.local/share/xorg/Xorg.0.log updated and get the new timestamp Triplc (talk) 21:36, 20 April 2016 (UTC)


there are 2 xinit examples which by themselves do not work as laid out, imo they should be removed and instead an optional note could be put (somewhere) that says something like:

xinit can be executed instead of startx if you know what options to use

otherwise it seems frustrating to recommend examples which will obviously fail --Ubone (talk) 02:29, 12 November 2018 (UTC)

xinit would not obviously fail if you specified the options in xserverrc. If you already have an X server started, you should also pass the :display_number option mentioned in the note after the first example. -- Lahwaacz (talk) 07:35, 12 November 2018 (UTC)
then replace or in #Usage with or if #xserverrc is configured: ? --Ubone (talk) 08:10, 12 November 2018 (UTC)
I think it should be worded in a way to make it clear why xserverrc is relevant, after all the right options can be specified on the command line as well. -- Lahwaacz (talk) 22:04, 12 November 2018 (UTC)

Add `export DESKTOP_SESSION=something` to ~/.xinitrc

I have had issues previously described here:

In summary, and how to reproduce:

  1. sudo pacman -S xorg-xinit plasma deepin
  2. follow the wiki's instructions to set up ~/.xinitrc, e.g. below

# merge in defaults and keymaps
if [ -f $sysresources ]; then
    xrdb -merge $sysresources
if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"
if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
# start some nice programs
if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 unset f
exec startplasma-x11

I observed the following glitches:

  • the command startplasma-x11 leads to /usr/lib/deepin-daemon/dde-system-daemon being forked off of system dbus.service
  • less important but, kvantum themes do not apply to autostarted X apps.

However these problems do not occur when starting KDE Plasma from gdm. I used printenv to track differences.

If you add the line export DESKTOP_SESSION=plasma before exec startplasma-x11 in ~/.xinitrc, KDE loads correctly (without deepin processes in the background and themes correctly applied to autostarted applications).

Maybe we should add export DESKTOP_SESSION=desktop_environment to the wiki instructions?

Jennydaman (talk) 18:47, 29 June 2020 (UTC)

I don't think it's an issue with other desktop environments, so add it to KDE#From the console instead. -- Lahwaacz (talk) 08:38, 30 June 2020 (UTC)
you don't need .xinitrc to start a de/wm -- Ubone (talk) 06:21, 5 July 2020 (UTC)

xinitrc.d scripts tip

Hmm as @Alad pointed out by the consideration of removal, I haven't thought about the .xinitrc actually being user content. I kind of thought about the way scripts are sourced as somewhat standard, even though there should really not be such expectation (even if it were kind of nice).

However I think it may be useful to somehow explain that the 'default implementation (on Arch?)' does source only executable files. Or I'm not sure. It just confused me that the x permission would be required, since the source command in bash does not require the file to be executable. Maybe there's a bigger reason behind this behaviour in the default .xinitrc - or maybe it shouldn't be like this, I'm not sure how other programs implement .d/ folders.

Feel free to delete this or improve on this, it was just a quick idea how to maybe save someone a while - but maybe it's too big of a headache and not that important.

I don't know how to rewrite what I added, again, feel free to moderate this.

Jsmetana (talk) 21:39, 7 December 2021 (UTC)

I am confused as to why it's giving you trouble with non-executable files. It should be using the . builtin, which does not require the file to be executable. As for the shebang, that is useful information but I'm not sure if it belongs here - there are surely other places in the wiki that have the user write scripts, without mentioning it. :) - CodingKoopa (talk) 02:13, 9 December 2021 (UTC)

Should the article explicitly mention more security considerations?

Quoting an answer to Xephyr -ac dangerously?

This also applies to any X server, not just Xephyr

Which is why I find it relevant for this talk page.

I haven't looked at how different display managers are starting X. Since a display manager is not mandatory, and some users can manage a multi user machine, I wonder if the xinit article should not have more pointers to security considerations. Regid (talk) 07:28, 6 April 2022 (UTC)