Colin Watson wrote: > On Tue, Feb 11, 2014 at 12:32:34AM +0100, Michael Biebl wrote: > > Do you think it would be helpful if we write a small paragraph in > > README.Debian explaining the two different modes and how to enable/use them? > > I already did. :-) > > systemd socket activation > ------------------------- > > If you want to reconfigure systemd to launch sshd using socket activation, > then you can run:
I think this would benefit from a more clear explanation of the activation mode, namely that it means launching a per-connection daemon in "Accept=yes" mode. As written, this could be confused with default systemd socket activation mode, as in systemd passing a listening socket to sshd (which would be strictly superior to the current behavior with sshd opening the socket itself, but which is not supported by upstream sshd yet AFAIK). > > I also wonder why the following check was added: > > > > ExecStartPre=/usr/bin/test -c /dev/null > > > > Why is this needed? Seems rather odd to me. With devtmpfs being > > mandatory (in systemd/udev) nowadays, /dev/null is guaranteed to exist. > > Do you remember why this check was added? Afaics it doesn't seem > > necessary anymore nowadays. > > Russ already provided a link to the original bug. While I never tracked > down the exact script that was at fault for the users in question, as > it's very difficult to find retroactively, it can happen any time some > script accidentally does "rm /dev/null", at which point the next thing > to run as root and redirect to /dev/null will create it as a regular > file. Nothing about systemd/udev prevents this from happening. Yes, > this is absolutely somebody else's bug, and it seems to be pretty rare, > but when it happens I don't want to have to spend time dealing with the > bug reports. A quick test call seems worth it. IMO it seems questionable to do this in the startup script of a single package. If it's a common enough problem to matter then it should be done more centrally, such as systemd itself doing a sanity check. And if it's a meaningful sanity check for sshd in particular, then it looks like something that should be added to the binary rather than be run as a separate shell check. There also seems to be a problem with transitioning from the init script to the .service on a system with sshd running. I got messages like "sshd[25017]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use." in journal, while the old sshd process from before the upgrade was still running. I think the problem is that the .service is installed and "systemctl daemon-reload" run while the old initscript-started sshd is running, and this sshd was started WITHOUT "-D". This process is not recognized as the main process, but is left to run under the .service, which has "KillMode=process". Postinst has a comment saying "We must stop the sysvinit-controlled sshd before we can restart it under systemd." and a "start-stop-daemon --stop" call, but I think this is too late - the above has already happened and the --stop will no longer work. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
