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

[John Brooks]

As Martin Pitt said, it has been reverted already in Debian's systemd 
package. Here is the relevant commit: 
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=c11c9a4


Have a nice day.

--
*John Brooks

*
On 16-06-04 07:57 PM, Brendan Halpin wrote:

Please revert this. I use nohup to run long statistical simulations, and
I have just lost 12 hours of computation. This change breaks fundamental
behaviour.

Brendan

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

[Brendan Halpin]

Please revert this. I use nohup to run long statistical simulations, and
I have just lost 12 hours of computation. This change breaks fundamental
behaviour. 

Brendan
-- 
Brendan Halpin, Head, Department of Sociology, University of Limerick, Ireland
Tel: w +353-61-213147  f +353-61-202569 Room F1-002 x 3147
mailto:brendan.hal...@ul.ieULSociology on Facebook: http://on.fb.me/fjIK9t
http://teaching.sociology.ul.ie/bhalpin/wordpress twitter:@ULSociology

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

[debian]

Just saying ..

> An admin who is upgrading to a new version of the operating system
> will run lots of tests before actually deploying which is
> how these things are usually caught.

Exactly, I do check if a screen is still up after disconnect, before
pushing every update in production. I do check if it's running after 2H,
4H, 24H and 7d.

This is why I am still on potato : checks for upgrading to woody hasn't
completed yet :lol:

(btw, puppet for heterogeneous systems, not so awesome)

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

[Duraid Madina]

If there were ever any doubt, this surely settles it:

systemd truly is the pulseaudio of process control!

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

[erdnaxeli]

On Mon, 30 May 2016 22:19:48 +0200 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> 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 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.
>
> 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.
>
> 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.

I don't understand something. You are a sysadmin, in an IT department. So I
suppose
you use something like « FAI, Putter or ansible to configure [your] systems
». Why
can't *you* set the right option you want? The feature already exists!

I think the problem is not about the feature. The problem is only about the
default value. The solution with debconf seems pretty good to me for end
users,
and the sysadmin already know what they want, as you say it.

>
> 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. 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.
>
> Thanks,
> Adrian
>


Alexandre Morignot

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

[martin f krafft]

also sprach John Paul Adrian Glaubitz  
[2016-05-30 23:30 +0200]:
> 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.

Wrong conclusion. If you don't understand the value of being able to
consider more than just the technical side, then maybe Debian isn't
the right project for you.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
eleventh law of acoustics:
  in a minimum-phase system there is an inextricable link between
  frequency response, phase response and transient response, as they
  are all merely transforms of one another. this combined with
  minimalization of open-loop errors in output amplifiers and correct
  compensation for non-linear passive crossover network loading can
  lead to a significant decrease in system resolution lost. however,
  of course, this all means jack when you listen to pink floyd.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

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 

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

[martin f krafft]

also sprach John Paul Adrian Glaubitz  
[2016-05-30 22:19 +0200]:
> 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, …

In this case: agreed. In general, I just wanted to point out that
a head count in Debian never translates to number of systems.

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

I disagree with your assessment. At least for my part, I am
a systemd supporter, especially after having seen the great work our
Debian packagers have done.

However, this does not mean I have to agree with every change that
systemd is imposing, and as I wrote in my original message,
Unix/Linux has become successful (also) *because* it doesn't just
break with tradition, but adheres to standards and doesn't surprise
people.

The proposed default might very well be what our users want, but we
have no way of knowing and until we do, we should refrain from
making invasive changes, whether in the systemd ecosystem or
anywhere else.

As such, I appreciate that Martin reverted the default and I trust
that the debian-systemd team will find a solution suitable for the
universal operating system.

> A reasonable person wouldn't even mind about such changes.

I am sure you didn't mean to call everyone unreasonable who minds
about this change.

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

We are Debian developers. We love what we do and we cherrish our
product. We do not satisfy ourselves with hacks, or turn a blind eye
to problems, and I hope that will never change.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"although occasionally there is something to be said for solitude."
-- special agent dale cooper


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

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 

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

[John Paul Adrian Glaubitz]

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

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.

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.

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

Thanks,
Adrian

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

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

[martin f krafft]

also sprach Martin Pitt  [2016-05-29 11:13 +0200]:
> I believe this *is* it the expected thing to do on personal
> computers. This is certainly different in environments like
> universities where one often does put long-running stuff in the
> background, but this doesn't appeal to me as being the behaviour
> to optimize for.

The problem with this statement that I have is that we're the
universal operating system, and while that should not keep us from
"optimising", we really ought not light-heartedly move away from how
things have worked ever since the inception of multics/unix/linux.

