> 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. > 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
