On Tue, Feb 11, 2014 at 1:52 PM, Colin Watson <[email protected]> wrote: > 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. After upgrading to sid I ended up getting only the socket-activated sshd, and having ssh.service fail to the port being already taken by ssh.socket. I had to systemctl disable ssh.socket
> >> > 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]] > > _______________________________________________ > Pkg-systemd-maintainers mailing list > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers -- Shawn Landden +1 360 389 3001 (SMS preferred) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAJusiZWWASJwLsXHj85OB8uMt55xGxWyuRocoVSjW_AEp=--e...@mail.gmail.com
