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

[Reinhard Tartler]

On Tue, Sep 25, 2012 at 5:14 PM, Michael Tokarev <mjt at tls.msk.ru> wrote:

> Autofs initscript uses start-stop-daemon with a pidfile option.

Oh, it seems that this has been rectified in by now wheezy, but not in
wheezy-backports yet. If you don't mind, I would update the backport
as I was the last uploader anyway.

> 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.

/run is not bind-mounted by default, but schroot can be instructed to
do so. As you correctly, point out, a bind-mounted /run will probably
cause problems.

>> 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.

We could of course argue about the 'fragile' part, but fragile or not,
stuff does work there :-)

> 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.

Which of the following patches would implement what you describe?
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/autofs/quantal/files/head:/debian/patches/

>
>> 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.

What I understood so far is that rbind mounts cause vfs semantics that
do not play well with autofs. Since you seem to have way more
knowledge than I have on this matter, maybe you could file a proper
bug report with a compilation of all relevant pieces of information?


-- 
regards,
    Reinhard