It may well be that a non-negligible part of our user base would
benefit from this new behaviour, but at this stage, assuming that
the majority would want this change and calling those speaking up
here a "vocal minority" is IMHO not the right thing to do. Even if
you were to have a GR over this, I 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.

We have a tool to handle divergent default behaviours in Debian and
it's called debconf. systemd-logind should engage debconf and prompt
on upgrade/install what the local behaviour should be. And until the
point comes that we have enough data to determine that we're
inconveniencing the majority of our users with the default (i.e.
they are choosing the other behaviour), we should leave the default
as how it's been.

> However, this really shouldn't be such a general problem: If/when
> we can change tmux and screen to use PAM or enable lingering, then
> I think we get the best of both worlds: Logging out would clean up
> properly, but the (relatively few) users who use screen/tmux on
> a PC would get the expected behaviour of those processes
> surviving.

There is more than tmux and screen. For instance, my shell knows
that I specifically do *not* want it to HUP background processes
when I leave the shell session:

  http://git.madduck.net/v/etc/zsh.git/blob/HEAD:/.zsh/zshrc/99_TODO#l31

Please do not assume that everything is as simple as how you're
portraying it to be. Linux is a very very very diverse ecosystem and
it grew to be such as a function of the principle of least surprise,
among other things.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

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

[Antonio]

>
>  It may be a minority, but I'm sure it's
> a significant amount of people
>
>
Agree, I think this should remain to be considered a bug, even a critical
bug. And I am sure users of screen/nohup/tmux or others "daemons" which
could be affected are not a small minority, but even the majority. So
please, set the former option as default.

best regards,
Antonio

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

[Lawrence D'Oliveiro]

Does setsid(1) still work? I read over this

carefully, and I think the answer is yes, but I’m not sure.

If it does, I’m happy. If it doesn’t, I would be annoyed.

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

[Vladimir K]

If some software is supposed to relate to user's session and does not properly 
exit with session, that is the bug of said software and no business of init 
system.
This change breaks things and requires to jump through hoops to repair things 
that until now just worked.

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

[Renaud Allard]

While I agree that it would be a good idea to kill the non useful 
remaining processes when a users logs out on a desktop or remote session 
server, the new behavior completely beats the purpose of 
nohup/tmux/screen or any user started daemon.


Actually, if a user logs out and some gnome (for example) related 
processes are not killed, this is more a bug which needs to be solved in 
gnome and not on the whole OS. When you quit gnome, gnome needs to 
ensure its own processes it started on login are killed at logout, but 
not anything that doesn't belong to gnome.




smime.p7s
Description: S/MIME Cryptographic Signature

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

[John Brooks]

On Sun, 29 May 2016 11:46:36 +0200 Guus Sliepen  wrote:
> I'm sure the majority of users couldn't care less either way. What we
> have to think about is: does the minority of people who really want this
> feature (for example, because you want your homedir to be locked
> whenever possible) outweigh the minority of people who really don't
> want this feature (because they lose time/work when their processes get
> killed unexpectedly)?

Actually, I think this would be of concern to anyone who uses screen or 
tmux to manage their sessions and/or run background processes (not 
limited to screen/tmux either). It may be a minority, but I'm sure it's 
a significant amount of people. Most of them wouldn't be following this 
news or posting here, however. As for whether which group of people is 
right, I think the principle of least surprise decides that easily; the 
people who want it can enable it manually, and the people that don't can 
continue operating as they have always done without having to be aware 
of this.


On Sun, 29 May 2016 11:13:32 +0200 Martin Pitt  wrote:
> I believe this *is* it the expected thing to do
> on personal computers. This is certainly different in environments
> like universities where one often does put long-running stuff in the
> background, but this doesn't appeal to me as being the behaviour to
> optimize for. At the moment I'm not sure whether this bug report and
> the followups are just a vocal minority or somewhat representative of
> Debian's user (I lean towards the former).

Most Debian installations (derivatives notwithstanding) are on servers, 
not workstations. I think it's a safe assumption that most of them would 
prefer that the system behaves in a way that is optimal for the server 
use case.

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

[Guus Sliepen]

On Sun, May 29, 2016 at 11:13:32AM +0200, Martin Pitt wrote:

> I've long wanted to enable killing leftover processes on logout. In my
> world, that's what I actually expect when I log out of a computer, and
> I *don't* want anything running as my user any more (which in turn
> keeps my encrypted home dir unlocked too). I never got around to
> enabling the option, but the upstream change was a welcome nudge to
> actually enable this. I believe this *is* it the expected thing to do
> on personal computers.

