Debian Bug report logs - #825394
systemd kill background processes after user logs out

version graph

Package: systemd; Maintainer for systemd is Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>; Source for systemd is src:systemd (PTS, buildd, popcon).

Affects: screen

Reported by: Guus Sliepen <guus@debian.org>

Date: Thu, 26 May 2016 16:18:06 UTC

Severity: normal

Merged with 825941

Found in version systemd/230-1

Fixed in version systemd/230-2

Done: Martin Pitt <mpitt@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Thu, 26 May 2016 16:18:10 GMT) (full text, mbox, link).


Acknowledgement sent to Guus Sliepen <guus@debian.org>:
New Bug report received and forwarded. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Thu, 26 May 2016 16:18:10 GMT) (full text, mbox, link).


Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Guus Sliepen <guus@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: systemd kill background processes after user logs out
Date: Thu, 26 May 2016 18:16:09 +0200
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  libapparmor1    2.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  libkmod2        22-1.1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.28-5
ii  libpam0g        1.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  dbus            1.10.8-1
ii  libpam-systemd  230-1

Versions of packages systemd suggests:
pn  systemd-container  <none>
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



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Thu, 26 May 2016 23:18:04 GMT) (full text, mbox, link).


Acknowledgement sent to Matt Taggart <taggart@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Thu, 26 May 2016 23:18:04 GMT) (full text, mbox, link).


Message #10 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>
To: 825394@bugs.debian.org
Subject: Re: systemd kill background processes after user logs out
Date: Thu, 26 May 2016 16:16:19 -0700
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
taggart@debian.org





Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Thu, 26 May 2016 23:39:03 GMT) (full text, mbox, link).


Acknowledgement sent to Christian Rebischke <Christian.Rebischke@tu-clausthal.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Thu, 26 May 2016 23:39:03 GMT) (full text, mbox, link).


Message #15 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Christian Rebischke <Christian.Rebischke@tu-clausthal.de>
To: 825394@bugs.debian.org
Subject: systemd kill background processes after user logs out
Date: Fri, 27 May 2016 01:34:09 +0200
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Thu, 26 May 2016 23:39:06 GMT) (full text, mbox, link).


Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Thu, 26 May 2016 23:39:06 GMT) (full text, mbox, link).


Message #20 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>
To: Matt Taggart <taggart@debian.org>, 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Fri, 27 May 2016 01:35:18 +0200
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Fri, 27 May 2016 04:51:03 GMT) (full text, mbox, link).


Acknowledgement sent to Andrew Rodland <andrew@cleverdomain.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 27 May 2016 04:51:04 GMT) (full text, mbox, link).


Message #25 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Andrew Rodland <andrew@cleverdomain.org>
To: 825394@bugs.debian.org
Subject: Re: systemd kill background processes after user logs out
Date: Fri, 27 May 2016 00:38:59 -0400
>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.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Fri, 27 May 2016 08:21:11 GMT) (full text, mbox, link).


Acknowledgement sent to Guus Sliepen <guus@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 27 May 2016 08:21:13 GMT) (full text, mbox, link).


Message #30 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Guus Sliepen <guus@debian.org>
To: Christian Rebischke <Christian.Rebischke@tu-clausthal.de>
Cc: 825394@bugs.debian.org
Subject: Re: systemd kill background processes after user logs out
Date: Fri, 27 May 2016 10:18:39 +0200
[Message part 1 (text/plain, inline)]
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 <command> & 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 <guus@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Fri, 27 May 2016 09:42:11 GMT) (full text, mbox, link).


Acknowledgement sent to Nicolai Langfeldt <janl@langfeldt.net>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 27 May 2016 09:42:12 GMT) (full text, mbox, link).


Message #35 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Nicolai Langfeldt <janl@langfeldt.net>
To: 825394@bugs.debian.org
Subject: ...
Date: Fri, 27 May 2016 11:32:06 +0200
The principle of least surprise applies.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Fri, 27 May 2016 10:42:43 GMT) (full text, mbox, link).


Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 27 May 2016 10:42:43 GMT) (full text, mbox, link).


Message #40 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>
To: Nicolai Langfeldt <janl@langfeldt.net>, 825394@bugs.debian.org
Subject: Re: Bug#825394: ...
Date: Fri, 27 May 2016 12:28:15 +0200
[Message part 1 (text/plain, inline)]
Am 27.05.2016 um 11:32 schrieb Nicolai Langfeldt:
> The principle of least surprise applies.

Please, this is a bug tracker, not a discussion forum.



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

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Fri, 27 May 2016 12:12:10 GMT) (full text, mbox, link).


Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 27 May 2016 12:12:10 GMT) (full text, mbox, link).


Message #45 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>
To: Guus Sliepen <guus@debian.org>, 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Fri, 27 May 2016 14:09:55 +0200
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Fri, 27 May 2016 13:57:04 GMT) (full text, mbox, link).


Acknowledgement sent to Stefanos Harhalakis <v13@v13.gr>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 27 May 2016 13:57:04 GMT) (full text, mbox, link).


Message #50 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Stefanos Harhalakis <v13@v13.gr>
To: 825394@bugs.debian.org
Subject: Re: systemd kill background processes after user logs out
Date: Fri, 27 May 2016 14:55:59 +0100
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



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sat, 28 May 2016 02:24:04 GMT) (full text, mbox, link).


Acknowledgement sent to georg@schorsch-tech.de:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sat, 28 May 2016 02:24:04 GMT) (full text, mbox, link).


Message #55 received at 825394@bugs.debian.org (full text, mbox, reply):

From: georg@schorsch-tech.de
To: 825394@bugs.debian.org
Subject: Maybe related to this post and bugs
Date: Sat, 28 May 2016 04:13:28 +0200
https://bbs.archlinux.org/viewtopic.php?id=204307

https://bugs.freedesktop.org/show_bug.cgi?id=94508






Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sat, 28 May 2016 02:54:03 GMT) (full text, mbox, link).


Acknowledgement sent to georg@schorsch-tech.de:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sat, 28 May 2016 02:54:03 GMT) (full text, mbox, link).


Message #60 received at 825394@bugs.debian.org (full text, mbox, reply):

From: georg@schorsch-tech.de
To: 825394@bugs.debian.org
Subject: Re: systemd kill background processes after user logs out
Date: Sat, 28 May 2016 04:50:45 +0200
It is most probably related to this

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sat, 28 May 2016 17:18:14 GMT) (full text, mbox, link).


Acknowledgement sent to Zbigniew Gralewski <zbigniew@gralewski.pl>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sat, 28 May 2016 17:18:14 GMT) (full text, mbox, link).


