automounter gone useless
Hactar
I have an automounter managing my filesystems except for those I
always want mounted (e.g. /, /usr, /home), and those that aren't on disk
(e.g. /proc, /sys), on the theory that if the machine crashes fewer
filesystems will need cleanup, as fewer will be mounted.
However, something is doing _something_ to cause most filesystems to be
mounted constantly. Here's a sampling:
Feb 21 19:35:46 pc automount[28490]: >> mp3: clean, 11454/7880704 files, 14305633/15729635 blocks
Feb 21 19:45:10 pc automount[30331]: >> mp3: clean, 11454/7880704 files, 14305633/15729635 blocks
Feb 21 20:00:12 pc automount[3127]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
Feb 21 20:43:34 pc automount[11665]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
Feb 21 20:52:59 pc automount[13460]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
Feb 21 21:02:25 pc automount[15262]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
Feb 21 21:11:50 pc automount[17236]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
Feb 21 21:21:15 pc automount[19336]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
Feb 21 21:30:41 pc automount[21173]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
(My timeout for that filesystem is 600 seconds (10 minutes).)
How can I find out what is doing this, and more importantly, make it
stop?
--
-eben QebWe...@vTerYizUonI.nOetP http://royalty.mine.nu:81
AQUARIUS: There's travel in your future when your tongue freezes to the
back of a speeding bus. Fill the void in your pathetic life by playing
Whack-a-Mole 17 hours a day. -- Weird Al, _Your Horoscope for Today_
Tim Greer
Are you talking about the "noauto" option or something else? The noauto
option should prevent automount.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
Allen Kistler
> Hactar wrote:
>
>> I have an automounter managing my filesystems except for those I
>> always want mounted (e.g. /, /usr, /home), and those that aren't on
>> disk (e.g. /proc, /sys), on the theory that if the machine crashes
>> fewer filesystems will need cleanup, as fewer will be mounted.
>>
>> However, something is doing _something_ to cause most filesystems to
>> be
>> mounted constantly. Here's a sampling:
>>
>>
>> (My timeout for that filesystem is 600 seconds (10 minutes).)
>>
>> How can I find out what is doing this, and more importantly, make it
>> stop?
>
> Are you talking about the "noauto" option or something else? The noauto
> option should prevent automount.
automount is a daemon that mounts removable media and nfs automatically,
but only when something needs it. After a preset idle timeout, it's
unmounted automatically.
I'd suggest running autofs with -v. You can set OPTIONS to "-v" in
/ets/sysconfig/autofs if you're running Fedora, Red Hat, or one of their
clones. According to the man page, verbose mode is supposed to log
progress on all actions, though I've never tried it.
BTW, do you have a file integrity monitor running? Something like
Tripwire or a rootkit checker would scan your whole filesystem regularly.
Hactar
Tim Greer <t...@burlyhost.com> wrote:
> Hactar wrote:
>
> > Crud. Forgot to fix the subject. I'll try this posting again...
> >
> > I have an automounter managing my filesystems except for those I
> > always want mounted (e.g. /, /usr, /home), and those that aren't on
> > disk (e.g. /proc, /sys), on the theory that if the machine crashes
> > fewer filesystems will need cleanup, as fewer will be mounted.
> >
> > However, something is doing _something_ to cause most filesystems to
> > be
> > mounted constantly. Here's a sampling:
[snip]
> > How can I find out what is doing this, and more importantly, make it
> > stop?
>
> Are you talking about the "noauto" option or something else? The noauto
> option should prevent automount.
You mean in /etc/fstab? The filesystems in question aren't listed there
at all. It's the automounter that's controlled by autofs/automount and
/etc/auto.{master,misc,...). I guess that's not the kernel one, but
rather the userspace one. Like so:
eben@pc:~$ grep mp3 /etc/auto.*
/etc/auto.misc:mp3 -fstype=ext3 :/dev/sda12
eben@pc:~$ grep auto.misc /etc/auto.*
/etc/auto.master:/misc /etc/auto.misc --timeout=450
Oops, not 600s (10m) but 450s (7m30s).
--
-eben QebWe...@vTerYizUonI.nOetP http://royalty.mine.nu:81
SAGITTARIUS: All your friends are laughing behind your back... kill
them. Take down all those naked pictures of Ernest Borgnine you've
got hanging in your den. -- Weird Al, _Your Horoscope for Today_
Dan Espen
That type of automounting takes place as any process changes
directory into the mount point.
To find out which process caused the file to mount do as root:
lsof | grep mp3
(substitute for "mp3" the place where the file is mounted.)
Tim Greer
> You mean in /etc/fstab?
Yeah, I was heading out of the office and didn't read the post well
enough (I wanted to get the reply out before I left). Sorry about
that.
Hactar
Nothing shows up:
eben@pc:~$ sudo lsof | grep -e mp3 -e media -e torrent
eben@pc:~$
Whatever's doing is transient. I'd hope that if it were continuously
running, the filesystem couldn't have been unmounted in the first place.
Now, is it possible I have a second automounter running, where #2 is idle
except for poking #1 when a filesystem is automatically unmounted? How do
I find out if that's the case?
--
-eben QebWe...@vTerYizUonI.nOetP royalty.mine.nu:81
Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein
Hactar
Allen Kistler <acki...@oohay.moc> wrote:
> Tim Greer wrote:
> > Hactar wrote:
> >
> >> I have an automounter managing my filesystems except for those I
> >> always want mounted (e.g. /, /usr, /home), and those that aren't on
> >> disk (e.g. /proc, /sys), on the theory that if the machine crashes
> >> fewer filesystems will need cleanup, as fewer will be mounted.
> >>
> >> However, something is doing _something_ to cause most filesystems to
> >> be
> >> mounted constantly. Here's a sampling:
> >>
> >> [snip]
> >>
> >> (My timeout for that filesystem is 600 seconds (10 minutes).)
> >>
> >> How can I find out what is doing this, and more importantly, make it
> >> stop?
> >
> > Are you talking about the "noauto" option or something else? The noauto
> > option should prevent automount.
>
> automount is a daemon that mounts removable media and nfs automatically,
> but only when something needs it. After a preset idle timeout, it's
> unmounted automatically.
>
> I'd suggest running autofs with -v. You can set OPTIONS to "-v" in
> /ets/sysconfig/autofs if you're running Fedora, Red Hat, or one of their
> clones. According to the man page, verbose mode is supposed to log
> progress on all actions, though I've never tried it.
OK, I set "daemonoptions" to "-v" in /etc/init.d/autofs and stopped and
started it. Here's what I saw in /var/log/syslog after a few minutes:
Feb 22 23:26:20 pc automount[18125]: expired /misc/mp3
Feb 22 23:26:20 pc automount[15521]: attempting to mount entry /misc/mp3
Feb 22 23:26:21 pc automount[18147]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
Feb 22 23:26:21 pc kernel: kjournald starting. Commit interval 5 seconds
Feb 22 23:26:21 pc kernel: EXT3 FS on sda12, internal journal
Feb 22 23:26:21 pc kernel: EXT3-fs: mounted filesystem with ordered data mode.
No extra details there. Odd that there are different PIDs in lines 2
and 3.
I quit gkrellm on the off chance it was causing this behavior. It's
still off; behavior still happens. So I'd say they're not related.
A little while ago, autofs wouldn't stop because automount for /misc
wouldn't exit because /misc/scratch wouldn't unmount. "sudo lsof | grep
scratch" returned nothing. Exiting X didn't work. Going to runlevel 1
might have worked, but it always screws up VMware to where I need to
reboot to fix it anyhow, so I just rebooted. It unmounted.
--
-eben QebWe...@vTerYizUonI.nOetP http://royalty.mine.nu:81
Every normal man must be tempted at times to spit upon his hands,
hoist the black flag, and begin slitting throats. -- H.L. Mencken
Hactar
> In article <DDkol.7596$jZ1....@flpi144.ffdc.sbc.com>,
> Allen Kistler <acki...@oohay.moc> wrote:
> > Tim Greer wrote:
> > >
> > I'd suggest running autofs with -v. You can set OPTIONS to "-v" in
> > /ets/sysconfig/autofs if you're running Fedora, Red Hat, or one of their
> > clones. According to the man page, verbose mode is supposed to log
> > progress on all actions, though I've never tried it.
>
> OK, I set "daemonoptions" to "-v" in /etc/init.d/autofs and stopped and
> started it. Here's what I saw in /var/log/syslog after a few minutes:
>
> Feb 22 23:26:20 pc automount[18125]: expired /misc/mp3
> Feb 22 23:26:20 pc automount[15521]: attempting to mount entry /misc/mp3
> Feb 22 23:26:21 pc automount[18147]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
> Feb 22 23:26:21 pc kernel: kjournald starting. Commit interval 5 seconds
> Feb 22 23:26:21 pc kernel: EXT3 FS on sda12, internal journal
> Feb 22 23:26:21 pc kernel: EXT3-fs: mounted filesystem with ordered data mode.
>
> No extra details there. Odd that there are different PIDs in lines 2
> and 3.
OK, that wasn't enough information (I want either the file/dir that was
accessed or the program doing the accessing), so I added "--debug". Now
I get (manual umount, as I didn't want to wait for it to time out):
Feb 23 01:00:47 pc automount[13243]: handle_packet: type = 0
Feb 23 01:00:47 pc automount[13243]: handle_packet_missing: token 217, name mp3
Feb 23 01:00:47 pc automount[13243]: attempting to mount entry /misc/mp3
Feb 23 01:00:47 pc automount[13797]: lookup(file): mp3 -> -fstype=ext3 :/dev/sda12
Feb 23 01:00:47 pc automount[13797]: parse(sun): expanded entry: -fstype=ext3 :/dev/sda12
Feb 23 01:00:47 pc automount[13797]: parse(sun): dequote("fstype=ext3") -> fstype=ext3
Feb 23 01:00:47 pc automount[13797]: parse(sun): gathered options: fstype=ext3
Feb 23 01:00:47 pc automount[13797]: parse(sun): dequote("/dev/sda12") -> /dev/sda12
Feb 23 01:00:47 pc automount[13797]: parse(sun): core of entry: options=fstype=ext3, loc=/dev/sda12
Feb 23 01:00:47 pc automount[13797]: parse(sun): mounting root /misc, mountpoint mp3, what /dev/sda12, fstype ext3, options
Feb 23 01:00:47 pc automount[13797]: do_mount /dev/sda12 /misc/mp3 type ext3 options using module ext3
Feb 23 01:00:47 pc automount[13797]: mount(ext2): calling mkdir_path /misc/mp3
Feb 23 01:00:47 pc automount[13797]: mount(ext2): calling /sbin/fsck.ext3 -p /dev/sda12
Feb 23 01:00:48 pc automount[13797]: >> mp3: clean, 11454/7880704 files, 14305630/15729635 blocks
Feb 23 01:00:48 pc automount[13797]: mount(ext2): calling mount -t ext3 -s -o /dev/sda12 /misc/mp3
Feb 23 01:00:48 pc kernel: kjournald starting. Commit interval 5 seconds
Feb 23 01:00:48 pc kernel: EXT3 FS on sda12, internal journal
Feb 23 01:00:48 pc kernel: EXT3-fs: mounted filesystem with ordered data mode.
Feb 23 01:00:48 pc automount[13797]: mount(ext2): mounted /dev/sda12 type ext3 on /misc/mp3
Feb 23 01:00:48 pc automount[13243]: handle_child: got pid 13797, sig 0 (0), stat 0
Feb 23 01:00:48 pc automount[13243]: sig_child: found pending iop pid 13797: signalled 0 (sig 0), exit status 0
Feb 23 01:00:48 pc automount[13243]: send_ready: token=217
Still doesn't say.
--
-eben QebWe...@vTerYizUonI.nOetP royalty.mine.nu:81
Hi! I'm a .sig virus! Copy me to your .sig!
Allen Kistler
> In article <fdl976-...@pc.home>, Hactar <ebenZ...@verizon.net> wrote:
>> In article <DDkol.7596$jZ1....@flpi144.ffdc.sbc.com>,
>> Allen Kistler <acki...@oohay.moc> wrote:
>>> I'd suggest running autofs with -v. You can set OPTIONS to "-v" in
>>> /ets/sysconfig/autofs if you're running Fedora, Red Hat, or one of their
>>> clones. According to the man page, verbose mode is supposed to log
>>> progress on all actions, though I've never tried it.
>>
>> OK, I set "daemonoptions" to "-v" in /etc/init.d/autofs and stopped and
>> started it. Here's what I saw in /var/log/syslog after a few minutes:
>>
>>
>> No extra details there. Odd that there are different PIDs in lines 2
>> and 3.
>
> OK, that wasn't enough information (I want either the file/dir that was
> accessed or the program doing the accessing), so I added "--debug". Now
> I get (manual umount, as I didn't want to wait for it to time out):
>
> Feb 23 01:00:47 pc automount[13243]: handle_packet: type = 0
> Feb 23 01:00:47 pc automount[13243]: handle_packet_missing: token 217, name mp3
>
>
I tried it myself. "-v" didn't tell me anything interesting, either,
but "--debug" spit out the following line, among others:
automount[5403]: handle_packet_missing_indirect: token 5, name nfs,
request pid 5352
where "nfs" is the key name of my mount. The process with pid 5352 is
the one that accessed the directory that needed to be mounted (bash in
my case, because I just cd'ed there). It is an indirect mount.
It's probably a difference in automount versions or builds between us
that mine reports the pid. So anyway, it seems possible with some
versions, although I wouldn't necessarily recommend playing musical
packages to find a version that reports it for you. I'm out of ideas on
how to track down the requesting process, though.
Hactar
being continually remounted by autofs/automount and I don't know why.
(/misc/export was too, but I did some thinking and realized too many
things I need are on there so it would usually be mounted anyhow, so I
made it permanently mounted via fstab.) I can manually umount them, but
a second later they're automatically remounted. This doesn't happen in
runlevel 1.
In runlevel 3 (X is there, it's not in runlevel 5) not logged into X,
everything's normal. When I log into X, scratch mounts permanently. I
commented out /misc/mp3 in /etc/auto.misc so it can't be automatically
mounted in hopes that something would break, and now every 5 seconds I get
two sets of this:
Mar 3 00:08:51 pc automount[24371]: attempting to mount entry /misc/mp3
Mar 3 00:08:51 pc automount[2521]: failed to mount /misc/mp3
Mar 3 00:08:51 pc automount[2521]: umount_multi: no mounts found under /misc/mp3
How do I find out what's responsible? I'm beginning to suspect some
part of VMware. I stopped Samba, sshd, portmap, nfs-user-server, edited
/etc/exports and /etc/samba/smb.conf and exited gkrellm and gedit to no
avail. "sudo lsof -n" in a very tight loop (it's been looping for most of
an hour) shows nothing. I greped "/mp3" from everything under ~, /etc,
and /usr nd turned up nothing useful. Any more ideas?
--
-eben QebWe...@vTerYizUonI.nOetP royalty.mine.nu:81
He who will not reason is a bigot; he who cannot is a fool;
and he who dares not is a slave. -Sir William Drummond