Debian Bug report logs - #825394

systemd kill background processes after user logs out

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

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

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.

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

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?

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

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>

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

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?

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

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?

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

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

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

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

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

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

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

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

An easy fix is to change the default init system to the superior System V init.

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

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)

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

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>

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

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.

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

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

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

ROFLCOPTER. This is the funnies bug that I remember in Debian. Debian, please get rid of that crap systemd.

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

What a pain! Turn this "feature" off, an application should not try to fix errors from other applications, what a mess Cheers Lars

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

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

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

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

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

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.

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

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

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 t