Message #65 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Zbigniew Gralewski <zbigniew@gralewski.pl>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Sat, 28 May 2016 19:08:26 +0200
[Message part 1 (text/plain, inline)]
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
zbigniew@gralewski.pl

	

[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sat, 28 May 2016 18:51:04 GMT) (full text, mbox, link).


Acknowledgement sent to John Brooks <john.lists@fastquake.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sat, 28 May 2016 18:51:04 GMT) (full text, mbox, link).


Message #70 received at 825394@bugs.debian.org (full text, mbox, reply):

From: John Brooks <john.lists@fastquake.com>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Sat, 28 May 2016 14:10:57 -0400
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sat, 28 May 2016 18:51:06 GMT) (full text, mbox, link).


Acknowledgement sent to Joey Hess <id@joeyh.name>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sat, 28 May 2016 18:51:06 GMT) (full text, mbox, link).


Message #75 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <id@joeyh.name>
To: 825394@bugs.debian.org
Subject: shim screen etc?
Date: Sat, 28 May 2016 14:49:41 -0400
[Message part 1 (text/plain, inline)]
Since the number of commands that start such a process is limited to
screen/tmux/nohup, these could just be shimmed to do whatever's
needed to let them keep running past logout.

Course it would make more sense to have a proper API that such programs
can use themselves.

I have tried to develop such a shim:

#!/bin/sh
cmd="$(basename "$0")"
# hardcoded path so this shim can be in eg ~/bin/screen and run the real program
systemd-run -q --scope --user /usr/bin/$cmd "$@"

Difficulties with this as it stands:

* loginctl enable-linger needs to be run before the login session
  in which that shim is used, I think?
* I could not get loginctl enable-linger as user to work when logging into the
  server as over ssh:
    Could not enable linger: The name org.freedesktop.PolicyKit1 was not provided by any .service files
  Running it as root to enable lingering for a user worked.

-- 
see shy jo, adding ! Systemd.killUserProcesses to his propellor config
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sat, 28 May 2016 19:48:07 GMT) (full text, mbox, link).


Acknowledgement sent to John Brooks <john.lists@fastquake.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sat, 28 May 2016 19:48:07 GMT) (full text, mbox, link).


Message #80 received at 825394@bugs.debian.org (full text, mbox, reply):

From: John Brooks <john.lists@fastquake.com>
To: 825394@bugs.debian.org
Subject: Re: shim screen etc?
Date: Sat, 28 May 2016 15:45:28 -0400
> Since the number of commands that start such a process is limited to
> screen/tmux/nohup, these could just be shimmed to do whatever's
> needed to let them keep running past logout.

I think implementing a workaround like that would just confuse the 
situation even more. I can easily imagine hours wasted digging around in 
/etc trying to figure out why some programs work properly and others don't.

> Course it would make more sense to have a proper API that such programs
> can use themselves.

That's an even worse idea, because then we're making programs work 
around systemd's decisions. Interoperability and maintenance nightmare, 
not to mention the numerous philosophical objections I could think of.

If this were a badly needed architectural change, it might be worth 
considering these ideas. But there's so little benefit to this behaviour 
that it's simply not worth making the effort to adapt to.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 29 May 2016 00:03:04 GMT) (full text, mbox, link).


Acknowledgement sent to Josh Triplett <josh@joshtriplett.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 29 May 2016 00:03:04 GMT) (full text, mbox, link).


Message #85 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>
To: 825394@bugs.debian.org
Subject: Re: shim screen etc?
Date: Sat, 28 May 2016 17:00:41 -0700
On Sat, 28 May 2016 14:49:41 -0400 Joey Hess <id@joeyh.name> wrote:
> Since the number of commands that start such a process is limited to
> screen/tmux/nohup, these could just be shimmed to do whatever's
> needed to let them keep running past logout.
> 
> Course it would make more sense to have a proper API that such programs
> can use themselves.
> 
> I have tried to develop such a shim:
> 
> #!/bin/sh
> cmd="$(basename "$0")"
> # hardcoded path so this shim can be in eg ~/bin/screen and run the real program
> systemd-run -q --scope --user /usr/bin/$cmd "$@"

I don't think systemd-run (or transient scopes in general, including
those created by the program natively) are the right solution to this
problem.  Instead, I think screen, tmux, a VNC server, or any other
command that runs a user session independent of the one it was called
from, should be invoking PAM to start a new session.  The PAM session
machinery would then run pam_systemd, which would register with logind.

PAM is the right way to start a new user session.  And in addition to
providing a solution that isn't systemd-specific, this also integrates
with any other session mechanism as well.  For instance, if you use PAM
to manage agents for SSH or similar, this solves the problem of screen
having SSH_AUTH_SOCK point to a stale SSH agent that died with the
session screen started from.

I would suggest adding PAM session support to screen.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 29 May 2016 01:03:03 GMT) (full text, mbox, link).


Acknowledgement sent to mots <mots@nepu.moe>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 29 May 2016 01:03:03 GMT) (full text, mbox, link).


Message #90 received at 825394@bugs.debian.org (full text, mbox, reply):

From: mots <mots@nepu.moe>
To: 825394@bugs.debian.org <825394@bugs.debian.org>
Subject: Get rid of systemd.
Date: Sun, 29 May 2016 02:52:07 +0200
[Message part 1 (text/plain, inline)]
An easy fix is to change the default init system to the superior System V init.
[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 29 May 2016 09:15:03 GMT) (full text, mbox, link).


Acknowledgement sent to Martin Pitt <mpitt@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 29 May 2016 09:15:03 GMT) (full text, mbox, link).


Message #95 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>
To: Michael Biebl <biebl@debian.org>, 825394@bugs.debian.org
Cc: Guus Sliepen <guus@debian.org>
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Sun, 29 May 2016 11:13:32 +0200
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 29 May 2016 09:48:14 GMT) (full text, mbox, link).


Acknowledgement sent to Guus Sliepen <guus@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 29 May 2016 09:48:14 GMT) (full text, mbox, link).


Message #100 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Guus Sliepen <guus@debian.org>
To: Martin Pitt <mpitt@debian.org>
Cc: Michael Biebl <biebl@debian.org>, 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Sun, 29 May 2016 11:46:36 +0200
[Message part 1 (text/plain, inline)]
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 <guus@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 29 May 2016 19:21:13 GMT) (full text, mbox, link).


Acknowledgement sent to John Brooks <john@fastquake.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 29 May 2016 19:21:13 GMT) (full text, mbox, link).


Message #105 received at 825394@bugs.debian.org (full text, mbox, reply):

