Re: autofs/automount gone wild - Ubuntu

This is a discussion on Re: autofs/automount gone wild - Ubuntu ; * Hactar : > I wrote a few scripts, and they run in the background and from /export > (sda5), which is under the control of automount/autofs. I noted frequent > long pauses where nothing happened yet the disk I/O ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: autofs/automount gone wild

  1. Re: autofs/automount gone wild

    * Hactar :
    > I wrote a few scripts, and they run in the background and from /export
    > (sda5), which is under the control of automount/autofs. I noted frequent
    > long pauses where nothing happened yet the disk I/O light was on solid.
    > So I looked in the log to see what was happening -- fsck, forced by
    > remount count, on each automounted partition, but mainly sda5. It's
    > being mounted about every 10 minutes -- see


    Based on the information provided later in the message, you're using
    ext3. Forcing a fsck based on mount count is unnecessary since ext3 is
    journalled. It's necessary to fsck an ext3 only if it fails to mount
    cleanly, or you have other reason to believe there is some filesystem
    corruption. See tune2fs(1) for ways to disable mount-count and
    time-interval checking.

    $ sudo tune2fs -c 0 /dev/sda5

    would disable mount-count checking.

    > http://royalty.mine.nu:81/remounts.png
    >
    > I don't know what the deal is with those very short intervals. And
    > anyhow, I don't know why it would use 10 minutes:
    >
    > eben@pc:~$ grep sda5 /etc/auto.*
    > /etc/auto.misc:export -fstype=ext3 :/dev/sda5
    > eben@pc:~$ grep misc /etc/auto.*
    > /etc/auto.master:/misc /etc/auto.misc --timeout=450
    >
    > (450 seconds is 7.5 minutes -- I'll have to lengthen that.)
    >
    > Maybe some second automounter is running and _its_ timeout is 10
    > minutes?
    >
    > Apparently, while the scripts are running, the OS allows the filesystem to
    > fall idle, but as soon as it's unmounted, requests it again.
    >
    > How can I stop this behavior, so the filesystem can't be unmounted
    > while the scripts are running, or the scripts don't particularly care
    > if it's mounted?


    I would have thought that a filesystem could not be unmounted while in
    use. This certainly appears to be the case when a filesystem has been
    mounted directly (not through autofs).

    automount is typically used for network filesystems and sometimes
    removeable media. Unless you're using a removeable hard disk, is there
    some other requirement that prevents the filesystem from being mounted
    via fstab?

    --
    James Michael Fultz
    Remove this part when replying ^^^^^^^^

  2. Re: autofs/automount gone wild

    In article ,
    James Michael Fultz wrote:
    > * Hactar :
    > > I wrote a few scripts, and they run in the background and from /export
    > > (sda5), which is under the control of automount/autofs. I noted frequent
    > > long pauses where nothing happened yet the disk I/O light was on solid.
    > > So I looked in the log to see what was happening -- fsck, forced by
    > > remount count, on each automounted partition, but mainly sda5. It's
    > > being mounted about every 10 minutes -- see

    >
    > Based on the information provided later in the message, you're using
    > ext3. Forcing a fsck based on mount count is unnecessary since ext3 is
    > journalled. It's necessary to fsck an ext3 only if it fails to mount
    > cleanly, or you have other reason to believe there is some filesystem
    > corruption. See tune2fs(1) for ways to disable mount-count and
    > time-interval checking.


    I guess checking at mount periodically is OK, but I see no reason to
    remount sda5 every 9m 55s (over the last 3 days at least). Good thing
    it's not on its own drive.

    > > Apparently, while the scripts are running, the OS allows the filesystem to
    > > fall idle, but as soon as it's unmounted, requests it again.
    > >
    > > How can I stop this behavior, so the filesystem can't be unmounted
    > > while the scripts are running, or the scripts don't particularly care
    > > if it's mounted?

    >
    > I would have thought that a filesystem could not be unmounted while in
    > use. This certainly appears to be the case when a filesystem has been
    > mounted directly (not through autofs).


    I thought so too. Maybe it doesn't apply here for some reason.

    eben@pc:~$ lsof | grep export
    eben@pc:~$ mount | grep export
    /dev/sda5 on /misc/export type ext3 (rw)
    eben@pc:~$ sudo umount /export ; sleep 5 ; mount | grep export
    eben@pc:~$ sudo /export/bin/monitor-cid
    eben@pc:~$ sudo /export/bin/logmonitor
    # Those two scripts run most of themselves in the background
    eben@pc:~$ logger -t pidgin test ; mount | grep export
    /dev/sda5 on /misc/export type ext3 (rw)
    eben@pc:~$ lsof | grep export
    eben@pc:~$

    I suppose they could've cded to somewhere in /export, done something,
    then cded back, but I'm guessing when that message appeared in the
    system log, /export/bin/logmonitor had to check something with its
    on-disk copy. Maybe.

    > automount is typically used for network filesystems and sometimes
    > removeable media. Unless you're using a removeable hard disk, is there
    > some other requirement that prevents the filesystem from being mounted
    > via fstab?


    I have a backup process that runs in the middle of the night (or I will
    when I finish the upgrading). It makes a direct copy of sda onto sdb
    (not enough cable to make it sdc). I'd like most filesystems to be
    unmounted (and hence *cleanly* unmounted) when it runs. I have to run
    autofs/automount _anyway_ to handle optical media, USB things, etc. so I
    figured "what the hey".

    --
    -eben QebWenE01R@vTerYizUonI.nOetP royalty.mine.nu:81
    LIBRA: A big promotion is just around the corner for someone
    much more talented than you. Laughter is the very best medicine,
    remember that when your appendix bursts next week. -- Weird Al

  3. Re: autofs/automount gone wild

    * Hactar :
    > In article ,
    > James Michael Fultz wrote:

    [ ... ]
    >> I would have thought that a filesystem could not be unmounted while in
    >> use. This certainly appears to be the case when a filesystem has been
    >> mounted directly (not through autofs).

    >
    > I thought so too. Maybe it doesn't apply here for some reason.
    >
    > eben@pc:~$ lsof | grep export
    > eben@pc:~$ mount | grep export
    > /dev/sda5 on /misc/export type ext3 (rw)
    > eben@pc:~$ sudo umount /export ; sleep 5 ; mount | grep export
    > eben@pc:~$ sudo /export/bin/monitor-cid
    > eben@pc:~$ sudo /export/bin/logmonitor
    > # Those two scripts run most of themselves in the background
    > eben@pc:~$ logger -t pidgin test ; mount | grep export
    > /dev/sda5 on /misc/export type ext3 (rw)
    > eben@pc:~$ lsof | grep export
    > eben@pc:~$
    >
    > I suppose they could've cded to somewhere in /export, done something,
    > then cded back, but I'm guessing when that message appeared in the
    > system log, /export/bin/logmonitor had to check something with its
    > on-disk copy. Maybe.


    My thinking is that the shell would be holding the file containing the
    script open until the script terminates whether by reaching its end or
    forking another process. As long as the shell holds that file open, the
    filesystem should be busy.

    Perhaps creating a 'lockfile' on the filesystem would help to keep it
    from being prematurely unmounted. Something like this:

    lock_file () {
    while touch /export/somedir/.lockfile
    do
    # wait five minutes
    sleep 300
    done
    }

    lock_file & lockpid=$!

    ....

    kill $lockpid

    >> automount is typically used for network filesystems and sometimes
    >> removeable media. Unless you're using a removeable hard disk, is there
    >> some other requirement that prevents the filesystem from being mounted
    >> via fstab?

    >
    > I have a backup process that runs in the middle of the night (or I will
    > when I finish the upgrading). It makes a direct copy of sda onto sdb
    > (not enough cable to make it sdc). I'd like most filesystems to be
    > unmounted (and hence *cleanly* unmounted) when it runs. I have to run
    > autofs/automount _anyway_ to handle optical media, USB things, etc. so I
    > figured "what the hey".


    Another approach may be to have your scripts mount and unmount the
    filesystem as needed. To ensure that the filesystem was always cleanly
    unmounted, you could use a trap statement such as the following:

    trap 'umount /export' 1 2 15

    --
    James Michael Fultz
    Remove this part when replying ^^^^^^^^

+ Reply to Thread