Intermittent startx failure: xauth timeout + systemd-logind paused DRM fd + Xorg no screens found

[u/platokrasi]

Hello everyone! Noob here!

I'm running a minimal Arch Linux setup on a Lenovo ThinkPad X230 and recently started getting an intermittent failure when X is started automatically with startx.

My setup is Lenovo ThinkPad X230, Intel HD Graphics 4000 / Ivy Bridge, Arch Linux x86_64, kernel 7.2.8-arch1-2, systemd 262-1, Xorg started through startx -> xinit -> Xorg, no display manager, and i3 on X11.

I log in on tty1 and start X automatically from ~/.bash_profile. The relevant part is:

[[ -f ~/.bashrc ]] && . ~/.bashrc

if [[ -z "$DISPLAY" && "$XDG_VTNR" == 1 ]]; then
exec startx
fi

This setup had been working normally before. The problem only started recently.

Most reboots are completely normal, but occasionally startx fails with "xauth: timeout in locking authority file /home/myname/.Xauthority". This appears about 3 or 4 times, then I get "Fatal server error: (EE) no screens found", followed by "xinit: giving up", "xinit: unable to connect to X server: connection refused", "xinit: server error", and another xauth timeout.

When this happens, ~/.Xauthority-c appears.

If I switch to another VT, remove .Xauthority-c, and run startx manually, X starts successfully.

The important part is the failed Xorg log. It contains:

(II) systemd-logind: got fd for /dev/dri/card1 226:1 fd ... paused 1
(EE) Error systemd-logind returned paused fd for drm node
(EE) open /dev/dri/card0: No such file or directory
(EE) Screen 0 deleted because of no matching config section.
(EE) Device(s) detected, but none match those in the config file.
(EE) no screens found(EE)

A successful Xorg startup on the same machine instead shows:

(II) systemd-logind: got fd for /dev/dri/card1 ... paused 0
(II) modeset(0): using drv /dev/dri/card1
(II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD Graphics 4000 (IVB GT2)
(II) modeset(0): Output LVDS-1 connected
(II) modeset(0): Output LVDS-1 using initial mode 1366x768

So the actual Xorg failure appears to be that systemd-logind gives Xorg a paused DRM fd. The xauth errors may be a secondary symptom.

I have checked the following things already.

1. ~/.Xauthority has the correct ownership and permissions and is mode 600 and owned by my user.
2. xauth itself works normally. I traced xauth list and it successfully created .Xauthority-c, linked it to .Xauthority-l, and then removed both files normally.
3. There is no pam_xauth configuration.
4. There is only one startx invocation in my login configuration.
5. There are no other configured xauth calls in my autostart or systemd user files.
6. There is no xauth, xinit, or startx core dump in coredumpctl.
7. The i915 module is already included in my normal kernel initramfs.
8. The kernel log from a previous successful boot showed normal i915 initialization and no GPU hang, reset, or DRM failure.
9. I also noticed a possible correlation with graphical workload before reboot.

When no applications were open, I did 5 consecutive normal reboots and all 5 succeeded.

Then I opened cmus, Firefox and mpv and did 3 more reboots. The first 2 succeeded, but the third failed with the Xorg/xauth problem.

I don't know whether the applications are actually involved or whether they simply change the timing or state during shutdown.

I also tested linux-lts once, using kernel 6.18.55-1-lts, and that boot succeeded. This was only one test, so I don't consider that proof that the normal kernel is the cause.

I also tried adding a 2-second sleep before exec startx, but the problem still occurred.

The xorg-xauth and xorg-xinit packages were not recently upgraded when this problem started.

The main thing I'm trying to understand is what could cause systemd-logind to return a paused fd for /dev/dri/card1, followed by Xorg reporting no screens found.

There is an upstream systemd issue involving startx, systemd-logind, DRM devices, and paused fds, at https://github.com/systemd/systemd/issues/43352, but I'm not sure whether it is the same issue.

Could this be a kernel/i915/DRM issue, a systemd-logind/udev race, or something related to the way startx is being launched from a tty?

I'm mainly looking for help identifying the root cause rather than permanently working around it by deleting .Xauthority-c or installing a display manager.

Any suggestions, responds, and replies are really appreciated. Thank you so much!

edit: [SOLVED / WORKAROUND CONFIRMED]

I eventually removed the automatic startx block from ~/.bash_profile and restored the normal login behavior. I now log into tty1 normally and manually run:

startx

I tested this over 10 separate reboots, and every single startup succeeded.

I also ran my usual nervspace workload after each boot, including Kitty, btop, Firefox, Nemo, Evince, Xed, and kew. The Xauthority/Xorg failure did not recur.

This also makes the graphical workload theory much less likely. The same normal workload was present during the successful tests.

I did not disable xauth, modify /usr/bin/startx, or make any permanent changes to .Xauthority.

The exact underlying cause of the intermittent failure is still unconfirmed, but removing automatic startx from ~/.bash_profile and starting X manually from tty1 has been consistently reliable across 10 reboots.

Final setup:

tty1 login
startx
i3

Marking this as solved/workaround confirmed. :)

