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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature