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

[Michael Tokarev]

On 25.09.2012 19:34, Reinhard Tartler wrote:
> 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 want to push one more release of autofs to sid (with aim to go
to wheezy) today or tomorrow, with fixes for lots of other bugs.
I know bpo60 hasn't been updated yet, but so is wheezy too, as
we're waiting for the release team answer.  The unblock request
I sent is already of no use, since I already uploaded a new
release and want to update it even further.

It isn't really good idea to update bpo before the release team
accepts stuff to wheezy, or havoc will happen.

>> I'm not sure we should teach it about this situation.

And indeed, I forgot that s-s-d isn't the case in wheezy and
squeeze yet.

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

It is 0001-Remove-kernel-mount.nfs-version-checks-on-Debian-Ubu.patch,
which removes spawning off mount.nfs at startup to determine its version.
It is #678555 in debian.

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

I know nothing about autofs kernel module, except of just one chance
I had with it this spring (iirc), which discovered lots of bad logic
in there (it was 32/64 bit issue).

But at least now when I'm aware of the issue and as I somehow become
autofs maintainer I can try to experiment and sum it up.  I can't
promise anything obviously, but I'll try...

Thanks,

/mj