Bug#645788: openssh-server: /run on tmpfs breaks sshd started, from inetd

[Russ Allbery <rra@debian.org>]

Paul Millar <paul.millar@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>