On 25.09.2012 19:34, Reinhard Tartler wrote: > On Tue, Sep 25, 2012 at 5:14 PM, Michael Tokarev <m...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org