[buildd-tools-devel] Bug#688750: schroot and autofs need better integration

[Michael Tokarev]

On 25.09.2012 15:34, Reinhard Tartler wrote:
> Package: schroot,autofs
> Severity: normal
> 
> I have a setup in which the home directory is mounted via NFS with the
> help of autofs. Because of #622756 and #648459, bind-mounting /home
> with the rbind option is unfortunately not an option. Until this
> becomes possible, the chroot needs to start its own automount
> processes.

Well.  This is explained well in #648459.  Kernel side of this needs
to be fixed, and I agree completely -- this is the only reasonable
thing to do.  All the other ways to "fix" this issue will result in
other issues popping up.

> Schroot 1.6 features an option to start services. Unfortunately, this
> feature does not work with the autofs init script. Upon starting a
> squeeze chroot with autofs installed and enabled in the configuration,
> I get this error:
> 
>>> schroot -c squeeze-amd64
> I: 70services: Starting automount automount.../usr/sbin/automount
> already running.
> I: 70services: .
> W: Failed to change to directory ‘/home/siretart’: No such file or directory
> 
> I suspect this is because the autofs init script detects that there is
> already an automount instance running. Unfortunately, this is the
> instance outside the chroot.

Autofs initscript uses start-stop-daemon with a pidfile option.
I'm not sure we should teach it about this situation.

But as far as I understand, /run from host is bind-mounted to schroot
too, right?  If that's the case, we can't run two automountds this way
anyway, since the two will try to use the same pidfile, which will break.

> Interestingly, the service option does work with autofs in an
> ubuntu/quantal chroot, which uses upstart to manage and supervise
> services, just fine.

Upstart uses different, rather fragile, technique to watch for daemons.
Debian initscripts &Co uses pidfiles, upstart watches for forks.

Note that for this very reason stock autofs does not work here, since
it spawns mount proces during startup and upstart, who watches for
forks, thinks it is this mount which is the main process, and whole
things breaks.  Autofs had to be patched for ubuntu quantal to stop
doing checks at startup, because of this very reason.

> In order to solve this, I see two possibilities: a) enhance the autofs
> init script to become chroot-aware. b) extend schroot to start autofs
> managed mount points by itself, ideally using the host-provided autofs
> programs so that autofs does not need to be installed into the chroot.

There's one more solution which is not listed but which is the only
real solution: fix the real issue instead of designing workarounds
of various levels of "quality".

The thing is: autofs is very messy thing, both userspace and kernel.

/mjt