Found a fix for this type of behavior
edit /lib/systemd/system/systemd-user-sessions.service and append network.target to the after line.
[Unit]
Description = Permit User Sessions
Documentation = man:systemd-user-sessions.service(8)
After = network.target remote-fs.targetthen symlink /lib/systemd/system/systemd-user-sessions.service to /etc/systemd/system/
Hope this helps someone else.
This was already rejected upstream: http://lists.freedesktop.org/archives/s … 06900.html
]]>I don't have the link anymore, but from my understanding this is already in the works for the next upstream version.
Would be great to confirm so that the wiki pages that teach the method I suggested above can be edited.
]]>edit /lib/systemd/system/systemd-user-sessions.service and append network.target to the after line.
[Unit]
Description = Permit User Sessions
Documentation = man:systemd-user-sessions.service(8)
After = network.target remote-fs.target
then symlink /lib/systemd/system/systemd-user-sessions.service to /etc/systemd/system/
Hope this helps someone else.
]]>From my understanding of the problem at hand, systemd brings down the sshd.service and network.service, but the SSH connections are never killed. Instead the connection just hangs until the TCP timeout is reached in which case you will get a software connection error if you are using Putty. It would *NOT* be recommended to create a script within SSHD to kill all connections whenever the SSHD is stopped or restarted due to the fact that there are situations where you need to restart the daemon while logged in via SSH, without killing your own connection.
On the other hand it may be possible to create a script that is executed whenever the system is restarted or shutdown that would canvas the system for logged in SSH users and kill the connections, however I do not have the foggiest idea where to start or how to go about doing this, and that is if it is even possible via systemd or some other means.
Anyone have any other suggestions?
On a side note, there are quite a few bugs listed for this specific problem on different distributions, however no solutions were mentioned.
]]>You must configure your network service (netcfg, NetworkManager, ... ) to stop sshd.service before bringing down the network.
]]>Thanks!
- Aaron
]]>