I believe this is the same bug as identified in #399614 (autofs:
dont_create_remote_dirs patch relies on /etc/mtab). I built an autofs
package excluding the 077_dont_create_remote_dirs patch, and it was able
to create its mountpoints again.
That also explains why strace did not show any call to
I'm encountering this exact problem. Using strace to compare the listed
successful run with my problematic run, I see that mkdir is never called:
[pid 26064] stat64(/java, 0xbeeb5428) = -1 ENOENT (No such file or
directory)
[pid 26064] open(/etc/mtab, O_RDONLY) = 4
[pid 26064] fstat64(4,
On Sun, 2009-08-02 at 01:40 +0200, Jan Christoph Nordholz wrote:
Hi Michael,
No idea. If I were knew, I'd attach a patch for this issue.
The code is quite.. funny and fragile, I tried to understand
it right before submitting a bugreport but that wasn't quite
successful.
I ran it
Hi Michael,
No idea. If I were knew, I'd attach a patch for this issue.
The code is quite.. funny and fragile, I tried to understand
it right before submitting a bugreport but that wasn't quite
successful.
I ran it under strace - pure automountd, without any startu
scripts but with the
Hi Michael,
(the following holds for both autofs v4 and v5)
usually the daemon creates these directories on startup and removes
them on exit. If you do not want that to happen, it suffices to
mark the directory as u-w:
] r...@apocatequil:/etc# grep ^/misc /etc/auto.master
] /misc
Jan Christoph Nordholz wrote:
Hi Michael,
(the following holds for both autofs v4 and v5)
usually the daemon creates these directories on startup and removes
them on exit. If you do not want that to happen, it suffices to
mark the directory as u-w:
] r...@apocatequil:/etc# grep ^/misc
Hi,
As I mentioned before, the ONLY way to stop it from
removing the top-level dir is to chattr+i it.
ah, autofs4 indeed removes the directory even without write permission
(v5 doesn't), I thought I'd checked that, too. But this behaviour has
been around for ages, and I still don't understand
Jan Christoph Nordholz wrote:
Hi,
As I mentioned before, the ONLY way to stop it from
removing the top-level dir is to chattr+i it.
ah, autofs4 indeed removes the directory even without write permission
(v5 doesn't), I thought I'd checked that, too. But this behaviour has
been around for
Package: autofs
Version: 4.1.4+debian-2.1
Severity: grave
When the automount daemon exits, it removes the top-level mountpoint
directory. For example, when auto.master contains
/net /etc/auto/net
and the /net dir exists before startup, on shutdown corresponding
automount process does right
9 matches
Mail list logo