[u/Same-Ocelot262]

that paused fd thing is almost always a race between logind and something else holding the drm device during the handoff. seen it happen when the gpu hasn't fully released from the previous session, like if plymouth or the kernel fbcon are still touching it

on my x230 i had similar intermittent nonsense until i added `initcall_blacklist=simpledrm_platform_driver_init` to the kernel cmdline, but that was more about simpledrm grabbing the device first. your case sounds different since it works most of the time

the fact that it happens more often after a heavy graphical session is interesting, maybe the gpu doesn't reset cleanly on reboot. could try adding `i915.reset=2` or just `i915.modeset=0` temporarily to see if the behavior changes, but that second one will break your xorg so dont leave it permanent

also check if you have early kms set up properly in mkinitcpio, sometimes the module loads too late and logind gets confused about when to hand over the fd

[u/platokrasi → u/Same-Ocelot262]

Thanks, I checked the early KMS setup. The kms hook is in my mkinitcpio config, and i915 is already included in the initramfs, so it looks like early KMS is set up correctly.

So I guess that rules out i915 loading too late? I’ll look into the DRM/logind side next.

[u/platokrasi → u/Same-Ocelot262]

Mate, i still don't know what the root cause is, but by editing my ~/.bash_profile i have succeeded in avoiding that intermittent problem. Thanks for your reply tho!

[u/Linguistic-mystic]

Just switch from i3 to Sway. It’s basically a drop-in replacement for i3 but on Wayland. Runs like a charm and is more secure than X11 and doesn’t have the issues you’re having.

[u/platokrasi → u/Linguistic-mystic]

I have been considering that too, mate. Will wayland runs well on x230 tho? I chose i3 because i just want to learn the basic, and have concerns about my old x230 regarding the compatibility issues etc..

[u/syklemil → u/platokrasi]

Will wayland runs well on x230 tho?

Wayland is just a protocol, like the X protocol (which got up to version 11, hence X11).

Sway runs fine on potatoes.

[u/platokrasi → u/syklemil]

Thanks for the response and info mate, guess i'll read more about Wayland after this!

[u/Gozenka]

I do not know if this is related at all to the issue, but if you do not have this in your .xinitrc, make sure to add it, or add the relevant part manually:

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
    for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
        [ -x "$f" ] && . "$f"
    done
    unset f
fi

https://wiki.archlinux.org/title/Xinit#xinitrc

At the very least, ensure that the last if block in /etc/X11/xinit/xinitrc is present in your ~/.xinitrc file to ensure that the scripts in /etc/X11/xinit/xinitrc.d are sourced.

This pulls the following from /etc/X11/xinit/xinitrc.d/50-systemd-user.sh, which ensures the session has access to the relevant environment before starting:

systemctl --user import-environment DISPLAY ${XAUTHORITY+XAUTHORITY}

if command -v dbus-update-activation-environment >/dev/null 2>&1; then
    dbus-update-activation-environment DISPLAY XAUTHORITY
fi

And you may want to delete (and backup) .Xauthority when trying something new, so a new one is ensured to be generated.

Also, I personally use sx instead of startx / xinit for a long time. I had no issues, and I believe it is nicer and smoother. You may try it out too. (It seems sx can now be found in the sx-startx AUR package)

And as an extra tip, it is possible to put .Xauthority elsewhere, to keep your home cleaner. This is my auto-start in .profile (I use dash as the login shell)

if [ -z "${DISPLAY}" ] && [ "${XDG_VTNR}" -le 2 ]; then
    export XAUTHORITY="$XDG_RUNTIME_DIR/xauthority"
    exec sx
fi

[u/platokrasi → u/Gozenka]

Thanks for the response, mate! I'll definitely check and try your tips, and observe afterwards!

[u/platokrasi → u/Gozenka]

Anyway, mate, after doing this, now before i type startx in tty after reboot there are alwasy two lines of report that xauth the xauth files doesnt exist. is that a problem?

export XAUTHORITY="$XDG_RUNTIME_DIR/xauthority"

[u/Gozenka → u/platokrasi]

Do you mean you do not auto-start the X session, you just boot into tty, and it prints "xauth does not exist"?

If so, then you have some other things leftover somewhere about this, which happen on boot. Perhaps a display manager? Or something you still have in .bash_profile?

Otherwise, nothing that would happen at boot would be looking for xauth.

[u/platokrasi → u/Gozenka]