From: John Brooks <john@fastquake.com>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Sun, 29 May 2016 14:56:30 -0400
On Sun, 29 May 2016 11:46:36 +0200 Guus Sliepen <guus@debian.org> 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 <mpitt@debian.org> 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.



Added tag(s) pending. Request was from Martin Pitt <martin.pitt@ubuntu.com> to control@bugs.debian.org. (Sun, 29 May 2016 20:48:04 GMT) (full text, mbox, link).


Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 29 May 2016 21:51:07 GMT) (full text, mbox, link).


Acknowledgement sent to Renaud Allard <renaud@allard.it>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 29 May 2016 21:51:07 GMT) (full text, mbox, link).


Message #112 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Renaud Allard <renaud@allard.it>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Sun, 29 May 2016 23:40:06 +0200
[Message part 1 (text/plain, inline)]
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 (application/pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 03:39:13 GMT) (full text, mbox, link).


Acknowledgement sent to Vladimir K <pzs-fs@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 03:39:13 GMT) (full text, mbox, link).


Message #117 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Vladimir K <pzs-fs@yandex.ru>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 06:34:44 +0300
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.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 04:09:04 GMT) (full text, mbox, link).


Acknowledgement sent to Lawrence D'Oliveiro <ldo@geek-central.gen.nz>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 04:09:04 GMT) (full text, mbox, link).


Message #122 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Lawrence D'Oliveiro <ldo@geek-central.gen.nz>
To: 825394@bugs.debian.org
Subject: Re: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 15:57:01 +1200
Does setsid(1) still work? I read over this
<https://www.freedesktop.org/software/systemd/man/logind.conf.html>
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.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 07:51:04 GMT) (full text, mbox, link).


Acknowledgement sent to Antonio <antviro@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 07:51:04 GMT) (full text, mbox, link).


Message #127 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Antonio <antviro@gmail.com>
To: 825394@bugs.debian.org
Subject: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 09:47:49 +0200
[Message part 1 (text/plain, inline)]
>
>  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
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 09:51:16 GMT) (full text, mbox, link).


Acknowledgement sent to Shish <shish@shishnet.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 09:51:16 GMT) (full text, mbox, link).


Message #132 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Shish <shish@shishnet.org>
To: 825394@bugs.debian.org
Subject: also mosh
Date: Mon, 30 May 2016 10:46:42 +0100
`mosh-server` should be added to the list of processes which should be
exempt from this behaviour, as it is based on the principle of "ssh
into remote host, start daemon, exit ssh, continue speaking to
daemon".

As a workaround, I'm running it in a new session explicitly:

  mosh --server "systemd-run --scope --user mosh-server" $hostname

To make this more googlable, the error message which happens when
systemd kills mosh-server is:

  mosh: Nothing received from server on UDP port 60001. [To quit: Ctrl-^ .]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 13:42:03 GMT) (full text, mbox, link).


Acknowledgement sent to John Brooks <john@fastquake.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 13:42:03 GMT) (full text, mbox, link).


Message #137 received at 825394@bugs.debian.org (full text, mbox, reply):

From: John Brooks <john@fastquake.com>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394: also mosh
Date: Mon, 30 May 2016 09:39:36 -0400
On 05/30/2016 05:46 AM, Shish wrote:
> `mosh-server` should be added to the list of processes which should be
> exempt from this behaviour, as it is based on the principle of "ssh
> into remote host, start daemon, exit ssh, continue speaking to
> daemon".
>
> As a workaround, I'm running it in a new session explicitly:
>
>    mosh --server "systemd-run --scope --user mosh-server" $hostname
>
> To make this more googlable, the error message which happens when
> systemd kills mosh-server is:
>
>    mosh: Nothing received from server on UDP port 60001. [To quit: Ctrl-^ .]
>

And here's another example of why exempting/shimming certain processes 
(or waiting for them to be patched) is a bad workaround. Any number of 
programs could be affected by this, and not all of them are still 
actively developed.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 14:03:04 GMT) (full text, mbox, link).


Acknowledgement sent to Vitaliyi <imgrey@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 14:03:04 GMT) (full text, mbox, link).


Message #142 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Vitaliyi <imgrey@gmail.com>
To: 825394@bugs.debian.org
Date: Mon, 30 May 2016 14:59:53 +0100
[Message part 1 (text/plain, inline)]
ROFLCOPTER.

This is the funnies bug that I remember in Debian.

Debian, please get rid of that crap systemd.
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 14:03:06 GMT) (full text, mbox, link).


Acknowledgement sent to Lars Grundei <l.grundei@meteocontrol.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 14:03:06 GMT) (full text, mbox, link).


Message #147 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Lars Grundei <l.grundei@meteocontrol.de>
To: "825394@bugs.debian.org" <825394@bugs.debian.org>
Subject: What a pain
Date: Mon, 30 May 2016 15:50:11 +0200
[Message part 1 (text/plain, inline)]
What a pain! Turn this "feature" off, an application should not try to fix
errors from other applications, what a mess

Cheers
Lars
[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 14:12:03 GMT) (full text, mbox, link).


Acknowledgement sent to John Brooks <john@fastquake.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 14:12:03 GMT) (full text, mbox, link).


Message #152 received at 825394@bugs.debian.org (full text, mbox, reply):

From: John Brooks <john@fastquake.com>
To: Vitaliyi <imgrey@gmail.com>, 825394@bugs.debian.org
Subject: Re: Bug#825394:
Date: Mon, 30 May 2016 10:08:08 -0400
On 05/30/2016 09:59 AM, Vitaliyi wrote:
> ROFLCOPTER.
>
> This is the funnies bug that I remember in Debian.
>
> Debian, please get rid of that crap systemd.
>

Please try to be constructive and contribute to useful, mature discourse 
when making comments here.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 14:18:06 GMT) (full text, mbox, link).


Acknowledgement sent to Martin Pitt <mpitt@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 14:18:06 GMT) (full text, mbox, link).


Message #157 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394:
Date: Mon, 30 May 2016 16:16:22 +0200
Hello all,

Pretty please stop all the ranting and "me too"s. The option has
already be reverted in the packaging git. This isn't an exercise in
"who shouts the loudest".

Thanks,

Martin

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



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 18:33:06 GMT) (full text, mbox, link).


Acknowledgement sent to martin f krafft <madduck@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 18:33:06 GMT) (full text, mbox, link).


Message #162 received at 825394@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>
To: Martin Pitt <mpitt@debian.org>, 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 20:30:03 +0200
[Message part 1 (text/plain, inline)]
also sprach Martin Pitt <mpitt@debian.org> [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 <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
[digital_signature_gpg.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 20:21:03 GMT) (full text, mbox, link).


Acknowledgement sent to John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 20:21:04 GMT) (full text, mbox, link).


