On Sun, 2015-11-08 at 00:22 -0800, Greg Earle wrote: > > On Nov 7, 2015, at 10:33 PM, Ian Kent <raven@xxxxxxxxxx> wrote: > > > > Do those directories actually exist within /home? > > Thanks for responding, Ian. > > "objects" exists (apparently due to tickling by the automounter) but > "refs" > does not: > > [root@mipldiv log]# ls -ltF /home | head -2 > total 40 > dr-xr-xr-x 2 root root 0 Nov 8 00:15 objects/ > > [root@mipldiv log]# ls -ltF /home/objects > ls: /home/objects: No such file or directory > > > Has the machine been up for a long time? > > Ironically, they started happening shortly AFTER the machine was > upgraded > from RHEL 5.4 to 5.10 (with several reboots). (It's been up for just > over > 4 days now, and it's still doing it every 15 or 30 minutes.) > > [root@mipldiv log]# grep failed messages | grep -v bin/nrpe | tail -5 > Nov 7 22:00:05 mipldiv automount[31419]: rmdir_path: lstat of > /home/refs failed > Nov 7 22:15:05 mipldiv automount[31419]: rmdir_path: lstat of > /home/objects failed > Nov 7 23:00:05 mipldiv automount[31419]: rmdir_path: lstat of > /home/refs failed > Nov 7 23:30:05 mipldiv automount[31419]: rmdir_path: lstat of > /home/refs failed > Nov 8 00:00:06 mipldiv automount[31419]: rmdir_path: lstat of > /home/objects failed > > > Are they actually causing a problem, other than annoyance value? > > Just an annoyance as far as I can tell - our Xymon monitoring system > triggers on "failed" so we get red alerts from the system(s) whenever > this happens. My officemate isn't happy :-) > > > They could be left over from when they where keys in a map but not > > removed on cleanup for some reason, or they could be the result of > > a > > failed or partial lookup and also not cleaned up on error. > > The keys were never in a map. That is what is so weird. I went to > our > Solaris NIS master and there is no reference to "objects" or "refs" > in > /etc/auto_home or /etc/auto_*. I can't imagine what could be running > that is trying to access those two phantom "/home" paths. Yeah, that function is called from a few places. At map read time, at autofs fs mount time and on HUP signal or if a lookup makes autofs think the map has been modified and at expire when attempting to remove a path on failed mount attempts for some fs types, notably NFS. The read map is driven by what's in the internal map entry cache so they could be negative entries added due to a failed lookup. The problem might be that the function could get called multiple times and fails on the later but that would imply bad path lookups occurring fairly regularly. Puzzling thing is I haven't had other reports of it. > > > You could try scheduling a reboot at some opportune time as that > > will > > result in a clean autofs directory at system startup since the > > autofs > > pseudo file system is RAM based. Then if the messages continue, it > > must > > be some process attempting access of a path starting with > > /home/<dir>. > > Well, given that the behavior really kicked in after the last post > -install > reboot, I'm guessing your latter explanation is far more likely. :-) > > I've just turned process accounting on to see what is running on > those > 15-minute intervals that might be triggering these. Already checked > the > "cron" jobs and there aren't any on that frequency. Most curious ... > > - Greg > > -- > To unsubscribe from this list: send the line "unsubscribe autofs" in -- To unsubscribe from this list: send the line "unsubscribe autofs" in