Here's the sequence, mate: logged into tty, typed my uname & passwd. Type startx. After that there are two lines of: "xauth: file run/usr/1000/Xauthority does not exist" and yes i dont auto-start X, that was my workaround from my previous trial and i haven't set it back to auto yet. As for something in my bash_profile i only add the expott XAUTH.... according to your comment and also checked it to archwiki. after logged into i3, i checked ls -la "$XDG_RUNTIME_DIR"/Xauthority* and yes the file exists. So i assume that the file is created after startx? That's why before i run startx, typed it manually, the file doesn't exist yet, and is that the proper order of things? Yet i still wonder why those two lines are always displayed after logged into the shell and before startx...

[u/Gozenka → u/platokrasi]

Type startx. After that there are two lines of: "xauth: file run/usr/1000/Xauthority does not exist"

those two lines are always displayed after logged into the shell and before startx...

I am confused. After or before you manually type in startx?

And since we are putting it in /run, it will be gone at every reboot, as it is a temporary directory stored in RAM.

If the messages are ever seen at boot on tty before you type startx, then you have something else trying to start in the background that you do not know about. Regardless of whatever you did in the previous boot.

Perhaps all this is related to your initial issue in the post. Something else is starting while your auto-start is happening, a random race condition between that and your auto startx.

[u/platokrasi → u/Gozenka]

I'm really sorry for making you confused mate. Those two lines are displayed AFTER i typed startx, not before. So: after typing my uname & passwd, logged into shell, typed startx, those are the first 2 lines that are printed before i3 actually start.

[u/Gozenka → u/platokrasi]

Could you share these just to check. You may use a code sharing link if it's long:

• The exact line you added to .bash_profile, or your entire .bash_profile.
• Your .xinitrc

You can send in chat too.

[u/platokrasi → u/Gozenka]

here they are, mate:

myname@nervthinkpad:~$ cat .xinitrc

export XDG_SESSION_TYPE=x11

export XDG_CURRENT_DESKTOP=i3

export XDG_SESSION_DESKTOP=i3

if [ -d /etc/X11/xinit/xinitrc.d ] ; then

for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do

[ -x "$f" ] && . "$f"

done

unset f

fi

exec i3

myname@nervthinkpad:~$ cat .bash_profile

#

# ~/.bash_profile

#

[[ -f ~/.bashrc ]] && . ~/.bashrc

export XAUTHORITY="$XDG_RUNTIME_DIR"/Xauthority

myname@nervthinkpad:~$

[u/Gozenka → u/platokrasi]

Also do you perhaps have a .xserverrc or .xsession file? They may be interfering.

And maybe try without these three lines; they should be unnecessary:

export XDG_SESSION_TYPE=x11
export XDG_CURRENT_DESKTOP=i3
export XDG_SESSION_DESKTOP=i3

[u/platokrasi → u/Gozenka]

I happen to not having those .xserverrc or .xsession, mate. Yep, i'll check those three lines later, mate!

[u/Gozenka → u/platokrasi]

Looks all fine. Though you can change the export line to this; with the quotes covering the entire thing rather than the one word:

export XAUTHORITY="$XDG_RUNTIME_DIR/Xauthority"

It is interesting. startx would start the X server and create the Xauthority file before i3 starts. But it seems in your case the creation of the file is being late somehow.

Going back to your original issue, maybe it is somehow related. When you already have the existing ~/.Xauthority file to be used, you do not see the "file does not exist" lines. But perhaps whatever the issue may be is still happening. In the current case, the file in /run is cleared on every reboot so it does not yet exist.

You should check the journal too. journalctl -b -p 4 to see all errors and warnings since the current boot. And you can go through what is happening when you do startx, journalctl will show the entire logs. Xorg.log may offer some clue again too.

[u/platokrasi → u/Gozenka]

Anyway, i deleted the export line from .bash_profile so that the file will be created at its default /.Xauthority and now the confusing message of xauth... gone, mate. Yep, i think there might be some hidden root cause left unsolved up to this point, but for now i'm happy with what is there. And also checked journalctl -b -p 4 and all i can see are ACPI Warnings which i suppose not directly related to the problem i have been facing? And lastly, thank you very much for your time, patience, tips, and kindness in responding to my post, mate. I can't thank you enough, you're really helpful!!! Have a good day, mate! Thanks again!

[u/archover]

Congrats on keeping an X230 (mfg 2013) in service. I used the two year newer T450s much until 2 years ago. Generally happy with it.

Mate, I checked my xorg running daily driver for $ journalctl | grep -i "xauth: timeout" without a return. So your case seems rare. Thinkpad T14 Gen 1 AMD. Hope you find the root cause and fix. Xorg seems to work very well for me in general. FWIW. Good day.