Message #167 received at 825394@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: martin f krafft <madduck@debian.org>
Cc: Martin Pitt <mpitt@debian.org>, 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 22:19:48 +0200
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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 20:54:03 GMT) (full text, mbox, link).


Acknowledgement sent to Iustin Pop <iustin@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 20:54:03 GMT) (full text, mbox, link).


Message #172 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Iustin Pop <iustin@debian.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, 825394@bugs.debian.org
Cc: martin f krafft <madduck@debian.org>, Martin Pitt <mpitt@debian.org>
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 22:52:05 +0200
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



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 20:57:03 GMT) (full text, mbox, link).


Acknowledgement sent to martin f krafft <madduck@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 20:57:03 GMT) (full text, mbox, link).


Message #177 received at 825394@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 22:55:33 +0200
[Message part 1 (text/plain, inline)]
also sprach John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> [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 <madduck@d.o> @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 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 21:33:05 GMT) (full text, mbox, link).


Acknowledgement sent to John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 21:33:05 GMT) (full text, mbox, link).


Message #182 received at 825394@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Iustin Pop <iustin@debian.org>, 825394@bugs.debian.org, martin f krafft <madduck@debian.org>, Martin Pitt <mpitt@debian.org>
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 23:30:27 +0200
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@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 21:57:03 GMT) (full text, mbox, link).


Acknowledgement sent to martin f krafft <madduck@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 21:57:03 GMT) (full text, mbox, link).


Message #187 received at 825394@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Mon, 30 May 2016 23:54:14 +0200
[Message part 1 (text/plain, inline)]
also sprach John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> [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 <madduck@d.o> @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 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 30 May 2016 23:15:06 GMT) (full text, mbox, link).


Acknowledgement sent to erdnaxeli <erdnaxeli@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 30 May 2016 23:15:06 GMT) (full text, mbox, link).


Message #192 received at 825394@bugs.debian.org (full text, mbox, reply):

From: erdnaxeli <erdnaxeli@gmail.com>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Tue, 31 May 2016 01:12:10 +0200
[Message part 1 (text/plain, inline)]
On Mon, 30 May 2016 22:19:48 +0200 John Paul Adrian Glaubitz <
glaubitz@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
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Tue, 31 May 2016 03:48:04 GMT) (full text, mbox, link).


Acknowledgement sent to Duraid Madina <duraid@octopus.com.au>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Tue, 31 May 2016 03:48:04 GMT) (full text, mbox, link).


Message #197 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Duraid Madina <duraid@octopus.com.au>
To: 825394@bugs.debian.org
Subject: Re: systemd kill background processes after user logs out
Date: Tue, 31 May 2016 13:36:05 +1000
If there were ever any doubt, this surely settles it:

systemd truly is the pulseaudio of process control!




Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Tue, 31 May 2016 06:33:03 GMT) (full text, mbox, link).


Acknowledgement sent to debian@jack.fr.eu.org:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Tue, 31 May 2016 06:33:03 GMT) (full text, mbox, link).


Message #202 received at 825394@bugs.debian.org (full text, mbox, reply):

From: debian@jack.fr.eu.org
To: 825394@bugs.debian.org
Subject: Re: systemd kill background processes after user logs out
Date: Tue, 31 May 2016 08:26:00 +0200
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)



Reply sent to Martin Pitt <mpitt@debian.org>:
You have taken responsibility. (Tue, 31 May 2016 11:27:11 GMT) (full text, mbox, link).


Notification sent to Guus Sliepen <guus@debian.org>:
Bug acknowledged by developer. (Tue, 31 May 2016 11:27:11 GMT) (full text, mbox, link).


Message #207 received at 825394-close@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>
To: 825394-close@bugs.debian.org
Subject: Bug#825394: fixed in systemd 230-2
Date: Tue, 31 May 2016 11:24:35 +0000
Source: systemd
Source-Version: 230-2

