Hi Przemyslaw / Przemek, Thanks for the clarifications.
> The monitoring alert is based on Zabbix's system.users.num item, which in > this setup obtains the user count from `who | wc -l`. OK, then we ignore this monitoring alert from our considerations. > I am also not suggesting that merely retaining the session in `loginctl` is > necessarily a bug. A detached Screen process was still running in its scope, > and the session remained in the "closing" state. > ... > loginctl still listed session 151944 with the same Leader. I tend to consider this a bug in systemd. systemd is supposed to report the *current* state of the sessions, not some historical state. This means that if systemd reports a certain PID and that PID is now reassigned to a process that is unrelated to that session, it is doing the wrong thing. systemd should not report that PID for that session any more. > I agree that it is worth asking the systemd maintainers about the expected > semantics of Leader for a closing session. I am happy to raise that question > there. Thanks. I'll wait for their answer. > Would you nevertheless agree that the PID-reuse-dependent behavior in `who` > is undesirable, regardless of whether retaining the closing session in > loginctl is expected? No. If the systemd maintainers agree that it's a systemd bug, I don't wish to add a workaround in coreutils / gnulib. Bruno
