Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Hey, OK looking at this bug, if I understood the issue properly, I think I found what the problem is. With libpam-systemd installed, UsePAM set to yes, the ssh process with lower privileges is assign to the user session, when shutting down, systemd is going through all the user sessions and kill them one by one properly. Without libpam-systemd (or UsePAM set to no), the low privileged process stays in the sshd cgroup. As the ssh.service file explicitly contains KillMode=process, only the main (privileged) process is killed. At the end of the shutdown procedure, systemd is going into a killing spree and SIGKILL all the remaining processes. The correct solution is IMVHO is to use libpam-systemd with UsePAM set to yes. On other solution is to change the KillMode, but doing so, you'll probably loose the connection if the ssh service is restarted. my 2¢ Laurent Bigonville
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Mon, 2015-08-17 at 12:23 +0200, Laurent Bigonville wrote: The correct solution is IMVHO is to use libpam-systemd with UsePAM set to yes. On other solution is to change the KillMode, but doing so, you'll probably loose the connection if the ssh service is restarted. Both doesn't seem to be ideal... I think we should simply add a new unit file, that cleans up any left over sessions which haven't been killed via the cgroup (either because of the pam module not installed or simply because the user doesn't want to use UsePAM. Cheers, Chris smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Mon, 17 Aug 2015 16:51:42 +0200 Christoph Anton Mitterer cales...@scientia.net wrote: On Mon, 2015-08-17 at 12:23 +0200, Laurent Bigonville wrote: The correct solution is IMVHO is to use libpam-systemd with UsePAM set to yes. On other solution is to change the KillMode, but doing so, you'll probably loose the connection if the ssh service is restarted. Both doesn't seem to be ideal... I think we should simply add a new unit file, that cleans up any left over sessions which haven't been killed via the cgroup (either because of the pam module not installed or simply because the user doesn't want to use UsePAM. I personally don't like this solution. IMO, if you are using systemd you need to call libpam-systemd in your entry point service (sshd, login, xDM,...) otherwise you are loosing 1/2 of the nice features. We need to be certain that if systemd is used as pid1 the pam module is also installed. And if you are setting UsePAM to false there will be other stuffs missing/being broken, (like missing entries in the lastlog, the loginuid using for auditing not being set properly,...). BTW, if I understand the things correctly (I didn't check the code), but disabling PAM in sshd or removing libpam-systemd would also mean that the user processes started via ssh will not be killed gracefully if somebody is rebooting/shutting down the machine. Cheers, Laurent Bigonville
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
I've been struggling with an appropriate fix for this bug. I've also found that installing libpam-systemd seems to fix this for me in my testing. (If I discover it still to be a problem, I'll post again). However, I'd like to understand why libpam-systemd makes a difference if anyone has any insight? Finally, there are issues with using the ssh.socket approach which are not at first apparent. When exiting an SSH session, all processes created under that session are terminated - which means tools like screen and tmux will not work. This may or may not be a problem for you, but it's certainly means ssh.socket is also not a drop-in replacement like ssh.service. Cheers Matt Black
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Tue, 2015-05-12 at 10:20 +1000, Matt Black wrote: I've also found that installing libpam-systemd seems to fix this for me in my testing. (If I discover it still to be a problem, I'll post again). However, I'd like to understand why libpam-systemd makes a difference if anyone has any insight? It doesn't, I still have the problem occasionally on multiple systems, all with libpam-systemd installed. It's pure coincidence. Finally, there are issues with using the ssh.socket approach which are not at first apparent. When exiting an SSH session, all processes created under that session are terminated - which means tools like screen and tmux will not work. This may or may not be a problem for you, but it's certainly means ssh.socket is also not a drop-in replacement like ssh.service. please open a separate bug for this. Cheers. Chris smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Tue, 2015-05-12 at 10:49 +1000, Matt Black wrote: Interesting. The important thing here then is my question - WHY does libpam-systemd make a difference in some cases? I think Russ mentioned it before already,... it may be simply some timing issues i.e. libpam-systemd's presence slowing the shutdown somehow down a bit, and thus your sessions get properly killed. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
I've also found that installing libpam-systemd seems to fix this for me in my testing. (If I discover it still to be a problem, I'll post again). However, I'd like to understand why libpam-systemd makes a difference if anyone has any insight? It doesn't, I still have the problem occasionally on multiple systems, all with libpam-systemd installed. It's pure coincidence. Interesting. The important thing here then is my question - WHY does libpam-systemd make a difference in some cases? Finally, there are issues with using the ssh.socket approach which are not at first apparent. When exiting an SSH session, all processes created under that session are terminated - which means tools like screen and tmux will not work. This may or may not be a problem for you, but it's certainly means ssh.socket is also not a drop-in replacement like ssh.service. please open a separate bug for this. IMO this isn't a bug, it's intended behaviour of ssh.socket. On 12 May 2015 at 10:45, Christoph Anton Mitterer cales...@scientia.net wrote: On Tue, 2015-05-12 at 10:20 +1000, Matt Black wrote: I've also found that installing libpam-systemd seems to fix this for me in my testing. (If I discover it still to be a problem, I'll post again). However, I'd like to understand why libpam-systemd makes a difference if anyone has any insight? It doesn't, I still have the problem occasionally on multiple systems, all with libpam-systemd installed. It's pure coincidence. Finally, there are issues with using the ssh.socket approach which are not at first apparent. When exiting an SSH session, all processes created under that session are terminated - which means tools like screen and tmux will not work. This may or may not be a problem for you, but it's certainly means ssh.socket is also not a drop-in replacement like ssh.service. please open a separate bug for this. Cheers. Chris
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Christoph Anton Mitterer cales...@scientia.net writes: On Tue, 2015-05-12 at 10:49 +1000, Matt Black wrote: Interesting. The important thing here then is my question - WHY does libpam-systemd make a difference in some cases? I think Russ mentioned it before already,... it may be simply some timing issues i.e. libpam-systemd's presence slowing the shutdown somehow down a bit, and thus your sessions get properly killed. Nope, I haven't mentioned anything about this, and I'm not sure why libpam-systemd would make a difference. For your explanation to be the case, that would mean there's some race, but I'm not sure what that race would be in my model of how the system shutdown works. Do you think that killall is racing the kernel shutting down the network device, maybe? I wouldn't have expected that. There have been LOTS of words written on this bug report, but having skimmed through it again, I think some really basic information is still missing. What, *exactly*, is the sequence of process operations on the server that causes the client to get a clean shutdown? What, *exactly*, is the sequence of process operations on the server that causes the connection to apparently hang? It's really hard to design a solution to this problem until one has a good answer to those two questions, and I haven't seen that information on this thread yet. I suspect it's going to require some manual experimentation with attempting to duplicate the shutdown behavior in a controlled way. Clearly something changed in systemd vs. sysvinit, which is a clue, but I don't think we've yet established *what* changed, and therefore have no idea whether it's intentional, a side effect of something else, a bug, a race condition, or something else we haven't anticipated. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Wed, 29 Apr 2015 02:57:28 -0400 Matthew Dawson matt...@mjdsystems.ca wrote: On Sun, 15 Jun 2014 01:20:41 +0200 Christoph Anton Mitterer Since openssh-server comes with systemd support, whenever a host is shut down or restarted, ssh connections to that host just hang and are no longer cleanly terminated (one also doesn't see the shutdown message anymore). I'd suspect that systemd might shut down the network before it kills the ssh session (or perhaps never kills them at all?) I ran into this issue on a freshly upgraded VM. I think I found an appropriate work around, installing libpam-systemd. With that, systemd seems to know about my ssh sessions and will close them down before killing the network. Just writing to confirm that this workaround worked for me. I was having this same problem on a new, minimal Jessie installation. Installing libpam-systemd (and rebooting) fixed it. As an aside, it seems strange that libpam-systemd was not installed in a minimal Jessie install, since systemd recommends it. But perhaps that's a quirk of the Debian Installer. -Steven M. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, 2015-05-02 at 18:55 -0700, Steven Monai wrote: I was having this same problem on a new, minimal Jessie installation. Installing libpam-systemd (and rebooting) fixed it. I somewhat doubt that this is really a fix. When I reported the problem in the beginning, I've always had libpam-systemd installed. At some later point I've also seen the problem occurring far less... but from time to time it still happens that I have a hanging connection. So I'd guess it's just coincidence that this improves things a bit. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sun, 15 Jun 2014 01:20:41 +0200 Christoph Anton Mitterer Hi. Since openssh-server comes with systemd support, whenever a host is shut down or restarted, ssh connections to that host just hang and are no longer cleanly terminated (one also doesn't see the shutdown message anymore). I'd suspect that systemd might shut down the network before it kills the ssh session (or perhaps never kills them at all?) Hi all, I ran into this issue on a freshly upgraded VM. I think I found an appropriate work around, installing libpam-systemd. With that, systemd seems to know about my ssh sessions and will close them down before killing the network. I'm not sure if something is still missing, as mosh sessions will sometimes linger. But ssh seems solved. -- Matthew smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Re: Christoph Anton Mitterer 2014-06-15 20140614232041.29765.83096.report...@heisenberg.scientia.net Since openssh-server comes with systemd support, whenever a host is shut down or restarted, ssh connections to that host just hang and are no longer cleanly terminated (one also doesn't see the shutdown message anymore). Fwiw, I'm also seeing this behavior and I find it utterly annoying. Sometimes not even enter~. works (possibly when ssh is waiting for a reply from the remote machine). It's the same on CentOS, so it's not Debian-specific, but we should do something about it. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Hi, On Sat, Dec 13, 2014 at 07:04:30PM +0100, Christoph Anton Mitterer wrote: On Sat, 2014-12-13 at 15:01 +0100, Marc Haber wrote: I would like to have a method to kill all ssh sessions with the exception of my own ones, or the single session that I happen to type the command restarting sshd in. Since there is no definition of which are yours (the ones logged in to your current user? sessions started by your current user?) this is going to be difficult, apart from the fact, that one would need a way to find out such information. Anyway. This kind of process management is not what the init-system should be there for. I am aware of that. I was just dreaming of a perfect solution, very well knowing that I won't get it RSN. That would be a pretty severe change from the behavior we used to have for fifteen years. I also guess it would be used as an argument against systemd as a whole. First of all,... I just put that up for open discussion... i.e. the questions: When we'd start from scratch with the OS, and would ask ourselves what should happen when I type 'stop service XYZ'... would that be to only stop the listener, or to stop anything related to that service (i.e. also any sessions, like ongoing httpd connections or that like). Yes, but GNU/Linux is not a grüne wiese approach, it is migrating millions of existing systems. Even a classic Unix leaves many things to be hated, but it's just what we are used to, and which is not easily changed. OTOH, people aren't stupid and when you tell them why a current behaviour changes and that it's for a better design of the system,.. they likely can adapt to it. Locking a shell for a two-digit number of seconds in a ordinare usage situation is something I would not want to adapt to even if the underlying system was perfect. And in general, one cannot stop progress just because there are some backwards-minded people who never want to have ill-designed things to change. I fail to see why it is progress to save five seconds of shutdown time for the machine while the same change wastes half a minute or more for the human. Greetings Marc, well aware that the last sentence will be misinterpreted as systemd hatred again, which it is not -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, Dec 13, 2014 at 07:14:53PM +0100, Christoph Anton Mitterer wrote: On Sat, 2014-12-13 at 15:06 +0100, Marc Haber wrote: /lib/systemd/system/ssh.service in current sid has After=network.target in its Unit stanza and still not cleanly kills off ssh sessions. Since the ssh.service unit file only starts the listener daemons and not the sessions neither explicitly stops the session processes... this is absolutely expected behaviour. It might be expected by somebody very familiar with how new init works. It is surprising to people who aren't and undresired by some of them. On Sat, 2014-12-13 at 15:10 +0100, Marc Haber wrote: That would be the systemd way to do it No, it would be the way to improve things when the were done wrong in the past, Wrong is subjective. It might also be something people are used to for decades. and instantly spawn a new hate wave. After all, it was systemd locking people out of their headless, remote systems during an urgent security update. Since such behavioural change wouldn't depend on the initsystem, just stubborn people who annoy us with their systemd FUD and hatred anyway would do so... Unfortunately, there are many of those people. Btw, with systemd sticking its head in many parts of the system that are traditionally not an init's job, it is hard to judge whether a change is introduced by systemd or not. People are going to take the easiest route to vent. On Sat, 2014-12-13 at 15:16 +0100, Marc Haber wrote: Do I understand correctly, that ssh in jessie/sid allows the local admin to run sshd as a traditional daemon, with the new (undesired) behavior, or as a systemd service with socket activation, which gives a better emulation of traditional behavior? No, you don't understand correctly. In daemon mode, the new behaviour is a bug, reported in this very ticket. As long as we agree on this being a bug, we are fine with each other. In socket mode, each session is controlled by what compares to the listener daemon (i.e. the process which is directly managed by systemd), therefore one get's the fix for free, as this process is stopped by systemd. After typing systemctl disable ssh.service and systemctl enable ssh.socket, I still have a running sshd -D, and rebooting the system results in a hanging shell. After the reboot, there is no sshd -D under systemd, my connection closes immediately after typing shutdown -r now, but the shutdown message is still not printed. I can therfore not be sure whether it was a random ion storm in the kernel that disconnected me or the shutdown that I initiated. If this is really seriously meant that way, people will see this as a conspiracy to coax people into using socket activation. There is no conspiracy, the default mode of ssh is still the daemon based. You know that, I know that. But if the daemon mode has new shortcomings compared to what we are used to, and the canonical answer is switch to socket activation, we're screwed. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sun, 2014-12-14 at 16:19 +0100, Marc Haber wrote: It might be expected by somebody very familiar with how new init works. It is surprising to people who aren't and undresired by some of them. Again, this is why we have this bug. And when I talked about absolutely expected behaviour I meant when you look at the system and wonder why does XYZ happen... if you now then how things work, it's not unexpected or strange that systemd works as it does. As long as we agree on this being a bug, we are fine with each other. Well sure... haven't you seen *who* reported that issue first? Me. After typing systemctl disable ssh.service and systemctl enable ssh.socket, I still have a running sshd -D systemd's enable and disable actions are just the same as update-rc.d's were with sysvinit. They don't start or stop an already running service. , and rebooting the system results in a hanging shell. What exactly do you mean,... the shell which you were using to connect to the host that you're just rebooting from a remote node? Then again, this is this very bug (i.e. ssh has no init-system configuration to properly stop it's sessions). but the shutdown message is still not printed. I can therfore not be sure whether it was a random ion storm in the kernel that disconnected me or the shutdown that I initiated. mhh and the canonical answer is switch to socket activation, we're screwed. For some daemons, socket activation may actually be the preferred way that should become default (e.g. why should I need to have a local cups daemon running all time, if I only print every once in a while)... for others (e.g. ssh) I doubt that socket based activation will get default, because it have disadvantages (like the delay in ssh parsing the configuration file) Also note that systemd provides here actually more than two ways of starting things up: /lib/systemd/system/ssh.service = the classic way of having a daemon run at boot, which listens for incomming connections, spawning session processes /lib/systemd/system/ssh.socket = socket based activation which starts the plain old listener (ssh.service) the first time someone uses the socket /lib/systemd/system/ssh@.service = spawn an inetd-style ssh just for that single connection, when someone connects to the socket which systemd listens on. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Answering two of your mails in one, since all of this got really off topic. On Sun, 2014-12-14 at 15:46 +0100, Marc Haber wrote: Yes, but GNU/Linux is not a grüne wiese approach, it is migrating millions of existing systems. Sure, but this doesn't mean that one cannot pick out single points, think about whether there is a conceptually better way (I didn't even say that I'm 100% sure that my proposed way is really the conceptually better one)... and migrate to this when feasible. We had much harder migrations (multiarch, etc.) than something like telling people if tell your init systemd to stop XYZ, it's sessions will stop as well. Locking a shell for a two-digit number of seconds in a ordinare usage situation is something I would not want to adapt to even if the underlying system was perfect. I don't get what you want to say... *if* my proposed change would be chosen, then stopping ssh would stop all active sessions... not just freeze them for n seconds. I fail to see why it is progress to save five seconds of shutdown time for the machine while the same change wastes half a minute or more for the human. Again I don't really see where anything here stops something for half a minute or more... but personally said: being a faster init system (in some occasions) is the least interesting thing for me about systemd (actually I don't care at all about boot speed). The real advancements are clean dependency expression mechanisms, guarantees like I can prevent my daemon to start if the firewall rules didn't load, etc. On Sun, 2014-12-14 at 15:40 +0100, Marc Haber wrote: Please try to take matter-of-fact criticism not as hatred. I do actually like some of systemd's concepts. Well I think I've showed that most of the things you've criticised have nothing to with systemd itself, especially not any proposals to change the behaviour of ssh stop - which was just a proposal by myself and nothing form the package maintainers. The only valid criticism was that due to how systemd shuts down (i.e. more parallel) we see this bug. And I doubt that other software (neither upstart nor sysvinit) is free of bugs. systemd's behavior has some clear disadvantages which show themselves evidently in server management. Which was discussed over and over again on general lists, and which has really nothing to do with this bug. I _want_ to switch to systemd. Before I do so, I'd like to get rid of some nuisances. Nuisances are not the side effect of switching to systemd, they are the side effect of every switch that is done. Most software projects deal with those reports professionally without taking the critique personally. Well that's why this bug (and others) are reported, and I haven't seen any of the systemd maintainers here, complaining against the bug (which is btw. rather a bug in ssh in that it never had a clean way of session termination). You in contrast mentioned every second sentence that this was all systemd's fault, that there would be conspiracies, etc.. I personally do have several points of critic in systemd as well (starting from that we more or less only try to rebuild sysvinit in systemd, without really using the full range of systemd features... over political questions that more and more base things are concentrated in one projects). These are things which one can objectively discuss in the appropriate places. But even I'm really fed up with all the FUD spread at in all kinds of unrelated places like this. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Fri, Oct 10, 2014 at 11:52:24AM +0200, Tom Hutter wrote: The solution provided under https://bugzilla.redhat.com/show_bug.cgi?id=626477 suggests to killall ssh sessions, when stopping sshd. I prefer to have at least one ssh session open to my server when restarting ssh, if something goes wrong. Agreed. This change would not be acceptable. Therefore I added a service, to solve this under the current Debian Wheezy version I am running. /etc/systemd/system/ssh-user-sessions.service: [Unit] Description=Shutdown all ssh sessions before network After=network.target [Service] TimeoutStartSec=0 Type=oneshot RemainAfterExit=yes ExecStart=/bin/true ExecStop=/usr/bin/killall sshd When starting, this service does simply nothing (/bin/true). But due to the statement After=network.target it kills all ssh processes before shutting down the network. I had always thought that systemd would group processes together in cgroups to be able to kill them more elegantly on shutdown. I'd like to see that feature used instead of resorting to the old sledgehammer method. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Fri, Oct 10, 2014 at 05:44:14PM +0200, Christoph Anton Mitterer wrote: a) if sshd crashes or when it is restarted/reloaded (or when the network is restarted), we do not want ssh sessions to terminate, right? At least that's what we always had. I would like to have a method to kill all ssh sessions with the exception of my own ones, or the single session that I happen to type the command restarting sshd in. b) we want a way to actually stop user sessions... not only for this particular bug (i.e. on shutdown), but as a locally logged in sysadmin I'd also like to say okay... away with sshd and it's users. Agreed. We didn't have that until jessie though. AFAICS, this should solve (a) and (b), the only difference to now would be, that we need to educate our users/admins, that systemctl stop ssh really means all ssh stops and not just the main ssh daemon stops but old connections remain. That would be a pretty severe change from the behavior we used to have for fifteen years. I also guess it would be used as an argument against systemd as a whole. Please consider not changing this behavior to keep system acceptance up. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Fri, Oct 10, 2014 at 06:51:20PM +0200, Tom Hutter wrote: If ssh is restarted, my hack does exactly the expected. The ssh user sessions stay alive. Only, if the network is shut down, the sessions will be terminated. Looking at this excerpt from systemd.special(7), I would say, my hack does exactly the expected. What is a session depending on network good, once the network has gone away? network.target This unit is supposed to indicate when network functionality is available, but it is only very weakly defined what that is supposed to mean, with one exception: at shutdown, a unit that is ordered after network.target will be stopped before the network -- to whatever level it might be set up then -- is shut down. Also see Running Services After the Network is up[1] for more information. Also see network-online.target described above. /lib/systemd/system/ssh.service in current sid has After=network.target in its Unit stanza and still not cleanly kills off ssh sessions. There is also /lib/systemd/system/ssh@.service which seems to be contrary to /lib/systemd/system/ssh.service which I do not understand. I think it's more a philosophical question, if running processes depending on the network should survive a network restart They usually did in the past, /etc/init.d/network stop; /etc/init.d/network start returned you to the shell and did not kill the session. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, Oct 11, 2014 at 06:33:39PM -0700, Russ Allbery wrote: Christoph Anton Mitterer cales...@scientia.net writes: But I mean before thinking about how to handle it technically,... it should probably decided what do we actually want. Like even if ssh itself (the binary) behaves different from apache/etc. - do we want to keep that in the unit-files or do we want stop to generally mean that everything from that service is stopped. I personally would tend to the later, though this may have many implications... Yes, a lot of people being *quite* upset when they stop ssh to restart it with debugging or to temporarily bring it down while working on something, discover that their session was terminated in a way that's never happened with ssh in the past, and now be unable to connect to the system since it was a remote server. Let's not do that. That would be really unpleasant. We need to preserve the current sshd behavior that stopping the service does *not* kill open sessions. Amen. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, Oct 11, 2014 at 08:12:56PM -0700, Russ Allbery wrote: I have no problems with the current behavior under systemd, so I'm not the one to ask for a solution. It makes no difference at all to me whether I get a clean connection shutdown from a host when it's being rebooted. It makes a big difference to me when working with multiple hosts at once. I will only get back my shell after a manual action or after waiting for the host to return to the network to finally send an RST. That didn't reliably happen even under sysvinit-started sshd. It happened reliably in so many cases that I don't even remember the last time where a sysvinit system didn't return me cleanly and quickly to my shell on shutdown. It was a big WTF when my first systemd system behaved that way. If sysvinit were so unreliable in its behavior on shutdown, I would have been at least a bit familiar with the new behavior, and I do not like it at all. This change will not improve systemd's behavior, as it is one more place where the self-proclaimed drop-in replacement to sysvinit changes system behavior in a _very_ prominent way. If you can find a way to improve the behavior along some axis that you care about, I'm certainly fine with that, but given that I don't even consider the problem that you're trying to solve to be a problem, I'm going to have a low tolerance for regressions. :) jftr, I see the changed behavior as a problem. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sun, Oct 12, 2014 at 04:12:07AM +0200, Christoph Anton Mitterer wrote: On Sat, 2014-10-11 at 18:33 -0700, Russ Allbery wrote: Yes, a lot of people being *quite* upset when they stop ssh to restart it with debugging or to temporarily bring it down while working on something, discover that their session was terminated in a way that's never happened with ssh in the past, and now be unable to connect to the system since it was a remote server. Let's not do that. That would be really unpleasant. We need to preserve the current sshd behavior that stopping the service does *not* kill open sessions. Well never too late to change something *if* it was the cleaner way to handle it. =) That would be the systemd way to do it and instantly spawn a new hate wave. After all, it was systemd locking people out of their headless, remote systems during an urgent security update. Don't change this behavior. Please. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Fri, Oct 10, 2014 at 10:51:04AM -0500, David Lechner wrote: I have found that using ssh.socket instead of ssh.service makes clients shut down cleanly most of the time (sometimes they will still hang, but it is rare). systemctl disable ssh.service systemctl enable ssh.socket Do I understand correctly, that ssh in jessie/sid allows the local admin to run sshd as a traditional daemon, with the new (undesired) behavior, or as a systemd service with socket activation, which gives a better emulation of traditional behavior? If this is really seriously meant that way, people will see this as a conspiracy to coax people into using socket activation. Danger, Will Robinson. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, 2014-12-13 at 15:01 +0100, Marc Haber wrote: I would like to have a method to kill all ssh sessions with the exception of my own ones, or the single session that I happen to type the command restarting sshd in. Since there is no definition of which are yours (the ones logged in to your current user? sessions started by your current user?) this is going to be difficult, apart from the fact, that one would need a way to find out such information. Anyway. This kind of process management is not what the init-system should be there for. b) we want a way to actually stop user sessions... not only for this particular bug (i.e. on shutdown), but as a locally logged in sysadmin I'd also like to say okay... away with sshd and it's users. Agreed. We didn't have that until jessie though. Sure,... I didn't claim that we had that before. AFAICS, this should solve (a) and (b), the only difference to now would be, that we need to educate our users/admins, that systemctl stop ssh really means all ssh stops and not just the main ssh daemon stops but old connections remain. That would be a pretty severe change from the behavior we used to have for fifteen years. I also guess it would be used as an argument against systemd as a whole. First of all,... I just put that up for open discussion... i.e. the questions: When we'd start from scratch with the OS, and would ask ourselves what should happen when I type 'stop service XYZ'... would that be to only stop the listener, or to stop anything related to that service (i.e. also any sessions, like ongoing httpd connections or that like). I think the later would be the cleaner way of (generally) handling things... and I'm well aware that this would change current behaviour. OTOH, people aren't stupid and when you tell them why a current behaviour changes and that it's for a better design of the system,.. they likely can adapt to it. And in general, one cannot stop progress just because there are some backwards-minded people who never want to have ill-designed things to change. Apart from that - *if* such change in behaviour would really come, it would have nothing to do with systemd. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, 2014-12-13 at 15:06 +0100, Marc Haber wrote: /lib/systemd/system/ssh.service in current sid has After=network.target in its Unit stanza and still not cleanly kills off ssh sessions. Since the ssh.service unit file only starts the listener daemons and not the sessions neither explicitly stops the session processes... this is absolutely expected behaviour. There is also /lib/systemd/system/ssh@.service which seems to be contrary to /lib/systemd/system/ssh.service which I do not understand. I guess it should be easy to find out what this is about, in any way, explaining systemd functionality doesn't belong to this bug. On Sat, 2014-12-13 at 15:10 +0100, Marc Haber wrote: That would be the systemd way to do it No, it would be the way to improve things when the were done wrong in the past,... which you've had always during the whole history of UNIX, and which neither contradicts any of UNIX' paradigms like small is nice and that like. and instantly spawn a new hate wave. After all, it was systemd locking people out of their headless, remote systems during an urgent security update. Since such behavioural change wouldn't depend on the initsystem, just stubborn people who annoy us with their systemd FUD and hatred anyway would do so... On Sat, 2014-12-13 at 15:16 +0100, Marc Haber wrote: Do I understand correctly, that ssh in jessie/sid allows the local admin to run sshd as a traditional daemon, with the new (undesired) behavior, or as a systemd service with socket activation, which gives a better emulation of traditional behavior? No, you don't understand correctly. In daemon mode, the new behaviour is a bug, reported in this very ticket. In socket mode, each session is controlled by what compares to the listener daemon (i.e. the process which is directly managed by systemd), therefore one get's the fix for free, as this process is stopped by systemd. If this is really seriously meant that way, people will see this as a conspiracy to coax people into using socket activation. There is no conspiracy, the default mode of ssh is still the daemon based. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Friday 10 October 2014 22:50:31 Christoph Anton Mitterer wrote: Sure,... I never claimed it wouldn't work... just that I'm not sure whether I like the idea of having a separate unit file for the ssh sessions. I mean you have a similar concepts in many other daemons (like httpd or some DB servers have their open connections)... and none of them will have these managed via a separate unit file. Exactly. Stop apache, nginx, mysql, postgres and tell me, how many children processes will be left, once you stopped it. As ssh behaves differently and keeps the children alive, you have to handle it differently :-) network.target This unit is supposed to indicate when network functionality is available, but it is only very weakly defined what that is supposed Well that's another point,.. I personally really hate the idea of network.target... as even upstream admits it's weakly defined... and I think this brings all kinds of problem with it. What does indicate when network functionality is available really mean in a even driven world with many possible network connections per computer and services networking depends upon. So the problem is that many things may hook into network.target or network-pre.target,... starting from just the bare question whether a device is up or not, over things like do we have DNS? to stuff like firewalls, or VPN. Of course this doesn't directly affect us, I just want to point out that depending on network.target always means some serialisation point, which is IMHO against the ideas of systemd. At least from my (though non-expert PoV) I'd suggest to avoid dependencies on it when possible. What can I say. You made your point clear. If you don't want to rely on network.target my solution will not help you :-) As mentioned above, restarting of sshd will not shut down the existing ssh sessions. Security flaw or not. Well you're talking about restarting the sshd process - sure it won't kill the existing sessions. I was referring to restarting the ssh[d] service (i.e. systemd service)... and was generally questioning, what do we want to happen, when people restart respectively stop it. :) systemctl stop ssh.service = all existing user sessions will stay alive Try it. That is why I made this hack in the first place. The solution provided in the RedHat forum would shut down all ssh sessions and I want to keep at least one ssh session open to my server, when restarting sshd. Cheers Tom
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, 2014-10-11 at 11:23 +0200, Tom Hutter wrote: Exactly. Stop apache, nginx, mysql, postgres and tell me, how many children processes will be left, once you stopped it. As ssh behaves differently and keeps the children alive, you have to handle it differently :-) Sure... But I mean before thinking about how to handle it technically,... it should probably decided what do we actually want. Like even if ssh itself (the binary) behaves different from apache/etc. - do we want to keep that in the unit-files or do we want stop to generally mean that everything from that service is stopped. I personally would tend to the later, though this may have many implications... And when you're right, that systemd restart == stop + start... then this would be anyway difficult. systemctl stop ssh.service = all existing user sessions will stay alive Sure, I know,... due to the KillMode=process Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Christoph Anton Mitterer cales...@scientia.net writes: But I mean before thinking about how to handle it technically,... it should probably decided what do we actually want. Like even if ssh itself (the binary) behaves different from apache/etc. - do we want to keep that in the unit-files or do we want stop to generally mean that everything from that service is stopped. I personally would tend to the later, though this may have many implications... Yes, a lot of people being *quite* upset when they stop ssh to restart it with debugging or to temporarily bring it down while working on something, discover that their session was terminated in a way that's never happened with ssh in the past, and now be unable to connect to the system since it was a remote server. Let's not do that. That would be really unpleasant. We need to preserve the current sshd behavior that stopping the service does *not* kill open sessions. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, 2014-10-11 at 18:33 -0700, Russ Allbery wrote: Yes, a lot of people being *quite* upset when they stop ssh to restart it with debugging or to temporarily bring it down while working on something, discover that their session was terminated in a way that's never happened with ssh in the past, and now be unable to connect to the system since it was a remote server. Let's not do that. That would be really unpleasant. We need to preserve the current sshd behavior that stopping the service does *not* kill open sessions. Well never too late to change something *if* it was the cleaner way to handle it. =) Anyway,... what would you propose then to bring everything under one hat? 2 service files? Or even three? Like ssh.service sshd.service ssh-sessions.service with: - sshd.service being the daemon, that, if stopped/restarted, leaves ssh-sessions.service alone - ssh-session.service being the one that stops the ssh sessions (either manually, when the admin wants it, or on shutdown) - and ssh.service being simply something that depends on both (i.e. stops both and starts sshd.serice) ? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Christoph Anton Mitterer cales...@scientia.net writes: Well never too late to change something *if* it was the cleaner way to handle it. =) But having stopping sshd kill open sessions is not cleaner. It would be a pretty serious regression. Anyway,... what would you propose then to bring everything under one hat? I have no problems with the current behavior under systemd, so I'm not the one to ask for a solution. It makes no difference at all to me whether I get a clean connection shutdown from a host when it's being rebooted. That didn't reliably happen even under sysvinit-started sshd. If you can find a way to improve the behavior along some axis that you care about, I'm certainly fine with that, but given that I don't even consider the problem that you're trying to solve to be a problem, I'm going to have a low tolerance for regressions. :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Hi, I had the same issue under Debian Wheezy with systemd 204-14~bpo70+1 As systemd is in constant development and Jessie is currently running version 215-5+b1 it maybe resolved in more recent versions than 204-14. The solution provided under https://bugzilla.redhat.com/show_bug.cgi?id=626477 suggests to killall ssh sessions, when stopping sshd. I prefer to have at least one ssh session open to my server when restarting ssh, if something goes wrong. Therefore I added a service, to solve this under the current Debian Wheezy version I am running. /etc/systemd/system/ssh-user-sessions.service: [Unit] Description=Shutdown all ssh sessions before network After=network.target [Service] TimeoutStartSec=0 Type=oneshot RemainAfterExit=yes ExecStart=/bin/true ExecStop=/usr/bin/killall sshd When starting, this service does simply nothing (/bin/true). But due to the statement After=network.target it kills all ssh processes before shutting down the network. Works for me :-) Cheers Tom
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Hi, I also created a workaround for my minimal environment, just yesterday. It involves patching /etc/acpi/powerbtn-acpi-support.sh (I use acpid/acpi-support-base for power events) and adding aliases for 'shutdown' and 'reboot': http://www.schreyben.de/Systemd_Haengende_SSH-Verbindungen_beim_Neustart Also seems to work well so far. Regards Ingmar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Fri, 2014-10-10 at 11:52 +0200, Tom Hutter wrote: Therefore I added a service, to solve this under the current Debian Wheezy version I am running. Hmm I'm a bit torn apart between thinking that this is either an ugly hack or a clean solution ^^ ExecStart=/bin/true At least this seems a hack ;-) Let me see, on the one hand I think there should be one ssh.service file which should be able to handle everything (isn't systemd so powerful?! )... on the other hand I like the idea of having a service for the user sessions, which should ideally allow to stop them (which is, AFAICS, however not achieved by your version). Let's perhaps collect what we want: a) if sshd crashes or when it is restarted/reloaded (or when the network is restarted), we do not want ssh sessions to terminate, right? Of course this has the problem, that long running user sessions (or consider something like ssh control channel multiplexing) are typically *never* killed - which can be quite of a security problem. Imagine a flaw found in ssh, which also affects running connections - even when the main daemon would be restarted after package upgrade,.. the user session processes would be still vulnerable. But let's say that this should be the job of a tool like needrestart[0] b) we want a way to actually stop user sessions... not only for this particular bug (i.e. on shutdown), but as a locally logged in sysadmin I'd also like to say okay... away with sshd and it's users. Maybe the way to go would be the following: - only restart/reload actions keep the user sessions a live - stop however kills them as well AFAICS, this should solve (a) and (b), the only difference to now would be, that we need to educate our users/admins, that systemctl stop ssh really means all ssh stops and not just the main ssh daemon stops but old connections remain. Actually I feel that would be much cleaner thins the action is called stop and not stop-but-there-are-exceptions and one should be able to expect stop to really stop it (on the other hand though, one could argue the same for restart/reload). Cheers, Chris. [0] Note that needrestart currently also suffers this problem: it only tracks the daemons, not the running sessions. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Fri, 2014-10-10 at 12:54 +0200, I. Schrey wrote: I also created a workaround for my minimal environment, just yesterday. It involves patching /etc/acpi/powerbtn-acpi-support.sh (I use acpid/acpi-support-base for power events) and adding aliases for 'shutdown' and 'reboot': http://www.schreyben.de/Systemd_Haengende_SSH-Verbindungen_beim_Neustart Also seems to work well so far. Well that's really a hack, especially since it only works with acpi* packages installed. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
I have found that using ssh.socket instead of ssh.service makes clients shut down cleanly most of the time (sometimes they will still hang, but it is rare). systemctl disable ssh.service systemctl enable ssh.socket -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Fri, 2014-10-10 at 18:51 +0200, Tom Hutter wrote: Hmm I'm a bit torn apart between thinking that this is either an ugly hack or a clean solution ^^ Never said it's not a hack. I may disagree in the word ugly ;-) ;-) If ssh is restarted, my hack does exactly the expected. The ssh user sessions stay alive. Only, if the network is shut down, the sessions will be terminated. Looking at this excerpt from systemd.special(7), I would say, my hack does exactly the expected. Sure,... I never claimed it wouldn't work... just that I'm not sure whether I like the idea of having a separate unit file for the ssh sessions. I mean you have a similar concepts in many other daemons (like httpd or some DB servers have their open connections)... and none of them will have these managed via a separate unit file. network.target This unit is supposed to indicate when network functionality is available, but it is only very weakly defined what that is supposed Well that's another point,.. I personally really hate the idea of network.target... as even upstream admits it's weakly defined... and I think this brings all kinds of problem with it. What does indicate when network functionality is available really mean in a even driven world with many possible network connections per computer and services networking depends upon. So the problem is that many things may hook into network.target or network-pre.target,... starting from just the bare question whether a device is up or not, over things like do we have DNS? to stuff like firewalls, or VPN. Of course this doesn't directly affect us, I just want to point out that depending on network.target always means some serialisation point, which is IMHO against the ideas of systemd. At least from my (though non-expert PoV) I'd suggest to avoid dependencies on it when possible. As mentioned above, restarting of sshd will not shut down the existing ssh sessions. Security flaw or not. Well you're talking about restarting the sshd process - sure it won't kill the existing sessions. I was referring to restarting the ssh[d] service (i.e. systemd service)... and was generally questioning, what do we want to happen, when people restart respectively stop it. :) If you want to stop the ssh sessions during shutdown and signalling it to the clients, you have to have the network stack still available. Therefore killing all ssh sessions before network.target is going down seems to me the last possible moment. Otherwise the ssh sessions will be closed but your client will not be signalled, which was the reason I made this hack. Again here,.. my point (b) was more a general question, not only specific to shutdown. My idea was: When we'd agree that stopping the ssh service (not restarting/reloading) should actually also stop the connections, then one could AFAIU simply do something like this: Remove the KillMode=process line from the ssh.service unit file. Or is KillMode also used on systemd's restart/reload of services? I think it's more a philosophical question, if running processes depending on the network should survive a network restart - I would say: No I'd say: depends Many services just happily survive a network restart... ssh is a good example (unless sshd kills the connection beacause of TCP ClientAlive or SSH ClientAlive). Then again if you say Yes, I think it's hard to find a solution, to terminate the ssh sessions only on network stop and not on network restart. Well all this question wouldn't arise when there was no separate service, right? If the normal ssh.service would just kill existing connections, than, AFAIU, the only thing needed is: After=networking.target (which we have anyway) and removal of: KillMode=process If network is just restarted, then this shouldn't affect ssh.service at all. But if the machine is shut down, then systemd should stop ssh.service, thereby calling the default KillMode=control-group. And because of the After= it should happen before networking.target is stopped. Or do I miss something? If I am correct, restart in systemd means stop and start. So how distinguish between stop to shut down an stop to restart? Mhhh... that would be a problem though in my idea,.. cause I base my assumption that on restart KillMode=control-group wouldn't happen. :/ Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Hi, I'm also getting this behaviour from a stripped-down Jessie VM that uses systemd. It started when I switched that VM from sysv to systemd a couple of months ago. It's reproducible on that VM - happens every time. openssh-server package version: 1:6.6p1-7. Funny enough, this doesn't happen with another Jessie VM (same package versions, just a lot more packages installed) - that one manages to cleanly terminate ssh sessions upon reboot. In addition, what both VMs fail to produce is the usual message, like ---snip--- Broadcast message from root@host (Mon Sep 15 10:29:06 2014): Power button pressed The system is going down for system halt NOW! ---snip--- Attached are two csv files containing the syslog messages on shutdown (loglevel info), for comparison. For example, missing from the stripped-down VM: sshd: Received signal 15; terminating whereas Stopping OpenBSD Secure Shell server... is present in both logs. Regards Ingmar Date,Facility,Severity,Host,Syslogtag,ProcessID,Messagetype,Message Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Session c3 of user root. Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Session c1 of user lightdm. Today 10:23:45,1,4,jessie,Bus,1096,1, g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Today 10:23:45,3,6,jessie,systemd,1,1, Stopping LVM2 PV scan on device 254:5... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping User Manager for 0... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Console Manager... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping User Manager for 108... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Authenticate and Authorize Users to Run Privileged Tasks... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Mail Transport Agent. Today 10:23:45,3,6,jessie,systemd,1,1, Stopped target Mail Transport Agent. Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Graphical Interface. Today 10:23:45,3,6,jessie,systemd,1,1, Stopped target Graphical Interface. Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Multi-User System. Today 10:23:45,3,6,jessie,systemd,1,1, Stopped target Multi-User System. Today 10:23:45,3,6,jessie,systemd,1,1, Stopping LSB: disk temperature monitoring daemon... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping LSB: Postfix Mail Transport Agent... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping LSB: SANE network scanner server... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Deferred execution scheduler... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Munin Node... Today 10:23:45,3,5,jessie,node,578,1, 2014/09/15-10:23:45 Server closing! Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Regular background program processing daemon... Today 10:23:45,3,6,jessie,systemd,1,1, Stopping OpenBSD Secure Shell server... Today 10:23:45,4,6,jessie,sshd,762,1, Received signal 15; terminating. Today 10:23:45,3,6,jessie,systemd,1,1, Stopping D-Bus System Message Bus... Today 10:23:45,3,6,jessie,saned,8925,1, saned disabled; edit /etc/default/saned Today 10:23:45,3,6,jessie,systemd,1,1, Stopping Initialize hardware monitoring sensors... Today 10:23:45,3,4,jessie,NetworkManager,500,1, warn disconnected by the system bus. Today 10:23:45,3,4,jessie,ModemManager,502,1, warn Could not acquire the 'org.freedesktop.ModemManager1' service name Today 10:23:45,3,6,jessie,ModemManager,502,1, info ModemManager is shut down Today 10:23:45,3,6,jessie,NetworkManager,500,1, info ModemManager disappeared from bus Today 10:23:45,4,3,jessie,logind,504,1, Failed to abandon scope session-c3.scope Today 10:23:45,4,3,jessie,logind,504,1, Failed to abandon session scope: Connection was disconnected before a reply was received Today 10:23:45,3,6,jessie,daemon,507,1, g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Today 10:23:45,3,6,jessie,lightdm,530,1, Failed to get D-Bus connection Today 10:23:45,3,6,jessie,NetworkManager,500,1, g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Today 10:23:45,3,6,jessie,systemd,1,1, Stopped Initialize hardware monitoring sensors. Today 10:23:45,3,6,jessie,systemd,1,1, Stopping System Logging Service... Today 10:23:45,5,6,jessie,rsyslogd,,1, [origin software=\rsyslogd\ swVersion=\8.4.0\ x-pid=\499\ x-info=\http://www.rsyslog.com\;] exiting on signal 15. Date,Facility,Severity,Host,Syslogtag,ProcessID,Messagetype,Message Today 10:25:28,3,6,jessie-s,systemd,1,1, Stopping Mail Transport Agent. Today 10:25:28,3,6,jessie-s,systemd,1,1, Stopped target Mail Transport Agent. Today 10:25:28,3,6,jessie-s,systemd,1,1, Stopping Graphical Interface. Today 10:25:28,3,6,jessie-s,systemd,1,1, Stopped target Graphical Interface. Today 10:25:28,3,6,jessie-s,systemd,1,1, Stopping Multi-User System.
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Package: openssh-server Version: 1:6.6p1-5 Severity: normal Hi. Since openssh-server comes with systemd support, whenever a host is shut down or restarted, ssh connections to that host just hang and are no longer cleanly terminated (one also doesn't see the shutdown message anymore). I'd suspect that systemd might shut down the network before it kills the ssh session (or perhaps never kills them at all?) Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openssh-server depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii dpkg 1.17.10 ii init-system-helpers1.19 ii libc6 2.19-1 ii libcomerr2 1.42.10-1 ii libgssapi-krb5-2 1.12.1+dfsg-2 ii libkrb5-3 1.12.1+dfsg-2 ii libpam-modules 1.1.8-3 ii libpam-runtime 1.1.8-3 ii libpam0g 1.1.8-3 ii libselinux12.3-1 ii libssl1.0.01.0.1h-2 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian13 ii openssh-client 1:6.6p1-5 ii openssh-sftp-server1:6.6p1-5 ii procps 1:3.3.9-5 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages openssh-server recommends: ii ncurses-term 5.9+20140118-1 ii xauth 1:1.0.7-1 Versions of packages openssh-server suggests: pn molly-guard none pn monkeysphere none ii rssh 2.3.4-4 pn ssh-askpass none pn ufw none -- debconf information: ssh/disable_cr_auth: false ssh/encrypted_host_key_but_no_keygen: openssh-server/permit-root-login: false * ssh/use_old_init_script: true ssh/vulnerable_host_keys: ssh/new_config: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=626477 smime.p7s Description: S/MIME cryptographic signature