We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 825394@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin Pitt <mpitt@debian.org> (supplier of updated systemd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 31 May 2016 12:02:14 +0200
Source: systemd
Binary: systemd systemd-sysv systemd-container systemd-journal-remote systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines libnss-resolve libsystemd0 libsystemd-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb
Architecture: source amd64
Version: 230-2
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Martin Pitt <mpitt@debian.org>
Description:
 libnss-myhostname - nss module providing fallback resolution for the current hostname
 libnss-mymachines - nss module to resolve hostnames for local container instances
 libnss-resolve - nss module to resolve names via systemd-resolved
 libpam-systemd - system and service manager - PAM module
 libsystemd-dev - systemd utility library - development files
 libsystemd0 - systemd utility library
 libudev-dev - libudev development files
 libudev1   - libudev shared library
 libudev1-udeb - libudev shared library (udeb)
 systemd    - system and service manager
 systemd-container - systemd container/nspawn tools
 systemd-coredump - tools for storing and retrieving coredumps
 systemd-journal-remote - tools for sending and receiving remote journal logs
 systemd-sysv - system and service manager - SysV links
 udev       - /dev/ and hotplug management daemon
 udev-udeb  - /dev/ and hotplug management daemon (udeb)
Closes: 825394
Changes:
 systemd (230-2) unstable; urgency=medium
 .
   [ Martin Pitt ]
   * Don't add a Breaks: against usb-modeswitch when building on Ubuntu; there
     it does not use hotplug.functions and is a lower version.
   * boot-and-services autopkgtest: Add missing xserver-xorg and
     lightdm-greeter test dependencies, so that lightdm can start.
     (See LP #1581106)
   * Re-disable logind's KillUserProcesses option by default. (Closes: #825394)
 .
   [ Michael Biebl ]
   * Drop --disable-silent-rules from debian/rules. This is now handled by dh
     directly depending on whether the DH_QUIET environment variable is set.
Checksums-Sha1:
 82a7239fcb560de410191697308c4f7747e18819 4016 systemd_230-2.dsc
 4b55c5aa9157fb4d1289851f27cd3a29ece1b76c 122492 systemd_230-2.debian.tar.xz
 126ef617ce08f53976ee0580b58846885f829cde 85898 libnss-myhostname-dbgsym_230-2_amd64.deb
 1f34fd97f21e62889d2a1b4c26fcd5b92b5e786c 89516 libnss-myhostname_230-2_amd64.deb
 f43a2143b8a0797191a061a7cc13e8fbcf27c18e 418730 libnss-mymachines-dbgsym_230-2_amd64.deb
 fc279cd8d67370ceca523be11697fdf9b72489e3 169932 libnss-mymachines_230-2_amd64.deb
 866e45690dded77bf9d64b043bce68b81c5bbea2 416360 libnss-resolve-dbgsym_230-2_amd64.deb
 4b3aae2b92b88860aae99552291b5d9300b31394 169340 libnss-resolve_230-2_amd64.deb
 390799a4f9ecffa956e10b87c86c553faefef202 421112 libpam-systemd-dbgsym_230-2_amd64.deb
 d85464bc805a358f90e20d122341644b043b5cdf 171990 libpam-systemd_230-2_amd64.deb
 8671f713b4074286fc051126bc20fcbfdb013e70 214822 libsystemd-dev_230-2_amd64.deb
 1b631c6f1d3fbd1fd8119b5150ea14627959380d 651162 libsystemd0-dbgsym_230-2_amd64.deb
 98f9741a1f69beb17a98a12d9989521ad46eeec0 261646 libsystemd0_230-2_amd64.deb
 f3a123bf7bcb5542a56e42e7dd1ad5170c126323 434024 libudev-dev-dbgsym_230-2_amd64.deb
 ebbbe5eaaa3cd38dcd261cc9f4add6249c8fafa7 211842 libudev-dev_230-2_amd64.deb
 60af5ef5f5ab7db1c4a09fb5216a2f5e1e3fc1e7 154926 libudev1-dbgsym_230-2_amd64.deb
 746e65b2ddd19564dc2dbb8b731b00d90f2b7d29 47766 libudev1-udeb_230-2_amd64.udeb
 9c4a652c2d994cf977417a53abce0ba825d47473 108262 libudev1_230-2_amd64.deb
 e0e7ee4dea736d68485e53b308005c4a1ee5cd2e 3287560 systemd-container-dbgsym_230-2_amd64.deb
 4516d1769b4783e04cff910d2b5606c80ff34114 730744 systemd-container_230-2_amd64.deb
 cb19accf2ae8eaeaadc2b0f71686a5699bfcb3de 370912 systemd-coredump-dbgsym_230-2_amd64.deb
 565627be1576060ef0e5401241f98fd85c40ef78 167472 systemd-coredump_230-2_amd64.deb
 5ba1c722bda10ef2a883368a887df558c2207f0e 20020734 systemd-dbgsym_230-2_amd64.deb
 af0ae82265996be7cf68e5c775bc49dc9f189671 1115274 systemd-journal-remote-dbgsym_230-2_amd64.deb
 f412ceb96288826f4c7c562902320a62e73fef17 323892 systemd-journal-remote_230-2_amd64.deb
 7cf92fd6a2a04a6cd51250d6ae9b8cd49b63e447 65582 systemd-sysv_230-2_amd64.deb
 6fe5f69d69270e9373b8408ce7920d8fe62ec495 3679480 systemd_230-2_amd64.deb
 1a28fdc41d55485653f3450922fe15533c96126c 1295114 udev-dbgsym_230-2_amd64.deb
 4ec0f1102cb8e4e73f113ab19147692c600f5328 269806 udev-udeb_230-2_amd64.udeb
 6f152e72f26c26eb15ed11ebe6eb403248da87b0 1058164 udev_230-2_amd64.deb
Checksums-Sha256:
 ff58aa583e6e885d4125b8b901064c66f1a81069d01e6a5c35b014d73f6994ee 4016 systemd_230-2.dsc
 2eddbb821044773998a45c751dc82a93d3382b2008df7fae70a2cf9bf2ffe648 122492 systemd_230-2.debian.tar.xz
 999bcb020676a181452e5625f29b67d97737e876d07288e0348865c94e1969d9 85898 libnss-myhostname-dbgsym_230-2_amd64.deb
 56e74f93ba885385f7950f8222bd026588041ef06e9fc75163fabc4dbac9b1b5 89516 libnss-myhostname_230-2_amd64.deb
 d502558d8037d1fd4bc48dd7d6f89be4a92e2f21b5221df4bed788167fa55f2c 418730 libnss-mymachines-dbgsym_230-2_amd64.deb
 14d9307bcfbc284efeda8ecbc9b49a64aa786c755a860f89e80efc67428cf185 169932 libnss-mymachines_230-2_amd64.deb
 ccca15ad2d070a46c4414ce3ed863169669006f88aafeb577235fc885815a52c 416360 libnss-resolve-dbgsym_230-2_amd64.deb
 46a3071c7df65fd8b6bd141f2def167c58087155d8bf38801ef68d4aa00478db 169340 libnss-resolve_230-2_amd64.deb
 85014b6cb2dbb97ea50574846455fb4eda44ba60e93749784c88bab7ab4a75d1 421112 libpam-systemd-dbgsym_230-2_amd64.deb
 c23ff12b92846a45207e0eda2abd15d62313fcae56821a5df928f08e4dbaf2f0 171990 libpam-systemd_230-2_amd64.deb
 0d35be26a9be27ed612c01c4c3fd51b7defb9856a9304cf3ce3071e582511a3a 214822 libsystemd-dev_230-2_amd64.deb
 82e56f176692335ae577c302fa1e79f3fdf5cae771ce5b167e964f2c125b927b 651162 libsystemd0-dbgsym_230-2_amd64.deb
 c0b4e76202addd37a1e456b43f2d76815db03d80ea1be02ae3f03c7f6b958d3f 261646 libsystemd0_230-2_amd64.deb
 56f4063d39066dcb21dee7cdc00ef536b202d12c39b5666b4743d77b5cae372c 434024 libudev-dev-dbgsym_230-2_amd64.deb
 a43166dd79826e154d1ea84799c4c7ed059ccec8c0ccfe63749136f02ecfd6af 211842 libudev-dev_230-2_amd64.deb
 db1229251c622adf296ad68f8d46cb3d3635f6a03be03b71ac721cd5bf935915 154926 libudev1-dbgsym_230-2_amd64.deb
 72f16028328854cc9ed94570ad96f19968b1d59aa792d1097d88977c7f639305 47766 libudev1-udeb_230-2_amd64.udeb
 079cf80fc491bbf0c1b1ef58c7923923955ab2b52073c39f450ec7f3f5e2ba64 108262 libudev1_230-2_amd64.deb
 76f0da611a45d80f343ca37f950102146397e58bc89cc206ec301abe2f0b15e1 3287560 systemd-container-dbgsym_230-2_amd64.deb
 f36c26f2516930ceed2bcf01074435b99e3840fb374db0ac5cf4c3b78de2c7bb 730744 systemd-container_230-2_amd64.deb
 3189f260e81d973a6a5716b26d96181c3bd63a24cb4195aad77882d56d10c486 370912 systemd-coredump-dbgsym_230-2_amd64.deb
 858b8c424dcf91347c73997e92f1e615ff273852ccb8c00b799b549a1a7486ba 167472 systemd-coredump_230-2_amd64.deb
 cf55c542aac11de227f5d0ba267f96f214237ab068b4344943dc6d687fa41fcf 20020734 systemd-dbgsym_230-2_amd64.deb
 25e2285dae74e1d8f9906b54d29b1ef6f30f3a4cf1e87ff5a025d72737740bb5 1115274 systemd-journal-remote-dbgsym_230-2_amd64.deb
 bca350e5ef6e1e4a9acace659772d1e08bd578690b0bfdf0c12986d13f3ebbd6 323892 systemd-journal-remote_230-2_amd64.deb
 e6b7bfd7015dd7ae3ea3edf908c93a53ee794d356c99023e73a0fd4e798bf104 65582 systemd-sysv_230-2_amd64.deb
 45777cffc4352980aea5bd44ef97d7e87f4cfac4687ab31a9890eca8012c9662 3679480 systemd_230-2_amd64.deb
 55e8fc70e623ce22f51e79213e3138bbfa7963596eda103f1f2504d9f230e23a 1295114 udev-dbgsym_230-2_amd64.deb
 75fa6221a9e3859056f2c2c101cb068a487ff7e40cb1ff33463536f31e431a56 269806 udev-udeb_230-2_amd64.udeb
 6d30f7dcae4c32fd1d6406ae71dda35cad949f4df8191ea3bfd791eaf5b48850 1058164 udev_230-2_amd64.deb
Files:
 0ab52f253311959ebdec76bc6ada240f 4016 admin optional systemd_230-2.dsc
 31ef78c5a14920ad4648d1f5258980e7 122492 admin optional systemd_230-2.debian.tar.xz
 2f1564b1ca2df9e687e01dc41517cf56 85898 debug extra libnss-myhostname-dbgsym_230-2_amd64.deb
 06ae949163c836bb7c09000be6e76f62 89516 admin extra libnss-myhostname_230-2_amd64.deb
 46e2ddedbb17bffb49c5eb9f72f66d84 418730 debug extra libnss-mymachines-dbgsym_230-2_amd64.deb
 6a5095cec5d7f6980cc89f163337b7e1 169932 admin extra libnss-mymachines_230-2_amd64.deb
 6fc1d9c16ce1cd73f5e6112ea29dfa29 416360 debug extra libnss-resolve-dbgsym_230-2_amd64.deb
 5ca616790ff49f4147fd8b04b9e136c2 169340 admin extra libnss-resolve_230-2_amd64.deb
 165e26fdaceab7e9d76ae2af8464be90 421112 debug extra libpam-systemd-dbgsym_230-2_amd64.deb
 e129de489a5a584d2a17fb76b038b24b 171990 admin optional libpam-systemd_230-2_amd64.deb
 395fff9f6556d5b2a14ae41d930adbe1 214822 libdevel optional libsystemd-dev_230-2_amd64.deb
 2a31975be075879404db217eaf962c4b 651162 debug extra libsystemd0-dbgsym_230-2_amd64.deb
 a40ba6e0ce64b2957982b6056ed63d19 261646 libs optional libsystemd0_230-2_amd64.deb
 3c4d6c4ac423f775e381a6d0403510e4 434024 debug extra libudev-dev-dbgsym_230-2_amd64.deb
 74a03961a1b7cead5194c08d69a049c7 211842 libdevel optional libudev-dev_230-2_amd64.deb
 3f182a7b4aef2089eda924973023b272 154926 debug extra libudev1-dbgsym_230-2_amd64.deb
 269b047e91968b9e89e91f1e4402d4fd 47766 debian-installer optional libudev1-udeb_230-2_amd64.udeb
 de8210e36eb7196656296da3c788e8d8 108262 libs important libudev1_230-2_amd64.deb
 8aeb438c8aeb105c0123f34e568f8b45 3287560 debug extra systemd-container-dbgsym_230-2_amd64.deb
 953755d023a3fa1de44fa5f58f67d1c1 730744 admin optional systemd-container_230-2_amd64.deb
 67e992b4c685c001885b0a8778e47fc1 370912 debug extra systemd-coredump-dbgsym_230-2_amd64.deb
 ecdfd14cc96ae36d98ae23b96691e9d6 167472 admin optional systemd-coredump_230-2_amd64.deb
 258ae055683086b4f405d182d8d52382 20020734 debug extra systemd-dbgsym_230-2_amd64.deb
 c843ace44452192d2c4164ee62347cd5 1115274 debug extra systemd-journal-remote-dbgsym_230-2_amd64.deb
 3fbb87f406495cada1cf997d60e35598 323892 admin optional systemd-journal-remote_230-2_amd64.deb
 7ec3ad2decd3ad6486ef829c33e3ab61 65582 admin important systemd-sysv_230-2_amd64.deb
 57a1c062c5591c23524d705957686cb6 3679480 admin important systemd_230-2_amd64.deb
 864fbe2a6e31e11f14a3647ead20595e 1295114 debug extra udev-dbgsym_230-2_amd64.deb
 23a4cafe1bed1352b657e8c50d3d11ea 269806 debian-installer optional udev-udeb_230-2_amd64.udeb
 68077fe35041a3b725011fd572d19078 1058164 admin important udev_230-2_amd64.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXTW35AAoJENFO8V2v4RNH9YEQAIK8IHnBGgTdUOplElG5BHS7
cmpu1yRahlOwtWwr2iFWECu/JOZfLK0ZL/a3wW+uAimgiYXJv1vthVOw7rgaMKab
NBGzrfVPMrW39xpqmgooLnuoBAvf5hmS6neJbM1dMh4jhSLfBcqVL8sRyTwI1U51
XRcfrBv3jMVDlT8UUx/mzqNwgshP1QlR6rp4AEGGTnWiIGcyGeMUPX8TxI5tpxcO
wSGy2WaHR5xqFE+CcJaIJg+2ufhiuINzEuwDhePbX02r8mbLDUCXYF67tuVT9ydR
fcPGs87mhxnd8Toix9JSTS2hXYzdLh7+JYDPD2e73eRvMMwBu1eZTHDVOJhNRs+h
jML7OoE9OOFkQXbojxZ+QyspBdntdSBGaP7sPOdso1rG9IeUOSOCOsrqDgm80ADU
Vd1YfSPs/F4nWboCMSwAqsQNFUzdPENyym9DjmF+dP6pceE9s+1VO9ZckoN5MO5I
Ej2wSyrFuUTfkEwJSz2KzeiMydtCyEvhBR4R/j67DQi/XbIaCm7s4GgmowRzGVie
kfwW5bdALL2TW5lI9nKsbDGOerFVybqYLv/ydubtYM8KQsJKNHrHjZOLjkmGuyRa
NcSftYJbkbzmJa8QMAYg8zsNDyPI/P3DeRBUBTLlrg/IUS6KKq3hahN/G3aBnnFD
zhw2+bPKLEwcObbcvksT
=1Vd7
-----END PGP SIGNATURE-----




Merged 825394 825941 Request was from Axel Beckert <abe@debian.org> to 825941-submit@bugs.debian.org. (Tue, 31 May 2016 16:33:16 GMT) (full text, mbox, link).


Added indication that 825394 affects screen Request was from Axel Beckert <abe@debian.org> to control@bugs.debian.org. (Tue, 31 May 2016 16:39:07 GMT) (full text, mbox, link).


Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Wed, 01 Jun 2016 07:00:04 GMT) (full text, mbox, link).


Acknowledgement sent to georg@schorsch-tech.de:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Wed, 01 Jun 2016 07:00:04 GMT) (full text, mbox, link).


