From ArchWiki

Running "Notes" Section

The two sets of notes at the bottom of xinitrc#Configuration should be condensed in some way. The first five bullet points all concern which tty X is running on. I could create this as its own subsection, and contain the information there, though I am not entirely convinced that this is necessary/appropriate/needed on this page at all. Would it be more appropriate to merge the relevant sections into the Xorg article, perhaps? Pid1 (talk) 00:30, 26 July 2015 (UTC)

First of all, the first 4 points are inaccurate. Back in 2013, this was indeed handled by the default /etc/X11/xinit/xserverrc, which contained
if [ -z "$XDG_VTNR" ]; then
  exec /usr/bin/X -nolisten tcp "$@"
  exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR
Now it contains only
exec /usr/bin/X -nolisten tcp "$@"
This will be more work than it seemed, we should investigate... Nevertheless, startx handles the vt parameter, but plain xinit doesn't, so I'd say the note is perfectly suitable for this page.
-- Lahwaacz (talk) 08:17, 26 July 2015 (UTC)
Thanks for the insights. I will cross-reference the documentation with what is provided here, and update accordingly. Pid1 (talk) 13:01, 26 July 2015 (UTC)
I've split this off into a new Running section. I think this section should be split into startx and xinit subsections and explain the details of using xinit in a way that is not a block of notes Ziusudra (talk) 00:19, 11 February 2016 (UTC)
I think this discussion has come to an end. It refers to old content. There were many edits through out the years, some of which are its results. Following Help:Discussion#Closing_a_discussion. Regid (talk) 06:48, 6 April 2022 (UTC)

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)

xorg-xinit and inetutils dependency

As of September 2020 xorg-xinit providing the binaries startx and xinit stil depend on the package "inetutils"

pacman -Si xorg-xinit

Depends On      : libx11  xorg-xauth  xorg-xrdb  xorg-xmodmap  inetutils

This is because it needs "hostname" as I understand it,

Closed by  Jan de Groot (JGC)
Monday, 19 December 2011, 11:59 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in svn. Preparing a new package at this moment, so   should be in repos soon.

This is from 2011. So this "new package ... so should be in repos soon, apparently never happened.

I'm a bit confused. Shouldnt this information be in the wiki ? Or a note or alternative of using sx for example ?

eschwartz: ...Use instead, it's available in [community].. 
Trilby: ...I also agree with ESchwartz that xinit code is a mess (and startx more so).

Try sx, in my sxrc I just source .xinitrc.

M040601 (talk) 10:28, 15 September 2020 (UTC)

It happened, see [1]. Every newer version of the package released to the binary repository includes the dependency. -- Lahwaacz (talk) 11:08, 15 September 2020 (UTC)
What I meant by "never happened" was, the removal of that dependency. That is I was expecting xorg-xinit was gonna be built without depending on inetutils. Using something other from some other package for the needed hostname. Because that dependency is the security risk right ? Whatever the case, doesn't it make sense, in this same wiki page, to add an additional note or warning mentioning this and clarifying some concern an uninformed user might have ? Put yourself in a position of someone running arch-audit. The user is confronted with the warning "high-risk" word, associated with "inetutils", and ends up tracing it to xorg-xinit. Additionally, a note, mentioning "... an alternative to xorg-xinit is sx ...." M040601 (talk) 04:23, 16 September 2020 (UTC)
The FS#24811 was not about removing the dependency, but adding the dependency to the package metadata. The use of hostname is not insecure - the reason why people consider inetutils insecure is rsh, telnet etc. which work with an insecure protocol.
Anyway, the call to hostname can be replaced with uname -n, but startx uses hostname -f. How would you replace that?
-- Lahwaacz (talk) 07:06, 16 September 2020 (UTC)
No follow-up, closing. -- Alad (talk) 10:22, 6 April 2022 (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)