* Jeffrey Anderson <JDAnderson AT lbl DOT gov> [20071220 10:51]:
> On Thursday 20 December 2007, "Dustin J. Mitchell" <dustin AT zmanda DOT com> 
> wrote:
> > On Dec 20, 2007 7:39 AM, Tim Bunnell <bunnell AT asel.udel DOT edu> wrote:
> > >  > Dec 19 23:45:06 helios automount[4754]: failed to mount /vol/rsma
> > >  > Dec 19 23:45:07 helios automount[4755]: failed to mount /vol/rhumgen
> > >  > Dec 19 23:45:07 helios automount[4756]: failed to mount /vol/rconfocal
> >
> > Any idea why the automounts themselves are failing?
> >
> > To rule out Amanda, take a look at the sendbackup and sendsize debug
> > logs for lines containing "Spawning".  These will show you the 'tar'
> > invocations which, I expect, will not contain the 'r'.
> >
> > Dustin
> 
> I experienced this same situation a couple of weeks ago.  It suddenly 
> started, 
> persisted for a couple weeks, then, just when I was about to ask the list, it 
> stopped!
> 
> The backups always proceeded as expected and there were no bad sideffects, 
> but 
> everytime amcheck or amdump ran there was an automount attempt to access 
> these non-existent directories.
> 
> For every DLE  named /home/SOMEUSER on the client amcheck (and amdump) 
> apparently also triggered an automount attempt for /home/rSOMEUSER.  In my 
> case, and I think in Tim's as well, the automounts fail because these 'r' 
> directories simply don't exist.
> 
> It only happened on one client.  It started happening without amanda being 
> updated on the client or the server.  I didn't pursue it further because it 
> never caused a problem and it stopped on its own, but it was very strange.

My 2¢...

I routinely see those on a few systems and I've never been able to
pinpoint where the automount errors are coming and how there are
triggered. Just for good measure here is what just happened this
morning on one of the amanda clients:

client syslog:
Dec 20 10:14:24 grumio automount[7198]: failed to mount /data/rbohbot
Dec 20 10:14:24 grumio automount[7199]: failed to mount /data/bohbot/rbohbot1
...
about 10 of them.

On the client runtar was spawn at 10:14:24

~# cat /tmp/amanda-av/client/right2/runtar.20071220101424.debug
runtar: debug 1 pid 7218 ruid 666 euid 0: start at Thu Dec 20 10:14:24 2007
runtar: time 0.000: version 2.5.2p1
/bin/tar version: tar (GNU tar) 1.14

config: right2
runtar: debug 1 pid 7218 ruid 0 euid 0: rename at Thu Dec 20 10:14:24 2007
running: /bin/tar: 'gtar' '--create' '--file' '-' '--directory'
'/export_raid12/bicadmin1/amanda-rsync' '--one-file-system'
'--listed-incremental'
'/opt/amanda/var/amanda/right2/gnutar-lists/grumio_export_raid12_bicadmin1_amanda-rsync_0.new'
'--sparse' '--ignore-failed-read' '--totals' '.' 
runtar: time 0.061: pid 7218 finish time Thu Dec 20 10:14:24 2007


The automount point failure (/data/bohbot/bohbot1) used to be a DLE
on some of the amanda configs I had setup in the past but it beats me
that somehow amanda 'remembers' that...why is she trying to mount the
(inexistant) associated raw device? No harm is done but I'd love to
iron out this little wrinkle :)

jf

> 
> 
> -- 
> --------------------------------------------------------------
> jeffrey anderson                      | jdanderson AT lbl DOT gov
> Lawrence Berkeley National Laboratory | Mailstop 50a-5101
> Phone: 510 486-4208                   | Fax: 510 486-6808

-- 
<° ><