Message #216 received at 825394@bugs.debian.org (full text, mbox, reply):

From: georg@schorsch-tech.de
To: 825394@bugs.debian.org
Subject: Re: [libcaf-dev] Fails to link example 'dining_philosophers'
Date: Wed, 1 Jun 2016 08:55:52 +0200
a self compiled Version of libcaf links perfectly. Also the example taken
from
https://raw.githubusercontent.com/actor-framework/actor-framework/0.13.2/examples/message_passing/dining_philosophers.cpp

is the same as the submitted example. So it seems it is related to the C++
ABI change. Maybe, the package could be updated to 0.14.5.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Wed, 01 Jun 2016 21:24:03 GMT) (full text, mbox, link).


Acknowledgement sent to Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Wed, 01 Jun 2016 21:24:04 GMT) (full text, mbox, link).


Message #221 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com>
To: 825394@bugs.debian.org
Subject: Bug#825394: systemd kills background processes after user logs out
Date: Wed, 1 Jun 2016 22:15:59 +0100
Martin Pitt:
> The option has already be reverted in the packaging git.
> This isn't an exercise in "who shouts the loudest".

It should, however, be an exercise in fixing bugs properly.  (-:

Turning off the enabling flag doesn't fix the underlying flawed 
mechanism.  There is still a logind bug to be fixed.

logind has invented its own systemd login session mechanism (as a "scope 
unit") .  It adds processes to a systemd login session. There's a moral 
equivalent of session leadership.  Systemd login sessions close.  At 
session closure, other processes in the session are sent a signal.  So 
far, this is reinventing the kernel's login session concept (as 
augmented by some job control shells) quite straightforwardly.

The bug is a very simple one.  systemd *sends the wrong signal* when it 
is decided that the session is closing.  It should send SIGHUP. It 
instead sends SIGTERM and then sends SIGKILL.  However, logind is the 
locus of the bug because it is logind that is constructing the login 
session and instructing systemd what to do, via the internal systemd 
Desktop Bus protocol.  It's as simple as that.

Send SIGHUP instead of SIGTERM+SIGKILL at systemd login session closure, 
and systemd and logind will continue to interoperate with wget, deluged, 
mosh-server, emacs --daemon, screen, tmux, and all of the rest — 
including anything invoked via nohup.  The DBUS server programs (in 
Freedesktop bug #94508) that are staying alive in the systemd login 
session because of a circular dependency receive a SIGHUP, which 
terminates them and breaks the circle.  The programs (in this bug and 
bug #825941) that have masked/ignored SIGHUP, because that's been the 
protocol for the past 37 years or more (since 7th Edition at minimum), 
avoid termination as they desire.

There are two ways to fix this that I can see.

The first way is to fix the systemd login session so that systemd 
terminates it with SIGHUP.  systemd is told what the "stop" action is 
for the session by logind.  At the moment, in your manager_start_scope() 
function, logind is creating the systemd login session with the 
equivalent of

>    KillSignal=SIGTERM
>    SendSIGHUP=yes
>    SendSIGKILL=yes

Modify that function to instead use the equivalent of

>    KillSignal=SIGHUP
>    SendSIGHUP=yes
>    SendSIGKILL=no

This is an inferior route, in my view, to the second way of doing this.  
The second way of doing this is for logind not to try to *stop* the 
login session in the first place.  Leave that to system shutdown and 
suchlike, which can use "StopUnit" and the resultant SIGTERMs+SIGKILLs 
in circumstances where those are actually appropriate even to nohupped 
processes.  Rather, modify your session_stop_scope() function to call a 
new manager_hangup_scope() function, which invokes "KillUnit" on the 
login session with a kill-who of "all" and a kill-signal of SIGHUP.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 05 Jun 2016 00:15:03 GMT) (full text, mbox, link).


Acknowledgement sent to <brendan.halpin@ul.ie>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 05 Jun 2016 00:15:03 GMT) (full text, mbox, link).


Message #226 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Brendan Halpin <brendan.halpin@ul.ie>
To: <825394@bugs.debian.org>
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Sun, 5 Jun 2016 00:57:20 +0100
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.halpin@ul.ie    ULSociology on Facebook: http://on.fb.me/fjIK9t
http://teaching.sociology.ul.ie/bhalpin/wordpress         twitter:@ULSociology



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 05 Jun 2016 02:03:03 GMT) (full text, mbox, link).


