[systemd-devel] Requested transaction contradicts existing jobs: start is destructive

[Kumar Kartikeya Dwivedi]

On Tue, 5 May 2020 at 16:27, Mark Bannister <mbannister at janestreet.com> wrote:
>
> So if I'm understanding correctly, your suggestion is that if an SSH
> session runs a process that ignores SIGTERM and the session is closed
> and then within 90 seconds the same user attempts to open a new SSH
> session, it should trigger this error condition?

Given the session you just logged out of was the last session, yes,
otherwise logind won't GC your user. The only requirement is for
something to delay the session scope's stopping, which should keep the
user slice's stop job waiting, which would allow you to reproduce this
at will.

>
> Perhaps I'm missing something or oversimplifying, but I tried to
> reproduce the problem as follows: I created a script that ignores INT,
> TERM and HUP and then loops indefinitely writing the time every second
> to a log file.  I SSHed into the box, ran the script, and then from
> another terminal window killed the parent (bash) and also retried the
> experiment by killing the bash parent (sshd).  In both cases the
> parent bash and sshd processes died (as expected), my script kept
> running but the parent PID of the script was changed to 1 (systemd).
> I did not receive any error messages in /var/log/messages.
>

It has to be the last remaining session of the user, and you should
inspect with systemctl list-jobs if systemd is trying to stop the
scope and slice units, just to be sure, before attempting to login.
Otherwise, if you're logged in from two places on the machine for a
user, you won't hit the issue, obviously.

--
Kartikeya