You are not logged in.

#1 2023-10-05 21:02:24

gcb
Member
Registered: 2014-02-12
Posts: 169

Why user.service KillMode is set to mixed?

All processes a user start get SIGKILL instantly on shutdown. No chance to save data or anything. And logs show it is all happening in the same millisecond. SIGHUP, bam SIGKILL.

Those are things started on the terminal or graphical interface. Sometimes the WM adds hacks to stop things (kde and gnome have hacks to wait for browsers, for example, and as far as i bothered to follow they add delays on their own synchronous `ExecStop=`). but everything else just gets killed instantly.

as far as i can tell the default is to send SIGHUP, wait, SIGKILL... but in my arch systems (only ones on systemd *and* users), I notice that they change the `KillMode=` from the default cgroups mode to `mixed` on user.service... why is that?

If set to mixed, the SIGTERM signal is sent to the main process while the subsequent SIGKILL signal is sent to all remaining processes of the unit's control group.

-- https://www.freedesktop.org/software/sy … .kill.html

1) Why would anyone think this is a good idea? (that is, assume all user processes can lose data on shutdown)
2) Is this an arch thing or upstream systemd?
3) can we start a conversation to change this? or are all the systemd jokes "its all about faster reboots" factual? smile

Offline

#2 2023-10-05 21:31:08

gcb
Member
Registered: 2014-02-12
Posts: 169

Re: Why user.service KillMode is set to mixed?

just noticed after checking if this was the same on other distros, something is overriding this in runtime.

The actual service unit have the default, the instantiated user unit have mixed

$ systemctl show  user.service | grep KillMode
KillMode=control-group

$ systemctl show  user@1000.service | grep KillMode
KillMode=mixed

?!

Offline

#3 2023-10-05 21:44:02

loqs
Member
Registered: 2014-03-06
Posts: 18,130

Re: Why user.service KillMode is set to mixed?

See /usr/lib/systemd/system/user@.service

Offline

#4 2023-10-05 22:20:55

gcb
Member
Registered: 2014-02-12
Posts: 169

Re: Why user.service KillMode is set to mixed?

Thanks! had just seen that and was following the source. seems to have been added in late 2014. caused lots of complaints all thru 2015 when distros rolled back with patches. and then back in early 2016.

Added a note on our wiki and sent an update to their docs noting that what hey call a default is not a default for some special units.

Cannot believe I'm wasting time with bad design choices from systemd from 9yrs ago.

Offline

#5 2023-10-06 14:36:07

gcb
Member
Registered: 2014-02-12
Posts: 169

Re: Why user.service KillMode is set to mixed?

Ok, that solves #2... still would like to know what you all think about

1) Why would anyone think this is a good idea?
2) ✔️
3) can we start a conversation to change this?

changed all my user's system to patch that file to comment out the KillMode change. Honestly, i have no idea why for 8yrs that was the default and nobody complained. Cannot imagine the random data loss people are getting from this if they run things like databases or libreoffice, and shutdown without closing each application manually. ...i guess most redhat customers only notice this when their ssh shell lost some history lines after a server shutdown. not like redhat is in the desktop business for a while.


with that "fixed", shutdowns manages to close everything fine in under a second without any problem. Which was the original reason for the "feature"

$ systemctl show  user@1000.service | grep KillMode
KillMode=control-group

