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

[John Paul Adrian Glaubitz]

On 05/30/2016 10:52 PM, Iustin Pop wrote:
> 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.

An admin who is upgrading to a new version of the operating system (assuming
that no one in their right mind runs unstable in their production
environment where systemd_230 would already be installed in the next
upgrade) will run lots of tests before actually deploying which is
how these things are usually caught.

And, moreover, if something like this slips through the cracks, you will
usually get a ticket from a user very quickly after deployment who would
complain about that change and you could adjust the configuration
accordingly.

An admin who runs into such upgrades blindly and unprepared will not
keep their jobs for a very long time.

>> 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.

It makes as much sense there as well. See above what Martin said [1]: When you
log out, you expect processes to be terminated, not to continue them running
since this a potential security problem.

>> 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.

Yes, that was proposed multiple times [2,3,4]. Plus, it was also mentioned
across multiple bug trackers like the tmux bug [5]. All of them are basically
asking to write bug-free software which is not possible. Again, the only
real feasible solution is have the session manager clean up leftover
processes after the user logs out. The same way the janitor in a large
company locks all doors, sets up the alarm and turns off the lights
after the last employee has left.

> 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.

First of all, Linux is a multi-user operating system, so I think it should,
by any means, behave sanely in this regard by default. Furthermore,
as I have mentioned before, I think most users will expect all processes
to be killed upon log out. I mean, you *closed* a session after all. Why
would you want anything from that session to continue running after
you closed it. That doesn't remotely make any sense, really.

If I wanted some process to survive logout, I should be forced to
explicitly tell that to the session manager. This is the only way
the session management is able to clean up a session properly. If
it will have to guess, there will always be random leftover processes.

>> 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.

Well, my argument is that the people who made the change are the ones
who do the actual work. And for that, they most certainly get to decide
what the defaults are. People seem to feel entitled to have free software
catered to their personal needs. But that isn't the case. Everyone
gets to make their decisions in their own code and others can just
use it and adjust it to their own needs.

This is the whole idea of open source, after all. But open source most
certainly doesn't mean, you get to tell others how to develop their software.

> 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.

I'm sorry, but this change currently affects Debian unstable or the-like
distributions only, so it's not disrupting anyone who is doing productive
work. I mean, "unstable" is called what it's called for a reason, isn't
it?

All what the systemd developers have done is change a default in their
upstream project which is - again - a decision which is completely up
to them. I mean, it's *their* project, after all.

> 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.

Leftover processes are a potential security issue as Martin has pointed
out in [1]. Processes that are unintentionally killed would only be those
that are run within tmux, screen or similar multiplexer without being
invoked with the necessary options to the session manager. Those are
usually only shortly running tasks or things like "irssi" as for real
daemons, users should set up a service anyway. Running something like
MySQL or Apache in a screen is a crude hack anyway as you give away
all the nice process tracking features that you get when setting up
a proper service.

> 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".

Well, come on. Look what the usual arguments against it are: "This has
been the default for the past 30 years and now it has changed and
I am forced to change two options." This is not, by any stretch, a technical
argument. This is just being against change for the sake of it being a
change.

If we seriously hadn't changed how Linux, or even Unix, behaves in
the past 25 years, we'd still be in the dark ages where we had to configure
XFree86 manually by editing modelines, had to use pnpdump and isaconf
to set up a sound card and had to read endless documentation just
to be able to set up apsfilter and lpr to be able to print. I have
been there and I don't want these times back.

Heck, I would bet that most people who come around with sentences
like "This hasn't been changed in the past 30 years" never knew
what it meant to use Linux in the 90ies or even early versions
of SunOS or other proprietary Unices. The reason why Linux has gained
so many more users over the past 25 years and why Linux is running
everywhere nowadays (Android, Routers, TVs etc) is because people
like the systemd developers actually improve the code and make
changes. If we had been standing still in the past 25 years, Linux
would have already been history and we'd all be using Windows 10.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#95
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#147
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#117
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#112
> [5] https://github.com/tmux/tmux/issues/428

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913