LACROIX Jean Marc <jeanmarc.lacr...@free.fr> writes: > I confirm this behaviour on Debian Jessie with following packages....
So far, everyone who has had this problem is having trouble because they have mounts configured in /etc/fstab that are failing. Judging from the large number of mounted file systems you have, I suspect a similar issue. systemd takes a different attitude towards failing mounts and treats them as fatal by default. If you mount file systems from /etc/fstab that may or may not be present, could you try adding "nofail" to the mount options for those mounts? This is really a bug in the process of switching to systemd that doesn't catch this problem and either add nofail or provide some warning. We need to sort this out before the release. However, separately... > In order to be sure, i make a trivial test ..... > root@choobaka:~# /usr/sbin/sshd -t; echo $? > Missing privilege separation directory: /var/run/sshd > 255 > which is a correct behaviour for sshd daemon.......but .... > root@choobaka:~# /etc/init.d/ssh start;echo $? > [ ok ] Restarting ssh (via systemctl): ssh.service. > 0 > ..is not a correct behaviour because systemd can NOT detect error. > It seems that /etc/init.d/ssh script does not test output value for sshd > daemon ...this sounds on the surface like a good idea. In general, I think any daemon that has a configuration and a test mode should test the configuration before starting, or at least before restarting, so that it can clearly diagnose configuration errors. Maybe I'm missing some problem for doing this with sshd, though. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
