Install/Update some packages forcefully restart user session [Solved]

sipak · 2025-08-07 04:21:55

Hi,

Updating certain packages such as dolphin or gnome-keyring forcefully restarts SDDM.
I have inspected the source of these packages and do not see anything in them doing the forceful restart. I cannot find a scriptlet doing it either.

Question: Is this something happening just to me? (I hope so). Or something somebody decided it was a good idea to implement?

Yes, yes, I can see you typing "duh! you shall always update from tty, derp!" and you are absolutely right. But come on... that is purist, and in like 13 years using Arch such a thing has never been necessary.
Yes yes, one should update from TTY, but such behavior causes the pacman installation to break as the terminal gets killed, and one has to go to delete the lock file. Risking to delete all of /var/lib/pacman by mistake. Which is what happened to me. And no, I am not a newb. And yes, I already said that I agree that ideally one should update from tty. And no, mockery is not going to help. But practicity > purity. If we were to make purity king, lets replace systemd with openrc, and take nvidia and other things tainting kernel out of official repos, etc.

Worse, it seems to do that even on installation. Pretty unpractical to expect users to close everything and switch to tty to install everything just in case that thing restarts their graphical session.

So, I do hope this is just something that happens to me.

Last edited by sipak (2025-08-08 07:15:54)

seth · 2025-08-07 07:35:46

Possibly https://bugs.archlinux.org/task/77789

sudo touch /etc/systemd/do-not-udevadm-trigger-on-update

In the past this has been caused by stale X11 driver references (evdev), please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General

Edit: if this is not it, you'll likely still see the actually crashing process + a core dump showing up in the system journal afterwards.
Or see https://wiki.archlinux.org/title/Core_d … _core_dump

Last edited by seth (2025-08-07 07:36:40)

sipak · 2025-08-07 07:55:49

Could you confirm that installing/updating these packages do not trigger a session restart on your side? So that I know if to look for a problem in some implementation, or something specific to my system. I currently don't have another system to test on.

I don't use X. Wayland only. Since wayland is just a compositor, it is not itself that manages the session. The session restart comes from something else. Some trigger somewhere.

touch do-not-udevadm-trigger-on-update changed nothing. Legacy option? And it seems to be related to hardware events.

I am noticing that many packages trigger this. I just reinstalled yubikey-personalization-gui and got kicked from session :s
Also, weird, on every session restart, the default display sink is moved to another tty. Originally, graphic session was on tty1, after first restart got moved to tty5, then tty6, then tty7.
dmesg shows absolutely nothing relevant, but journalctl shows:

systemd[1]: Stopping User Manager for UID 973...
systemd[218473]: Activating special unit Exit the Session...
systemd[218473]: Stopped target Main User Target.
systemd[218473]: Stopped target Basic System.
systemd[218473]: Stopped target Paths.
systemd[218473]: Stopped Submitting pending crash events (file monitor).
systemd[218473]: Stopped target Sockets.
systemd[218473]: Stopped target Timers.
...

So it seems to come from systemd, or something calling it.

Thank you.

Last edited by sipak (2025-08-07 08:06:18)

seth · 2025-08-07 09:19:50

SDDM defaults to X11 have you configured it to use wayland? An with what compositor?
Please post your complete system journal for the boot after the crash/sddm restart/whatever we're facing here

sudo journalctl -b | curl -F 'file=@-' 0x0.st

as well as the tail of the paman log, showing the triggering update.

Also did you reboot or at least reload systemd after adding the udev-hack thing?

sipak · 2025-08-07 09:44:25

Yes. I use only wayland even for SDDM. No X anywhere.
Yes. Rebooted.
Yes. I know how to read the journalctl. No need to paste the entire log. I have tested this several times and every time the exact same thing is shown in logs:

systemd[1]: Stopping User Manager for UID 973...
systemd[218473]: Activating special unit Exit the Session...
systemd[218473]: Stopped target Main User Target.

This is repeatable. No other thing is logged to dmesg.

# /var/log/pacman.log

[2025-08-07T03:12:21-0600] [ALPM] reinstalled dolphin (25.04.3-1)
[2025-08-07T03:12:21-0600] [ALPM] transaction completed
[2025-08-07T03:12:21-0600] [ALPM] running '30-systemd-daemon-reload-user.hook'...
[2025-08-07T03:12:22-0600] [ALPM] running '30-systemd-update.hook'...
[2025-08-07T03:12:22-0600] [ALPM] running 'gtk-update-icon-cache.hook'...
[2025-08-07T03:12:22-0600] [ALPM] running 'update-desktop-database.hook'...

