On Fri, 23 Jan 2004, Mike Marion wrote:
>
> Ok, I did a strace of the dameons on
> /usr/local/projects/some/automount and ./submount
> It appears that the daemon on .../submount does, in fact, try to umount
> itself after the NFS mounts are expired, without checking to see if
> it's path is busy, and when the umount fails, it simply tries to do an
> rmdir and then exits, even though this bit of code in automount.c seems
> to indicate that if umount fails it should stay runnnig:
>
> ~line 562:
> case ST_PRUNE:
> /* If we're a submount and we've just
> pruned or expired everything away,
> try to shut down */
> if (submount && success && ap.state !=
> ST_SHUTDOWN) {
> next = ST_SHUTDOWN_PENDING;
> break;
> }
> /* FALLTHROUGH */
>
> case ST_READY:
> next = ST_READY;
> break;
>
> case ST_SHUTDOWN_PENDING:
> next = ST_SHUTDOWN;
>
> [This doesn't appear to be happening, even though umount fails]
> /* Failed shutdown returns to ready */
> if (!success) {
> syslog(LOG_WARNING,
> "shutdown failed:
> filesystem %s still busy",
> ap.path);
> alarm(ap.exp_runfreq);
> next = ST_READY;
> }
> break;
Good work Mike. This will help me alot. However I don't think the daemon
actually gets to this point. Checking ....
>
> ====
>
> This subroutine appears to be called, even though the submount wasn't
> umounted, since it's where the log entry
> Jan 23 12:46:22 linux-glab-1 automount[31939]: failed to remove dir
> /usr/local/projects/some/automount/submount: Device or resource busy
> seems to be coming from:
>
> static void cleanup_exit(const char *path, int exit_code)
> {
> if (ap.lookup)
> close_lookup(ap.lookup);
>
> if (pid_file)
> unlink(pid_file);
>
> closelog();
>
> if ((!ap.ghost || !submount) && *(path + 1) != '-')
> if (rmdir(path) == -1)
> syslog(LOG_WARNING, "failed to remove dir %s:
> %m", path);
>
> exit(exit_code);
> }
Called when the daemon pops out of the event loop.
Can be caused by umount failure. I saw something like this the other day
and I've been meaning to return to it to try and find it.
Jim Carter would like this. I caused it by an incorect return from buffer
overflow checking code. I think this problem is hitting the same bad error
handling code. Looking ...
Ian
_______________________________________________
autofs mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/autofs
