Bug#825394: systemd kill background processes after user logs out

[Iustin Pop]

On 2016-05-30 22:19:48, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> > don't think the right response should be to just fix it one way
> > for everyone, especially not since those people in charge of hundreds
> > of systems have exactly one vote, similar to those who just develop
> > for their own home workstation.
> 
> I'm sorry, but this is a very bad argument. People who are in charge
> of hundreds of systems almost never use the default settings but use
> something like FAI, Puppet or ansible to configure their systems
> exactly the way they need them. No one is installing hundreds of
> computers manually with the d-i images like you would do on a single
> machine, that would just be nuts. And in these scenarios, changing
> the default settings of configuration files in packages is a daily
> routine and nothing special. So, this change has *zero* negative
> impact for these users.

As long as they know about it. In an ideal world, yes, every such admin
would read in detail all release notes. In the real world, you've just
added more trouble for the (usually overworked) admins.

> As for the usefulness of this change: I used to work at the IT departmant
> of a large university in the past and I have some experience in this regard.
> In fact, this particular change in systemd solves a *very* common problem in
> these setups which are leftover processes on the computers in the student computer
> pools as around at least a dozen different users are logging in and out again
> on these machines per day with many different processes still staying around, and,
> no, this is not particularly a GNOME problem - it's a general problem which
> is usually solved with a cron job which kills leftover processes regularly.

It's true that for shared machines this makes sense. But not for
individual workstations, e.g. in a company which deploys Linux as the
default OS for engineers.

> Some people here suggested that, instead of adding such a functionality to
> the session manager, affected projects should just fix their software which
> effectively translates to "People should write bug-free software" which
> is, of course, an unrealistic goal and therefore not really adding to
> the discussion in any fruitful manner.

Sure, but nobody in this bug proposed that.

> Thus, the systemd approach is actually sane and exactly what most admins of
> larger setups with many users want. And it's not that the systemd developers
> did not provide an opt-out solution. As it was clearly documented in the
> release notes, users are free to disable this feature or use systemd-run
> to explicitly prevent a process from being killed upon logout which is
> *exactly* what every admin wants: Processes should be killed upon logout
> by default and anything that should remain running should request an
> explicit permission from the session management. There is really no other
> good way to tackle this problem. Admins will neither be able to prevent
> buggy software (since users could just write and run their own buggy
> software) nor is it practical to keep a long black list with runaway
> processes which are being killed upon logout.

Again, you're looking at it from the point of view of shard machines. In
the case however where we're talking about individual machines, this
becomes a counter-argument. Similarly here in this bug people proposed
whitelists of processes which should not be killed, a similarly bad
measure.

> It's honestly very frustrating to read bug reports like these as they
> are usually written by people who lack the necessary background or refuse
> to accept that their particular use case is not the common use case.

This can be argued from the other side as well. Exactly the same
argument. What makes _your_ argument the right one? They are two sides
of the same problem.

> And I
> have more the impression that these bug reports are merely written to
> stir up emotions because, again, the systemd developers dared to touch
> something in the Linux software stack which has not been touch for years
> while solving yet another long-existing problem. A reasonable person wouldn't
> even mind about such changes. They would either just disable the feature
> completely or use the provided mechanisms to white-list individual processes
> which takes less time than writing up such a bug report and stirring up
> emotions.

No, that's not the case. The problem is that, unilaterally, systemd
authors/systemd packaging team decided to change the default. IMHO, a
reasonable and less conflictual path forward would have been to
advertise this feature, allow the needed software changes to propagate
to the most common programs affected (screen, tmux, etc.) and only later
make the switch to it.

The other issue is that, and here maybe it's only my experience,
unintended leftover processes usually only consume resources, but
unintentionally killed processes can result in data loss. Thus, this
setting is on the more dangerous default.

I'm happy that this setting exists. I'm not happy that the default was
changed, and that yet again, from the systemd side, I hear "you don't
have enough experience and wisdom to understand this is better for you".

regards,
iustin