Acknowledgement sent to John Brooks <john@fastquake.com>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 05 Jun 2016 02:03:03 GMT) (full text, mbox, link).


Message #231 received at 825394@bugs.debian.org (full text, mbox, reply):

From: John Brooks <john@fastquake.com>
To: brendan.halpin@ul.ie, 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kill background processes after user logs out
Date: Sat, 4 Jun 2016 22:01:36 -0400
[Message part 1 (text/plain, inline)]
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

[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 05 Jun 2016 07:48:06 GMT) (full text, mbox, link).


Acknowledgement sent to Vladimir K <pzs-fs@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 05 Jun 2016 07:48:06 GMT) (full text, mbox, link).


Message #236 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Vladimir K <pzs-fs@yandex.ru>
To: 825394@bugs.debian.org
Subject: Re: Bug#825394: systemd kills background processes after user logs out
Date: Sun, 05 Jun 2016 10:31:24 +0300
@Jonathan de Boyne Pollard
SIGHUP behavior you've described seems like the proper logical solution. Was it ever explicitly submitted upstream?



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 06 Jun 2016 13:45:07 GMT) (full text, mbox, link).


Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 06 Jun 2016 13:45:07 GMT) (full text, mbox, link).


Message #241 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Marc Lehmann <schmorp@schmorp.de>
To: 825394@bugs.debian.org
Cc: 824931@bugs.debian.org
Subject: similar to bug #824931
Date: Mon, 6 Jun 2016 15:28:48 +0200
I just wanted to add a note that this bug is very similar to bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824931 in openbsd-inet.