Yes, I certainly expect things to be cleaned up properly as well. I am
also mildly annoyed by all these newfangled daemons that are running and
don't properly clean up themselves. But I don't want proper programs
that are supposed to keep running to be collateral damage.

> This is certainly different in environments
> like universities where one often does put long-running stuff in the
> background, but this doesn't appeal to me as being the behaviour to
> optimize for.  At the moment I'm not sure whether this bug report and
> the followups are just a vocal minority or somewhat representative of
> Debian's user (I lean towards the former).

I'm sure the majority of users couldn't care less either way. What we
have to think about is: does the minority of people who really want this
feature (for example, because you want your homedir to be locked
whenever possible) outweigh the minority of people who really don't
want this feature (because they lose time/work when their processes get
killed unexpectedly)?

> However, this really shouldn't be such a general problem: If/when we
> can change tmux and screen to use PAM or enable lingering, then I
> think we get the best of both worlds: Logging out would clean up
> properly, but the (relatively few) users who use screen/tmux on a PC
> would get the expected behaviour of those processes surviving.

Note that I did only give tmux and screen as examples, they are not the
only programs that might go into the background. As mentioned by John
Brooks, it would be even more confusing if some programs do work because
and others don't. 

> So I'm fine with reverting to the previous behaviour until a more
> fine-grained API (https://github.com/systemd/systemd/issues/3382) is
> available.

I wonder if there are other approaches than to have to shoe-horn every
legacy backgrounding process into systemd's view of the world. Maybe
instead of a "lingering" option, could there be a "non-lingering"
option, that gets applied to those processes that you expect to
disappear when you log out of a session? And why do these processes not
quit properly anyway?

How about only sending the HUP signal to processes that don't have a
pseudo-TTY assigned? That would kill all those daemons, leave anything
running inside a screen/tmux/terminal untouched?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

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

[Martin Pitt]

Michael Biebl [2016-05-27 14:09 +0200]:
> The new requirement of having to enable lingering and starting
> tmux/screen/nohup/ via systemd-run can certainly be considered a
> nuisance and something our users are not necessarily aware of.
> I share that concern.
> So a NEWS.Debian entry would be the least we should do. And maybe
> documenting it in the release notes.
> 
> That all said, we'll discuss that within the team. I couldn't get hold
> of Martin on irc, so this might take a couple of days (I won't be around
> much over the weekend).

Sorry, I've been away for a few days. I'll return to normal work
tomorrow.

I've long wanted to enable killing leftover processes on logout. In my
world, that's what I actually expect when I log out of a computer, and
I *don't* want anything running as my user any more (which in turn
keeps my encrypted home dir unlocked too). I never got around to
enabling the option, but the upstream change was a welcome nudge to
actually enable this. I believe this *is* it the expected thing to do
on personal computers. This is certainly different in environments
like universities where one often does put long-running stuff in the
background, but this doesn't appeal to me as being the behaviour to
optimize for.  At the moment I'm not sure whether this bug report and
the followups are just a vocal minority or somewhat representative of
Debian's user (I lean towards the former).

