Re: systemd killing processes on monitor wakeup?

[Mantas Mikulėnas <grawity@xxxxxxxxx>]

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.

Can't think of any events directly related to monitor wakeup that systemd would react to (unless you meant the processes die on full system suspend that usually follows). Do you have any screensaver running? Do the processes actually get killed when the monitor goes to sleep or only when it wakes up?

On Wed, Jan 26, 2022, 15:39 Raman Gupta <rocketraman@xxxxxxxxx> wrote:

Does anyone have any tips for debugging this or getting more information? Should I create an issue for this?

On Sun, Jan 23, 2022 at 3:43 PM Raman Gupta <rocketraman@xxxxxxxxx> wrote:

(A variation of this message was originally sent to fedora-users)

I have a couple processes that have been consistently dying every time I wake up my monitors after the system has been idle. One is Slack Desktop and the other is IntelliJ IDEA.

I used an eBPF program (killsnoop.py at https://github.com/iovisor/bcc/blob/master/tools/killsnoop.py) to trace where the signal to shut down these processes was coming from, and it appears that systemd is sending pretty much every active process signal 15 and then 18.

TIME      PID    COMM             SIG  TPID   RESULT

... on monitor wakeup ...

12:16:58  2551   systemd          15   2938613 0
12:16:58  2551   systemd          18   2938613 0
12:16:58  2551   systemd          15   2938814 0
12:16:58  2551   systemd          18   2938814 0
12:16:58  2551   systemd          15   2938832 0
12:16:58  2551   systemd          18   2938832 0
12:16:58  2551   systemd          15   2938978 0
12:16:58  2551   systemd          18   2938978 0
12:16:58  2551   systemd          15   2939432 0
12:16:58  2551   systemd          18   2939432 0
12:16:58  2551   systemd          15   2939899 0
12:16:58  2551   systemd          18   2939899 0
12:16:58  2551   systemd          15   2942192 0
12:16:58  2551   systemd          18   2942192 0

...

Process 2551 is the PDF of the source of the signal according to killsnoop, 15 and 18 are the signals being sent, and TPID is the target PID, which among many others, does include my dying processes. Process 2551 is indeed systemd, specifically the user process:

raman       2551       1  0 Jan07 ?        00:00:10 /usr/lib/systemd/systemd --user

This behavior is relatively new. What is going on here? I haven't found any other reports of this behavior anywhere else.

I'm using systemd-249.9-1.fc35 on Fedora 35.

Regards,

Raman