$ journal -a -b -1
...
Sep 29 13:41:45  systemd[1]: Stopping User Login Management...
Sep 29 13:41:45  systemd[1]: Stopping User Manager for UID 1000...
Sep 29 13:41:45  dbus-daemon[726]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Refusing activation, D-Bus is shutting down.
Sep 29 13:41:45  systemd-logind[727]: Removed session 2.
Sep 29 13:41:45  systemd[903]: Activating special unit Exit the Session...
Sep 29 13:41:45  systemd[903]: Removed slice User Background Tasks Slice.
Sep 29 13:41:45  systemd[903]: background.slice: Consumed 1min 2.832s CPU time.
Sep 29 13:41:45  systemd[903]: Stopped target Bluetooth.
Sep 29 13:41:45  systemd[903]: Stopped target Main User Target.
Sep 29 13:41:45  systemd[903]: Stopping D-Bus User Message Bus...
Sep 29 13:41:45  systemd[903]: Stopping User preferences database...
Sep 29 13:41:45  systemd[903]: Stopping Bluetooth OBEX service...
Sep 29 13:41:45  systemd[903]: Stopping PipeWire PulseAudio...
Sep 29 13:41:45  systemd[903]: Stopped User preferences database.
Sep 29 13:41:45  systemd[903]: obex.service: Main process exited, code=exited, status=1/FAILURE
Sep 29 13:41:45  systemd[903]: obex.service: Failed with result 'exit-code'.
Sep 29 13:41:45  systemd[903]: Stopped Bluetooth OBEX service.
Sep 29 13:41:45  systemd[903]: Stopped PipeWire PulseAudio.
Sep 29 13:41:45  systemd[903]: Stopping Multimedia Service Session Manager...
Sep 29 13:41:45  polkitd[746]: Unregistered Authentication Agent for unix-session:2 (system bus name :1.40, object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UT>
Sep 29 13:41:45  systemd[903]: Stopped D-Bus User Message Bus.
Sep 29 13:41:45  systemd[903]: dbus.service: Consumed 2.802s CPU time.
Sep 29 13:41:45  wireplumber[1207]: stopped by signal: Terminated
Sep 29 13:41:45  kernel: wlp1s0: deauthenticating from d8:ec:5e:80:ad:64 by local choice (Reason: 3=DEAUTH_LEAVING)
Sep 29 13:41:45  wireplumber[1207]: disconnected from pipewire
Sep 29 13:41:45  systemd[903]: Stopped Multimedia Service Session Manager.
Sep 29 13:41:45  systemd[903]: wireplumber.service: Consumed 2.466s CPU time.
Sep 29 13:41:45  systemd[903]: Stopping PipeWire Multimedia Service...
Sep 29 13:41:45  systemd[903]: Stopped PipeWire Multimedia Service.
Sep 29 13:41:45  systemd[903]: Removed slice User Core Session Slice.
Sep 29 13:41:45  systemd[903]: session.slice: Consumed 3min 43.257s CPU time.
Sep 29 13:41:45  systemd[903]: Stopped target Basic System.
Sep 29 13:41:45  systemd[903]: Stopped target Paths.
Sep 29 13:41:45  systemd[903]: Stopped target Sockets.
Sep 29 13:41:45  systemd[903]: Stopped target Timers.
Sep 29 13:41:45  systemd[903]: Closed D-Bus User Message Bus Socket.
Sep 29 13:41:45  systemd[903]: Closed GnuPG network certificate management daemon.
Sep 29 13:41:45  systemd[903]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Sep 29 13:41:45  systemd[903]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Sep 29 13:41:45  systemd[903]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Sep 29 13:41:45  systemd[903]: Closed GnuPG cryptographic agent and passphrase cache.
Sep 29 13:41:45  systemd[903]: Closed p11-kit server.
Sep 29 13:41:45  systemd[903]: Closed PipeWire PulseAudio.
Sep 29 13:41:45  systemd[903]: Closed PipeWire Multimedia System Socket.
Sep 29 13:41:45  systemd[903]: Removed slice User Application Slice.
Sep 29 13:41:45  systemd[903]: app.slice: Consumed 5min 21.624s CPU time.
Sep 29 13:41:45  systemd[903]: Reached target Shutdown.
Sep 29 13:41:45  systemd[903]: Finished Exit the Session.
Sep 29 13:41:45  systemd[903]: Reached target Exit the Session.
Sep 29 13:41:45  (sd-pam)[904]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8004 service=[systemd-user] terminal=[] user=[gcb] ruser=[<unknown>] rhost=[<u>
Sep 29 13:41:45  systemd[1]: user@1000.service: Deactivated successfully.
Sep 29 13:41:45  systemd[1]: Stopped User Manager for UID 1000.
...

This is log from both the older laptop we have with more finicky hardware and amd drivers and a user who likes wayland. also not shown are dozen of vms shutindown properly without mentions on the syslog as the devs start them via qemu-system*

previously i'd get tickets that qemu was "leaving pid files around" after reboots. because well, they were being killed by that silly KillMode=mixed. Everything works as expected now.

Offline

#6 2023-10-06 15:32:30

loqs
Member
Registered: 2014-03-06
Posts: 18,130

Re: Why user.service KillMode is set to mixed?

gcb wrote:

Ok, that solves #2... still would like to know what you all think about

Why do you not consider #1 solved?  #3 needs to be addressed upstream surely?

gcb wrote:

changed all my user's system to patch that file to comment out the KillMode change.

By patch do you mean altering the file in /usr/lib meaning your change will be overwritten when the systemd package is updated?  Instead of overriding it?

gcb wrote:

also not shown are dozen of vms shutindown properly without mentions on the syslog as the devs start them via qemu-system*

Started how exactly?

Offline

Board footer

Powered by FluxBB