On Tue, Feb 11, 2014 at 10:18:52PM +0200, Uoti Urpala wrote: > Colin Watson wrote: > > 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).
OK. I've pushed this commit: http://anonscm.debian.org/gitweb/?p=pkg-ssh/openssh.git;a=commitdiff;h=a92ab9ee301bc9196bb20f4923886f021f070521 Let me know if that still looks wonky. > > 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. I don't have a broad enough view of this to know whether it's common enough to matter. As a general rule when I add this kind of check I won't remove it unless I've seen a conclusive demonstration that the root cause has been fixed (which seems unlikely in this case since it probably isn't a single root cause) or it's already been superseded elsewhere. So I don't mind if systemd wants to do it but until then I'll keep the check in my service file. > 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. Well, of course it is already done in the binary by way of libc's daemon(), it's just that the error message is dreadful. :-) It hasn't been *that* important to me so I just went for the lowest-maintenance approach rather than refining it; I've already spent more time discussing it in this thread than I spent maintaining it in the last six years. Again, yeah, it probably ought to be done in the binary and upstreamed etc., I've just had better things to do. I don't mind if somebody feels the need to chase this upstream. > 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. Curious. I thought I'd tested this upgrade path. What would have called daemon-reload? Do you by chance happen to have a log of the upgrade (say, from /var/log/apt/term.log)? If the old initscript-started sshd is still running, I would have expected its pid file to still be around, in which case start-stop-daemon should work. Perhaps I'm missing something. -- Colin Watson [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
