Hello all,
I have been using Artix Linux s6 since January and have an issue that I didn't have with Artix Linux runit. Sometimes when updating, my desktop environment disconnects and, I'm not sure if it is technically a crash, brings me back to my DM. This happens whether I use a DM like lightdm, or if I use a console-based one like tbsm. When updating, the screen kicks me out of my desktop environment and shows me the initial TTY that you see when starting the computer from grub.
I'm not sure where to look and diagnose this issue, but it happens frequently enough that I now only update from a TTY where it seems this issue doesn't happen. What I'm worried about most is doing an update and then hurting my system because the terminal that was running the "pacman -Syu" command gets destroyed and failed to finish an update properly. I usually go to /var/log/pacman.log and reupdate/reinstall what I just updated to make sure things were properly installed.
Does anyone have any tips for fixing this or suggestions of where to look to diagnose? Thanks!
A udev/elogind update?
I'm not sure, I haven't seen elogind or udev in the updates that cause the system to stop the X server. I will pay more attention to what is updated next time though and post here.
Is it normal for elogind and/or udev updates to restart things like the X server or DM?
Not so much updates as service restarts, which makes sense.
It's entirely possible that a service restart of elogind or lightdm would cause X to restart. However, this shouldn't actually be happening. I haven't updated those services or any of their dependencies since 2022 (when I change those, I try to make sure this doesn't happen).
If you have a /var/log/pacman.log snippet of an update when a restart happened, we could probably pinpoint what package caused it.
I will update normally until this happens and then I will upload the /etc/pacman.log snippet. Thank you all very much for your help and hopefully I can find an example soon!
Okay, I had the issue happen today after installing a package.
Here (https://pastebin.com/m7f7FdBV) is a pastebin of pacman.log
Is that really the full log? I don't see how anything there could cause this. Not even the udev hook should do it.
/usr/share/libalpm/hooks/30-udev-reload.hook
calls
Exec = /usr/share/libalpm/scripts/udev-hook udev-reload
/usr/share/libalpm/scripts/udev-hook udev-reload
contains
udev-reload)
udevd_live
/usr/bin/udevadm control --reload
/usr/bin/udevadm trigger
/usr/bin/udevadm settle
;;
*)
sudo /usr/bin/udevadm trigger
reliably kills Xorg here.
https://bbs.archlinux.org/viewtopic.php?id=285241
Links to a few bugs etc.
Gist seems to be it's affecting people with evdev entries in their xorg.conf files. Which is me.
This in the Xorg log
I'm just about to try commenting out the entries but I'll post now lest I kill X and lose what I've written.....
Edit:
Well there you go silly me.
I had evdev liberally splattered throughout xorg conf files that have followed me around for years (I use a separate layout for triple screen gaming so do need them).
And I didn't have xf86-input-evdev installed!
Installed it and the problem seems to be gone.
Interesting find. If OP has that issue too, then in that case s6 isn't relevant at all and just a weird red herring.
Yeah I'd be surprised if S6 is relevant? It just happened to be the init OP uses. I'm fairly confident our problems are/were related.
It kicked in for me a good few days after I saw the first post above about it. But I'd done no updates for quite a while as I put them off waiting to see how the repo merging was going to pan out. Which was very well it seems.
Unfortunately, yes this is the full log of installing the package and bringing my xorg down.
As far as what gripped is saying, I did have success in bringing down xorg by running "sudo /usr/bin/udevadm trigger", but I could only do it once interestingly. It seems like it only happens sometimes when it's ran. Interestingly, I don't have that same error that gripped had in their Xorg log. I also don't really have any Xorg config files in my home directory (or at least, not that I know of).
EDIT: After reading what happened with https://bbs.archlinux.org/viewtopic.php?id=285369, I do have two files (/usr/share/X11/xorg.conf.d/10-evdev.conf and /usr/share/X11/xorg.conf.d/10-quirks.conf) that reference evdev.
Maybe should I try to delete these files and see what happens? I can make backups before doing that.
"10-quirks.conf" is a default file. That shouldn't be causing any problems. You can try getting rid of the 10-evdev.conf one. No idea where that came from.
In case it's not clear, "udevadm trigger" isn't supposed to crash xorg. :P
Okay, I have moved it to a backups folder in case I need it back for any reason. I will keep updating and see if I still find an xorg crash. Thanks for the help!
If you try running
sudo /usr/bin/udevadm trigger
multiple times and there is no crash you should be good.
If you want to be cautious then another alternative to switching to a tty to update is to do the update in a tmux session tmux (https://wiki.archlinux.org/title/Tmux). Then if X dies the update keeps running. That's what I started doing once the issue started.
Okay, I'm still having the issue after moving the file. This (https://pastebin.com/568PCsHt) was the update log.
Maybe I can just update in gnu screen, tmux, or a new tty for now on, but it would be good to know why. I'll keep digging!
This suggests that it's the "update-desktop-database.hook" that's actually causing it. That was the same entry that was last in the log as last time. All that hook does is execute "/usr/bin/update-desktop-database --quiet". I don't know how this could be restarting X but that would be my guess at this point.
Edit: alternatively, I suppose the dbus-reload.hook hook is another possibility? All that does is this:
dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig > /dev/null
See if either of those commands crash X for you I suppose.
It looks like these commands exit just fine. However, that "udevadm trigger" command run as root crashes my Xorg session pretty frequently when ran.
Okay that's weird. The udev-reload hook goes off in the newest log of yours but pretty early. I wouldn't have expected you to be able to rebuild the initramfs afterwards. Sadly, I don't have an answer for you on the udevadm trigger thing but at least you know the problem. As a workaround, one could comment out the line in /usr/share/libalpm/scripts/udev-hook.
Where is the backup folder ?
Run this command again and post the output
grep -R evdev /{etc,usr/share}/X11/xorg.conf*What other (if any) .conf files are in /etc/X11/xorg.conf.d/ ?
Preferably post the contents
Thanks so much for your help anyways! :) I need to look into what that command even does. Is it anything super important?
The backup folder is in "/home/brandon/backups/10-evdev.conf".
Output of "grep -R evdev /{etc,usr/share}/X11/xorg.conf*":
$ grep -R evdev /{etc,usr/share}/X11/xorg.conf*
/usr/share/X11/xorg.conf.d/10-quirks.conf:# Explicitly tell evdev to not ignore the absolute axes.
/usr/share/X11/xorg.conf.d/10-quirks.conf: MatchDriver "evdev"
/usr/share/X11/xorg.conf.d/10-quirks.conf: MatchDriver "evdev"Here (https://pastebin.com/VGieztny) are all of the files in that location from the grep command. I cat'ed them all together with the filename and colon showing you what file they are from.
This is just a hunch but it goes like this:
The various Arch forum threads and bug reports I linked to before did say, along the lines of, that if evdev was in the xorg .conf files but not installed on the system
/usr/bin/udevadm trigger
would kill X
You do have evdev in the .conf files. If we look at my most recent Xorg.0.log we can see
As a test you could move /usr/share/X11/xorg.conf.d/10-quirks.conf to /usr/share/X11/xorg.conf.d/10-quirks.conf.bak
Restart X and try to crash with
/usr/bin/udevadm trigger
Or you could just install xf86-input-evdev and see if the issue goes away.
(The reason I picked evdev over libinput long ago is you got more fine-grained control over your mouse setting in the KDE settings. This thread (https://bbs.archlinux.org/viewtopic.php?id=240218) shows what I mean.
Whether it's still true or relevant I'm not sure and too be honest I struggled to remember why I'd done it. I must have needed it for something at the time.)
The thing that makes me doubt my hunch is that /usr/share/X11/xorg.conf.d/10-quirks.conf is installed by xorg-server so everyone with X has the file so I'd expect many more people to be suffering the issue. But it seems they are not.