Paul Millar <paul.mil...@desy.de> writes: > For the record, my problem was (or appears to have been) triggered by a > failure to mount an unrelated tmpfs file-system (/var/spool/cups/tmp) > earlier in the boot sequence. This failure was because /var/spool/cups > was a symlink pointing to another partition. If the other partition was > not mounted when attempting to mount /var/spool/cups/tmp, the mount > would fail.
> Removing the /var/spool/cups/tmp tmpfs entry in fstab "fixed" the > problem: on boot, the /run/sshd directory is created and sshd starts up > successfully. > I'll open a fresh ticket to discuss this problem with systemd since > their handling of directories (and tmpfs in particular) seems > problematic. I'm not sure this is related to tmpfs. I'm wondering if the mount process aborted because it failed to mount a directory and "nofail" was not specified for that mount. It would be interesting to see what systemd thought was the status of the various started services at the point at which you thought you had a fully booted system but /run/sshd didn't exist. I vaguely remember some other people noting that systemd and sysvinit are different in their handling of failures of file system mounts without nofail specified. -- 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
