[systemd-devel] systemd killing processes on monitor wakeup?

[Raman Gupta]

(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220123/4e36e00e/attachment.htm>