All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Stef Bon <stef@bononline.nl>
Cc: autofs mailing list <autofs@linux.kernel.org>
Subject: Re: Suggestion for better manpage.
Date: Tue, 17 Jun 2008 20:13:56 +0800	[thread overview]
Message-ID: <1213704836.20728.10.camel@raven.themaw.net> (raw)
In-Reply-To: <200806171257.45914.stef@bononline.nl>


On Tue, 2008-06-17 at 12:57 +0200, Stef Bon wrote:
> Hello,
> 
> reading the manpage of automount, I would like to change the section in the 
> manpage about how the daemon reacts on signals.

Send a patch.

> 
> It is now:
> 
> 
> If  the  automount  daemon  catches  a  USR1  signal, it will umount all 
> currently unused autofs managed mounted file systems and continue running
>        (forced expire).  If it catches the TERM signal it will umount all 
> unused autofs managed mounted file systems and exit if there are  no  
> remaining
>        busy  file systems. If autofs has been compiled with the option to 
> ignore busy mounts on exit it will exit leaving any busy mounts in place 
> other-
>        wise busy file systems will not be umounted and autofs will not exit.  
> Alternatively, if autofs has been compiled with the option to enable forced
>        shutdown then a USR2 signal to the daemon will cause all mounts to be 
> umounted and any busy mounts to be forcibly umounted, including autofs mount
>        point directories (summary execution). Note that the forced umount is 
> an unlink operation and the actual umount will not happen in the kernel  un-
>        til active file handles are released.  The daemon also responds to a 
> HUP signal which triggers an update of the maps for each mount point.
> 
>        If any autofs mount point directories are busy when the daemon is sent 
> an exit signal the daemon will not exit. The exception to this is if autofs
>        has been built with configure options to either ignore busy mounts at 
> exit or force umount at exit. If the ignore busy mounts at  exit  option  is
>        used  the filesystems will be left in a catatonic (non-functional) 
> state and can be manually umounted when they become unused. If the force 
> umount
>        at exit option is used the filesystems will be umounted but the mount 
> will not be released by the kernel until they are no longer in  use  by  the
>        processes that held them busy.  If automount managed filesystems are 
> found mounted when autofs is started they will be recoverd unless they are no
>        longer present in the map in which case they need to umounted manually.
> 
> I would like to suggest:
> 
> The automount daemon can react on a few signals. Some of them are standard, 
> others are less standard and/or need compiletime options.
> 
> TERM
> 
> If it catches the TERM signal it will umount all unused autofs managed mounted 
> filesystems, and exit if there are no remaining mounts left. It will keep on 
> running (till??)

You eventually send a TERM signal and no mounts are in use.

> If compiled with the "ignore busy mounts" option, it will exit here, and leave 
> any mountpoint in place.
> 
> USR2
> This only applies when the automounter is compiled with the "enable forced 
> shudown". When it catches the USR2, it will umount all mounts, busy or not. 
> Note: umounting a busy mountpoint  is actually an unlink operation. The actual 
> umount will be done later, when all active file handleds are released. (this 
> id done by??)

Kernel.

> 
> USR1
> With the USR1 signal it will umount all currently unused mounts, and continue 
> running (forced expire).
> 
> HUP
> This signal triggers an update of the maps for each mountpoint.
> 
> 
>  I've left out some parts, but mostly rearranged the information. I've left 
> out the text "summary execution" Is it important?
> 
> But what do you think. Is it better this way?
> 
> Stef Bon
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

  reply	other threads:[~2008-06-17 12:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-17 10:57 Suggestion for better manpage Stef Bon
2008-06-17 12:13 ` Ian Kent [this message]
2008-06-17 14:44   ` Jeff Moyer
2008-06-17 17:20     ` Stephen Biggs
2008-06-18  6:41     ` Stef Bon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1213704836.20728.10.camel@raven.themaw.net \
    --to=raven@themaw.net \
    --cc=autofs@linux.kernel.org \
    --cc=stef@bononline.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.