[SOLVED] Intermittent startx failure

Platokrasi · Yesterday 21:06:51

[SOLVED] xauth: timeout in locking authority file when starting X with startx

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.

~/.Xauthority has the correct ownership and permissions and is mode 600 and owned by my user.
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.
There is no pam_xauth configuration.
There is only one startx invocation in my login configuration.
There are no other configured xauth calls in my autostart or systemd user files.
There is no xauth, xinit, or startx core dump in coredumpctl.
The i915 module is already included in my normal kernel initramfs.
The kernel log from a previous successful boot showed normal i915 initialization and no GPU hang, reset, or DRM failure.

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 this?

UPDATE / SOLVED:

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. 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.

Last edited by Platokrasi (Today 01:03:29)

seth · Today 06:52:38

This fits a pattern of DMs running into the same situation because systemd advances to the graphical target as regardless of any drm devices being setup/ready.
Make sure you've https://wiki.archlinux.org/title/Kernel … _KMS_start setup and then just artificially delay startx for 1-3s

If you want to try and if this isn't a hybrid graphics system you could try to block the simpledrm device: add "initcall_blacklist=simpledrm_platform_driver_init" XOR "initcall_blacklist=sysfb_init" to the https://wiki.archlinux.org/title/Kernel_parameters
(I suspect that systemd just accepts that as drm device but it gets voided and replaced by the real one and then you fall through the cracks)

Arch Linux

#1 Yesterday 21:06:51

[SOLVED] Intermittent startx failure

#2 Today 06:52:38

Re: [SOLVED] Intermittent startx failure

Board footer