There also, only when running under systemd, all processes started
directly or indirectly via inetd get killed (for example, when I apt-get
install'd rlinetd to avoid this behaviour, automount, mysql, a backup
running in screen that was started some days ago and the apt-get doing
the rlinetd install itself were all killed because they were started
indirectly via inetd, and killed when the uninstalling process stopped
inetd).

The maintainer already said that this is the correct behaviour, so this
kind of disruption is likely going to become part of debian gnu/linux on
multiple levels now.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 06 Jun 2016 14:39:09 GMT) (full text, mbox, link).


Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 06 Jun 2016 14:39:09 GMT) (full text, mbox, link).


Message #246 received at 825394@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)
To: Marc Lehmann <schmorp@schmorp.de>, 824931@bugs.debian.org
Cc: 825394@bugs.debian.org
Subject: Re: Bug#824931: similar to bug #824931
Date: Mon, 6 Jun 2016 16:37:32 +0200
[Message part 1 (text/plain, inline)]
On Jun 06, Marc Lehmann <schmorp@schmorp.de> wrote:

> The maintainer already said that this is the correct behaviour, so this
No, I did not: I explained that I wanted to better understand your setup 
to determine what the default semantics should be.
In the case of #824931 the problem is that it is login and not telnetd 
which creates the new user session, so the telnet daemon is left in the 
inetd cgroup and killed along with it.

While I still think that this would be the most generally useful 
semantics for other inetd-started daemons, I can see how it could 
surprise telnet/rsh users.

Since I am not sure if there is a simple solution that could be 
implemented in the telnetd package, at this point I am considering to 
set KillMode=process as the default for openbsd-inetd.

OTOH, I am not sure that this use (corner) case of telnet/rsh users is 
more important than the others, even if the current default is 
a regression for them, so I am still undecided...

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Mon, 06 Jun 2016 18:21:06 GMT) (full text, mbox, link).


Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 06 Jun 2016 18:21:06 GMT) (full text, mbox, link).


Message #251 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Marc Lehmann <schmorp@schmorp.de>
To: Marco d'Itri <md@Linux.IT>
Cc: 824931@bugs.debian.org, 825394@bugs.debian.org
Subject: Re: Bug#824931: similar to bug #824931
Date: Mon, 6 Jun 2016 20:18:59 +0200
On Mon, Jun 06, 2016 at 04:37:32PM +0200, Marco d'Itri <md@Linux.IT> wrote:
> While I still think that this would be the most generally useful 
> semantics for other inetd-started daemons, I can see how it could 
> surprise telnet/rsh users.

It surely also suprises ftp users, samba users and users of other
services. I am not sure why you keep ignoring those and single out telnet
or rsh/rlogin? There is nothing special about rsh - all openbsd-inetd
services are affected the same way.

> Since I am not sure if there is a simple solution that could be 
> implemented in the telnetd package, at this point I am considering to 
> set KillMode=process as the default for openbsd-inetd.

It should be obvious that behaviour that is decades old and didn't suffer
from any obvious problems shouldn't be changed without a good reason,
which is the case for both bugs. Arguably, the systemd change has a better
rationale than the openbsd-inetd change.

So the mode that most closely resembles to what inetd has always done
should be the default unless there is reason to change.

This is especially true for "old" services - the older a service is, the
better the reason must be to break it. If a maintainer thinks breaking
stuff is ok just because he likes the new behaviour he/she is doing a bad
job.

> OTOH, I am not sure that this use (corner) case of telnet/rsh users is 
> more important than the others, even if the current default is 
> a regression for them, so I am still undecided...

A shame, really. In the absence of any good reason for a change, a change
shouldn't be done. If it breaks stuff, it should be undone.

In any case, it doesn't affect me anymore, because I already made the
transition to rlinetd, which doesn't have this bug, even if it cost me one
production box which had to be rebooted because openbsd-inetd killed all
kinds of system services when I installed rlinetd (because oßpenbsd killed
them and the apt-get process doing the rlinetd installation).

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#825394; Package systemd. (Sun, 12 Jun 2016 09:15:20 GMT) (full text, mbox, link).


Acknowledgement sent to Martin Steigerwald <martin@lichtvoll.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 12 Jun 2016 09:15:20 GMT) (full text, mbox, link).


Message #256 received at 825394@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>
To: 825394@bugs.debian.org
Subject: shutdown versus logout
Date: Sun, 12 Jun 2016 11:12:56 +0200
I know Martin Pitt reverted the setting, but I think there is a deeper issue 
in this:

I think one major issue here is that systemd then doesn´t seem to handle 
shutdown different to log out, i.e. I and quite some other users I read from 
prefer processes to be kept running on logout, but when I shutdown or reboot 
the system I prefer it to first SIGTERM and then SIGKILL processes if any are 
left over. Instead systemd seems to wait on processes on shutdown case for at 
least one and a half minute, and that requires the KillUserProcess switch be 
on which then also leads to user processes being killed on logout which is the 
part that doesn´t make sense to me.

Just as it worked with SysVInit. Sometimes I wonder why its necessary to break 
stuff that has worked just fine for ages.

The most important question here is always "What do users want?". I know what 
I want: When I say shutdown I mean it – I don´t mean wait for processes longer 
than a few seconds. When I say reboot I mean it – I don´t mean wait for 
processes longer than a few seconds. When I say logout, I mean it as well – I 
don´t mean kill my screen session. Instead of just changing things for the 
sake of changing them, or only to the view of the world that is correct in 
systemd developers terms, I wonder how about thinking of a new way to do it 
and coordinate with all involved parties *before* matter-of-factly breaking 
existing setups in inventive ways.

So in systemd world either the logout or the shutdown is broken depending on 
the setting of the KillUserProcesses switch.

Well if its possible to some day have it working out of the box with scopes… 
but hopefully in a portable way that will work on FreeBSD and other operating 
systems as well…

I do think it would be good to extend the "don´t break userspace" mantra to 
systemd as well.

Thanks,
-- 
Martin



Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 11 Jul 2016 07:28:22 GMT) (full text, mbox, link).


Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Tue Mar 19 08:24:05 2024; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.