However, this really shouldn't be such a general problem: If/when we
can change tmux and screen to use PAM or enable lingering, then I
think we get the best of both worlds: Logging out would clean up
properly, but the (relatively few) users who use screen/tmux on a PC
would get the expected behaviour of those processes surviving. So I'm
fine with reverting to the previous behaviour until a more
fine-grained API (https://github.com/systemd/systemd/issues/3382) is
available. Michael, WDYT?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

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

[John Brooks]

This new behaviour is counter-intuitive to how users expect the system to work. 
Among other things, it completely breaks the use of tmux/screen to save a 
session for another time or place, or to execute long-running tasks that don't 
warrant their own systemd service in a way that survives disconnections.

This really should never have been made a default at all. If systemd does not 
revert it upstream, it should at least be disabled by the Debian systemd 
maintainers. A news entry telling administrators how to disable it is not 
enough; there's no good reason for it to be enabled in the first place in a 
server environment. 
John Brooks

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

[Zbigniew Gralewski]

Yes, i sign also. New functionality is not expected behaviour.
I also run long term commands under screen and logout expecting they 
will be active when i get back.

Please, really consider reverting this back.
--
Zbigniew Gralewski
zbign...@gralewski.pl

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

[georg]

It is most probably related to this

https://github.com/systemd/systemd/issues/2900

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

[Stefanos Harhalakis]

Hi there,

As you know, one of the two reasons screen is used is to allow for
things to stay running if you get disconnected. In this spirit, I
personally run long-term things like backups and dist-upgrades under
screen (under X) in order to prevent interrupting them if (e.g.) X
crash. On the server side, I use screen in order to keep things
running even if I get disconnected.

My belief is that I am not the only and and I that a behavior change
like this should not enter testing lighthearted (I understand this is
only in unstable so far) even if it is the default behavior systemd
chooses to have.

Other than that, I'd be curious to see why this choice has been made
by systemd. I'm sure that there are good reasons, but I can't seem to
be able to find a reference to them. If you are aware of a link could
you please share it?

Thanks,
Stefanos

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

[Michael Biebl]

Hi Guus,

Am 26.05.2016 um 18:16 schrieb Guus Sliepen:
>> systemd-logind will now by default terminate user processes that are
>> part of the user session scope unit (session-XX.scope) when the user
>> logs out.
> 
> It is now indeed the case that any background processes that were still
> running are killed automatically when the user logs out of a session,
> whether it was a desktop session, a VT session, or when you SSHed into a
> machine.
> 
> Now you can no longer expect a long running background processes to
> continue after logging out.

Unless you use systemd-run/linger, then you can still expect those
background processes to continue to run.
But I guess this wasn't your point.

 I believe this breaks the expecations of
> many users. For example, you can no longer start a screen or tmux
> session, log out, and expect to come back to it. For this reason, I
> think it is a bad decision on the part of the systemd maintainers to
> enable this feature by default, and it should rather be disabled by
> default in Debian, either by compiling systemd with
> --without-kill-user-processes or by setting KillUserProcesses=no in
> /etc/systemd/logind.conf.

The new requirement of having to enable lingering and starting
tmux/screen/nohup/ via systemd-run can certainly be considered a
nuisance and something our users are not necessarily aware of.
I share that concern.
So a NEWS.Debian entry would be the least we should do. And maybe
documenting it in the release notes.

That all said, we'll discuss that within the team. I couldn't get hold
of Martin on irc, so this might take a couple of days (I won't be around
much over the weekend).
I personally need to do some more research first, e.g. how that affects
systemd/dbus user sessions.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Guus Sliepen]

On Fri, May 27, 2016 at 01:34:09AM +0200, Christian Rebischke wrote:

> Hello,
> You should quote the full changelog and not just
> the part that is 'bad' in your mind.

> >systemd-logind will now by default terminate user processes that are part of
> >the user session scope unit (session-XX.scope) when the user logs out. This
> >behavior is controlled by the KillUserProcesses= setting in logind.conf, and
> >the previous default of "no" is now changed to "yes". 

I mentioned these options later in my bugreport.

> For debian it would be enough to set this to "no" again with 
> --without-kill-user-processes option to "configure"

Yes, I hope the systemd maintainers will indeed make this change.

> >This means that user sessions will be properly cleaned up after, but
> >additional steps are necessary to allow intentionally long-running processes
> >to survive logout.
> 
> Here comes the important part. Seems like the systemd-devs are working on a
> way to allow intentionally long-running processes in a specific user scope.
> 
> And here is another way for allowing these long-running processes:
[...]
> And another way for allowing long-running processes.

You are missing the point. The way people using Linux (or any UNIX for
that matter) have been starting background processes for the last 30
years is to just run it with nohup  & or in a screen session.
Now suddenly systemd wants to change this, by having you jump through
extra hoops. If there was a damn good reason for this, I would maybe
say, ok, migrating to the new way is worth the pain. But I really don't
see what the benefit of this change is, apart from maybe cleaning up
some stray gconf and pulseaudio processes from the list of processes.

But lets talk about the pain: almost noone will read the changelog. You
cannot expect everyone to read every changelog everytime they upgrade
their machine. You cannot expect people to reread the manual of every
program after every update. So even people who have known the workings
of systemd intimately up to version 229 will be taken by surprise by
this change. And when they find out for the first time that their
background processes have been killed, they won't know why. Even if they
make the connection to their logging in and out of sessions, I'd think
that they still don't know that there is something like logind that
manages "user sessions" for them. So they will start blaming other
things, annoying other people, who in turn will finally get annoyed at
systemd.

Especially if you are told that hey, from now on you have to manually
set your user session to linger, or start your program in a separate
user session, or edit some config file as root on every machine you
maintain, I know that I would be very tempted to just type "sudo apt-get
install sysvinit-core", because that is just easier.

> >Previous defaults can be restored at compile time by the
> >--without-kill-user-processes option to "configure"
> 
> You see? No reason to complain about.

What do you mean? There is every reason to complain about this change in
systemd! If noone complained then noone would do anything about it. I'm
complaining so Debian will change the default behaviour, and I'm
complaining so hopefully some systemd developers get a clue that these
kind of changes are not appreciated.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

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

[Andrew Rodland]

