Hi Colin, I noticed that you added systemd .service files in openssh 1:6.5p1-1. Thanks a lot for that! There are a few issues though that I noticed which I'd like to discuss. SSH supports two modes: a/ The traditional way of being started via ssh.service, which starts the service on boot via multi-user.target (basically what the SysV init script does, daemon mode) b/ On-demand starting via socket activation using: ssh.socket + ssh@.service. This will only setup the socket file defined in ssh.socket and start sshd on demand on incoming requests. (inetd mode) I think it makes sense to keep using the traditional setup i.e. a/ and if an administrator wants mode b/ it should be enabled explicilty (and ssh.service disabled). But the package both enables ssh.socket and ssh.service (in postinst), which is kinda odd. They shouldn't be used at the same time. Maybe this is just an oversight? ssh.socket specifically includes Conflicts=ssh.service, so what happens now is that systemd will setup ssh.socket early during boot (via sockets.target) and as soon as ssh.service is started (via multi-user.target), the ssh.socket unit will be stopped. 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 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. If you have further questions, we are happy to help. You can reach us via pkg-systemd-maintainers@lists.alioth.debian.org or #pkg-systemd on OFTC. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature