[systemd-devel] systemd killing processes on monitor wakeup?
Mantas Mikulėnas
grawity at gmail.com
Sun Jan 30 10:54:23 UTC 2022
On Sat, Jan 29, 2022 at 5:29 AM Raman Gupta <rocketraman at gmail.com> wrote:
> Try to set the systemd user instance's log level to 'debug'; I'm guessing
>> it's not that systemd kills processes directly but that something triggers
>> a 'systemctl stop' of the session .scope that they were in.
>
>
> Here are the logs at debug level with some annotations inline:
>
> *<wake up at 21:57:30>*
>
> Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Application
> 'plasmashell' crashing...
> Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Attempting to start
> /usr/libexec/drkonqi
>
> *<This is because of https://bugs.kde.org/show_bug.cgi?id=396359
> <https://bugs.kde.org/show_bug.cgi?id=396359>, could be related to
> subsequent events but I'm pretty sure I've seen this same problem even when
> Plasma doesn't crash>*
>
> Jan 28 21:57:34 edison systemd[2551]: Got message type=signal
> sender=org.freedesktop.DBus destination=n/a path=/org/freedesktop/DBus
> interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4294967295
> reply_cookie=0 signature=sss error-name=n/a error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: D-Bus
> name org.kde.plasmashell now not owned by anyone.
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Changed
> running -> stop-sigterm
> Jan 28 21:57:34 edison systemd[2551]: Sent message type=signal sender=n/a
> destination=n/a
> path=/org/freedesktop/systemd1/unit/plasma_2dplasmashell_2eservice
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged
> cookie=10389 reply_cookie=0 signature=sa{sv}as error-name=n/a
> error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: Sent message type=signal sender=n/a
> destination=n/a
> path=/org/freedesktop/systemd1/unit/plasma_2dplasmashell_2eservice
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged
> cookie=10390 reply_cookie=0 signature=sa{sv}as error-name=n/a
> error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: Received SIGCHLD from PID 3326812
> (idea.sh).
> Jan 28 21:57:34 edison systemd[2551]: Child 3326812 (idea.sh) died
> (code=killed, status=15/TERM)
>
> *<This seems to indicate that systemd is receiving notification that IDEA
> died. Not sure why killsnoop.py seems to think that systemd is the process
> that sends the SIGTERM -- it's still unclear to me where IDEA is receiving
> the SIGTERM from>*
>
Processes get SIGCHLD for all children that exit -- it's not suppressed
just because the same process sent a SIGTERM recently.
>
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3326812 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Child 3114994 (kio_http_cache_) died
> (code=killed, status=15/TERM)
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3114994 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Child 3328167 (adb) died
> (code=killed, status=15/TERM)
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3328167 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Received SIGCHLD from PID 3328167
> (n/a).
>
> *<bunch more processes dying similarly, plasma restarting, etc.>*
>
Honestly this just sounds like systemd killing "leftover" processes within
the plasma-plasmashell cgroup, after the "main" process of that service has
exited. That's not a bug; that's standard behavior for systemd services.
For special cases like desktop environments, I think this means the
.service should have KillMode=process (as long as that's still supported,
anyway), *or* Plasma should be improved to no longer spawn apps directly
but to put them in new systemd units (like gnome-shell does).
--
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220130/d24a9501/attachment.htm>
More information about the systemd-devel
mailing list