>the previous default of "no" is now changed to "yes".

But why exactly has the default been changed to a value that's obviously wrong 
for the majority of Linux systems in existence? Perhaps instead the tiny 
minority of systems that are used in a workstation-like fashion, where this 
behavior might *arguably* make some kind of sense, could set the option to 
yes, and all other systems could benefit from a sensible default that doesn't 
break things for dubious reasons? Just a thought.

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

[Christian Rebischke]

Hello,
You should quote the full changelog and not just
the part that is 'bad' in your mind.

>systemd-logind will now by default terminate user processes that are part of
>the user session scope unit (session-XX.scope) when the user logs out. This
>behavior is controlled by the KillUserProcesses= setting in logind.conf, and
>the previous default of "no" is now changed to "yes". 

For debian it would be enough to set this to "no" again with 
--without-kill-user-processes option to "configure"

>This means that user sessions will be properly cleaned up after, but
>additional steps are necessary to allow intentionally long-running processes
>to survive logout.

Here comes the important part. Seems like the systemd-devs are working on a
way to allow intentionally long-running processes in a specific user scope.

And here is another way for allowing these long-running processes:

>While the user is logged in at least once, user@.service is running, and any
>service that should survive the end of any individual login session can be
>started at a user service or scope using systemd-run.  systemd-run(1) man
>page has been extended with an example which shows how to run screen in a
>scope unit underneath user@.service. The same command works for tmux.

And another way for allowing long-running processes.

>After the user logs out of all sessions, user@.service will be terminated
>too, by default, unless the user has "lingering" enabled.  To effectively
>allow users to run long-term tasks even if they are logged out, lingering
>must be enabled for them. See loginctl(1) for details. The default polkit
>policy was modified to allow users to set lingering for themselves without
>authentication.
>
>Previous defaults can be restored at compile time by the
>--without-kill-user-processes option to "configure"


You see? No reason to complain about.

Best regards

Christian Rebischke.


signature.asc
Description: PGP signature

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

[Michael Biebl]

Am 27.05.2016 um 01:16 schrieb Matt Taggart:
> I found this old link that might help
> 
> Systemd broke nohup?
> https://lwn.net/Articles/556084/
> 
> What happens if you use nohup(1)?

I guess that wouldn't really make a difference.
What makes a difference is when you enable "lingering" for your user,
which tells systemd that there will be long running processes.
See the NEWS file at [1] for further information or the loginctl man
page [2]

Regards,
Michael


[1] https://github.com/systemd/systemd/blob/master/NEWS#L29
[2]
https://www.freedesktop.org/software/systemd/man/loginctl.html#enable-linger%20USER...
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Matt Taggart]

I found this old link that might help

Systemd broke nohup?
https://lwn.net/Articles/556084/

What happens if you use nohup(1)?

-- 
Matt Taggart
tagg...@debian.org

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

[Guus Sliepen]

Package: systemd
Version: 230-1
Severity: normal

>From the changelog of systemd version 230:

> systemd-logind will now by default terminate user processes that are
> part of the user session scope unit (session-XX.scope) when the user
> logs out.

It is now indeed the case that any background processes that were still
running are killed automatically when the user logs out of a session,
whether it was a desktop session, a VT session, or when you SSHed into a
machine.

Now you can no longer expect a long running background processes to
continue after logging out. I believe this breaks the expecations of
many users. For example, you can no longer start a screen or tmux
session, log out, and expect to come back to it. For this reason, I
think it is a bad decision on the part of the systemd maintainers to
enable this feature by default, and it should rather be disabled by
default in Debian, either by compiling systemd with
--without-kill-user-processes or by setting KillUserProcesses=no in
/etc/systemd/logind.conf.

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.114
ii  libacl1 2.2.52-3
ii  libapparmor12.10-4
ii  libaudit1   1:2.5.2-1
ii  libblkid1   2.28-5
ii  libc6   2.22-9
ii  libcap2 1:2.25-1
ii  libcap2-bin 1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.7.0-2
ii  libgpg-error0   1.22-2
ii  libkmod222-1.1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.28-5
ii  libpam0g1.1.8-3.2
ii  libseccomp2 2.3.1-1
ii  libselinux1 2.5-3
ii  libsystemd0 230-1
ii  mount   2.28-5
ii  util-linux  2.28-5

Versions of packages systemd recommends:
ii  dbus1.10.8-1
ii  libpam-systemd  230-1

Versions of packages systemd suggests:
pn  systemd-container  
ii  systemd-ui 3-4

Versions of packages systemd is related to:
ii  udev  230-1

-- Configuration Files:
/etc/systemd/system.conf changed [not included]

-- no debconf information