Last edited by sipak (2025-08-07 09:57:53)

sipak · 2025-08-07 10:15:02

Okay. I found the nasty evil critters:

The hooks responsible: /usr/share/libalpm/hooks/30-systemd-daemon-reload-user.hook /usr/share/libalpm/hooks/30-systemd-daemon-reload-system.hook

[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Operation = Remove
Target = usr/lib/systemd/user/*

[Action]
Description = Reloading user manager configuration...
When = PostTransaction
Exec = /usr/share/libalpm/scripts/systemd-hook daemon-reload-user

Solution: remove the hook: mv /usr/share/libalpm/hooks/30-systemd-daemon-reload-user.hook /root/, then add the path to NoExtract in pacman.conf so they don't get extracted next time systemd is installed.

This is nasty behavior in my view. Likely to cause a lot of unnecessary problems particularly to new users. But I don't expect to change the mind of whoever thought this was a good idea.
Anyway, there it is for anybody else experiencing this issue.

Last edited by sipak (2025-08-07 11:51:06)

Whoracle · 2025-08-07 10:58:37

That file is owned by core/systemd and does not kill my X11 session on execution. And there haven't been reports for this apart from yours (ETA: that I could find with a quick search), even with Wayland. So sure, go ahead and just remove it instead of trying to figure out WHY your setup breaks, but I'd recommend others not take that approach unless further investigated.

Last edited by Whoracle (2025-08-07 10:59:04)

sipak · 2025-08-07 11:21:11

If you have a suggestion, I am all ears.

That hook execs /usr/share/libalpm/scripts/systemd-hook from which it execs this:

daemon-reload-user)
systemd_live
/usr/bin/systemctl reload 'user@*.service'

Whoracle · 2025-08-07 13:09:46

I haven't used SDDM ever, and Plasma not since it was introduced, and also not on Wayland, so no, not off the top of my head.

One low-level Idea would be to see if executing the hook manually also restarts the session. If it does, you can easily (if messily) reproduce the issue. If so, next step would be to run ps aux or something like that, save the output, rerun the hook ,then run ps aux again and compare - which processes got restarted?

Or some similar, but less stupid method of determining what exactly dies.

And then go on from there.

seth · 2025-08-07 13:10:31

Not reloading the daemon is in certain contexts NOT an option, systemd *has* to restart whenever libsystemd is updated on disk (yes, I agree, horrible design…)

Yes. I know how to read the journalctl. No need to paste the entire log.

If you want further comments on the situation it will be - I cannot tell you what's going on by sheer believe, but this is actually incredibly close to https://bugs.archlinux.org/task/77789

And just for the records

No other thing is logged to dmesg.

The kernel ringbuffer is utterly irrelevant here, this is a userspace problem.

V1del · 2025-08-07 19:31:32

FWIW @sipak, in your reply you mentioned just touch do-not-udevadm-trigger-on-update if that's literally what you ran instead of the command as seth posted it it will not have landed in the correct place.

sipak · 2025-08-08 02:03:31

this is a bug

@Whoracle Yes, running the script does restart the session. This has nothing to do with SDDM, or wayland. It is a systemd unit resetting a user session.

@V1del Yes, /etc/systemd/do-not-udevadm-trigger-on-update.

@seth The issue has been isolated. These two hooks were responsible: /usr/share/libalpm/hooks/30-systemd-daemon-reload-user.hook /usr/share/libalpm/hooks/30-systemd-daemon-reload-system.hook
They execute separate functions of the same script: /usr/share/libalpm/scripts/systemd-hook daemon-reload-user

$ /usr/share/libalpm/scripts/systemd-hook daemon-reload-user daemon-reload-system

  daemon-reload-system)
    systemd_live
    /usr/bin/systemctl --system daemon-reload
    ;;

$ /usr/share/libalpm/scripts/systemd-hook daemon-reload-user daemon-reload-user

  daemon-reload-user)
    systemd_live
    /usr/bin/systemctl reload 'user@*.service'
    ;;

/usr/bin/systemctl reload 'user@*.service'

When run inside a pacman hook triggered by libalpm, it's executed as root, outside of the user session context. The systemctl reload 'user@*.service' pattern interacts with all user manager instances, and depending on how it's invoked (non-interactive session, lacking XDG_RUNTIME_DIR), this can invalidate or tear down user sessions — especially if the PAM session/account is misconfigured or transient. When invoked from pacman hook, you don't have the full login session environment. PAM can't resolve runtime dirs properly, leading to session corruption.

Running systemctl reload 'user@*.service' via a pacman hook targets all user@UID.service units.
systemd may interpret that as: "reinstantiate all user managers." causing systemd to restart logind.

Safer Alternative 1 – Per-user reload via loginctl:

Instead of hitting all user@*.service units globally:

loginctl list-users | awk 'NR>1 {print $1}' | while read uid; do
loginctl enable-linger "$uid" >/dev/null 2>&1
sudo -u "#$uid" XDG_RUNTIME_DIR="/run/user/$uid" systemctl --user daemon-reexec
done

More granular, doesn't nuke the sessions.

Alternative 2 – No user reloads at all

The current hook is over-aggressive and violates session boundaries. It treats systemd --user as a daemon to reload at will, but that's false; it's tightly coupled to the user's login session. root-initiated global reload of user@*.service outside a properly configured PAM+login context should be avoided.

ah... don't you love systemd?

cryptearth · 2025-08-08 03:47:17

well - I can confirm that this is NOT a general bug but something specific to sipak system
I installed my system back in fall 2022 with then kde5 (I just don't like gnome - personal pref) and do updates via several different ways:
- from within the graphical desktop using Konsole
- remote via ssh (I have wake-on-lan setup so I usually remote boot my system when I get home and on thevway up the stairs I ssh and run my daily update)
- via pxe booted install
and I NEVER encountered restarting sddm ONCE
so whatever is wrong here is system specific
further evidence: I have multiple VMs also setup with plasma and none of them has show this issue either

this leads me to two options:
- for some reason I seem to be magically excluded from so many issues so many users reported here since I moved to arch that either I seem to do something so fundamentally different that my system keeps running - or all those others just do something wrong
- this issue is something local to you as I with pretty much the same base system can't reproduce it neither on my host nor in several VMs

and from many topics and thier results I doubt myself in the first option

also: I don't see how

systemctl deamon-reload-user

even could lead to sddm actually restarting

nah - there's something different going on here specific to the affected system - nothin to do with systemd or sddm or plasma - no matter of 13 years of experience vs 3

Whoracle · 2025-08-08 06:21:46

sipak wrote:

@Whoracle Yes, running the script does restart the session. This has nothing to do with SDDM, or wayland. It is a systemd unit resetting a user session.

The point is: It does NOT, for me, on X11 with LightDM and AwesomeWM. And apparently, it doesn't happen for other SDDM/Plasma users. So look for differences here. For example, apparently SDDM by default runs against X11, while, according to the other thread, yours doesn't - pure wayland. So, make sure that is in fact the case, and not an assumption. If it is the case, reproduce it, then switch SDDM to X11 and see if it is still reproducible. There might be a difference in how SDDM X11 handles the user session reload compared to SDDM Wayland.

seth · 2025-08-08 06:47:20

cryptearth wrote:

for some reason I seem to be magically excluded from so many issues so many users reported here

That's fun with statistics. I often read about people being struck by lightning. I must have lived my live wrong - this has never happened to me

@sipak, you don't have to convince me that the libsystemd role, making it the emacs of init daemons, is questionable design and the systematic requirement to restart the PID0 all the time bonkers.
But: It is a thing. And on occasion also mandatory (again: poor design…)

Everyone does that, all the time. If this constantly "restarts" your DM or "logs you out", there will be a very specific cause, borderline unique to your system.

So the first thing to check is what *actually* happens in response, ie. which process dies first, leading to those symptoms.

You are free to decide to just live with it or keep investigating it yourself or… but be aware that what you're currently doing is

sipak · 2025-08-08 07:08:28

Thanks Seth.

I will live with it until I convince myself to reinstall because that removal of /var/lib/pacman will eventually cause a bunch other problems.
And this system has been running for I dunno how long.

I still consider it a bug to use 'user@*.service' there.

seth · 2025-08-08 07:31:49

Stupid question: if you're sure it's a user service, do you edit plasma-kwin_wayland.service ?
/usr/lib/systemd/system/sddm.service isn#t a user service - though since you've suggested to be using https://wiki.archlinux.org/title/SDDM#Wayland - what does that exactly look like on your system?

sipak · 2025-08-08 07:48:37

@seth: No. I avoid modifying systemd units precisely to avoid weird stuff. It is set via config file:

# /etc/sddm.conf.d/kde_settings.conf
[Autologin]
Relogin=false
Session=plasma
User=foo
[General]
DisplayServer=wayland

Last edited by sipak (2025-08-08 07:58:00)

seth · 2025-08-08 07:53:23

That looks wrong - the "DisplayServer" key belongs into the "General" group, meaning SDDM most likely /does/ run on X11?

Whoracle · 2025-08-08 08:22:04

It is in the [General] Group - at least after the edit. I thought it wasn't earlier, too, but I didn't have enough coffee yet, so might be wrong.

seth · 2025-08-08 12:36:29

It was certainly not before the edit after my post.
Also

@sipak, in your reply you mentioned just touch do-not-udevadm-trigger-on-update if that's literally what you ran

@sipak please read https://bbs.archlinux.org/viewtopic.php?id=57855 to understand why this will not work.
We cannot possibly help you based on partial an semi-correct information.
I'll repeat that what you're doing right now is a bad way to gloss over the actual problem, but if you want a comment on what that actually might be, you'll *have* to provide the system journal after such incident.
You can pseudonymize things you don't want to expose (though there's nothing spectacular about user or hostnames) but otherwise leave the data "as is".

cryptearth · 2025-08-08 14:44:41

seth wrote:

That's fun with statistics. I often read about people being struck by lightning. I must have lived my live wrong - this has never happened to me

although I wasn't struck by lightning, yet - in terms of a few kV rushing through my fleshy body - I actually did have several occasions when the "structure" I was in was hit by up to multiple ones

*while "structure" also includes cars on a road and boats on the sea - along with home, office, elevator and the usual place you spent some time of the day

so - does that count for "been there; did that"? =P

sipak · 2025-08-09 03:31:38

One time, a lightning bolt struck an oil drum bin like 3 meters away from me. Does that count as being struck by thunder and survive it?
Anyway... ot

Arch Linux

#1 2025-08-07 04:21:55

Install/Update some packages forcefully restart user session [Solved]

#2 2025-08-07 07:35:46

Re: Install/Update some packages forcefully restart user session [Solved]

#3 2025-08-07 07:55:49

Re: Install/Update some packages forcefully restart user session [Solved]

#4 2025-08-07 09:19:50

Re: Install/Update some packages forcefully restart user session [Solved]

#5 2025-08-07 09:44:25

Re: Install/Update some packages forcefully restart user session [Solved]

#6 2025-08-07 10:15:02

Re: Install/Update some packages forcefully restart user session [Solved]

#7 2025-08-07 10:58:37

Re: Install/Update some packages forcefully restart user session [Solved]

#8 2025-08-07 11:21:11

Re: Install/Update some packages forcefully restart user session [Solved]

#9 2025-08-07 13:09:46

Re: Install/Update some packages forcefully restart user session [Solved]

#10 2025-08-07 13:10:31

Re: Install/Update some packages forcefully restart user session [Solved]

#11 2025-08-07 19:31:32

Re: Install/Update some packages forcefully restart user session [Solved]

#12 2025-08-08 02:03:31

Re: Install/Update some packages forcefully restart user session [Solved]

#13 2025-08-08 03:47:17

Re: Install/Update some packages forcefully restart user session [Solved]

#14 2025-08-08 06:21:46

Re: Install/Update some packages forcefully restart user session [Solved]

#15 2025-08-08 06:47:20

Re: Install/Update some packages forcefully restart user session [Solved]

#16 2025-08-08 07:08:28

Re: Install/Update some packages forcefully restart user session [Solved]

#17 2025-08-08 07:31:49

Re: Install/Update some packages forcefully restart user session [Solved]

#18 2025-08-08 07:48:37

Re: Install/Update some packages forcefully restart user session [Solved]

#19 2025-08-08 07:53:23

Re: Install/Update some packages forcefully restart user session [Solved]

#20 2025-08-08 08:22:04

Re: Install/Update some packages forcefully restart user session [Solved]

#21 2025-08-08 12:36:29

Re: Install/Update some packages forcefully restart user session [Solved]

#22 2025-08-08 14:44:41

Re: Install/Update some packages forcefully restart user session [Solved]

#23 2025-08-09 03:31:38

Re: Install/Update some packages forcefully restart user session [Solved]

Board footer