Hi,

I've got this find command running out of a cronjob nightly:

find / -local -name .rhosts -exec grep '+' {} \;

The script (a csh script) actually has a variable set to have the above
find results. But the find command isn't finishing... it's just sitting
there and then a day goes by and now I've got two sitting there, and so
on and so on.

I did a truss to see what the process was doing, and saw this:

lstat64("/net", 0xFFBEF058) = 0
d=0x04180001 i=5 m=0040555 l=1 u=0 g=0 sz=1
at = Jun 8 14:17:33 EDT 2005 [ 1118254653 ]
mt = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
ct = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
bsz=8192 blks=1 fs=autofs
open64("/net", O_RDONLY|O_NDELAY) = 4
fcntl(4, F_SETFD, 0x00000001) = 0
fstat64(4, 0xFFBEEF50) = 0
d=0x04180001 i=5 m=0040555 l=1 u=0 g=0 sz=1
at = Jun 8 14:17:33 EDT 2005 [ 1118254653 ]
mt = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
ct = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
bsz=8192 blks=1 fs=autofs
getdents64(4, 0x000276B0, 1048) = 48
ino=5 off=1 rlen=24 "."
ino=3 off=2 rlen=24 ".."
getdents64(4, 0x000276B0, 1048) = 0
close(4) = 0
lstat64("/xfn", 0xFFBEF058) = 0
d=0x04180002 i=7 m=0040555 l=1 u=0 g=0 sz=1
at = Jun 8 14:17:33 EDT 2005 [ 1118254653 ]
mt = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
ct = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
bsz=8192 blks=1 fs=autofs
open64("/xfn", O_RDONLY|O_NDELAY) = 4
fcntl(4, F_SETFD, 0x00000001) = 0
fstat64(4, 0xFFBEEF50) = 0
d=0x04180002 i=7 m=0040555 l=1 u=0 g=0 sz=1
at = Jun 8 14:17:33 EDT 2005 [ 1118254653 ]
mt = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
ct = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
bsz=8192 blks=1 fs=autofs
getdents64(4, 0x000276B0, 1048) = 48
ino=7 off=1 rlen=24 "."
ino=3 off=2 rlen=24 ".."
getdents64(4, 0x000276B0, 1048) (sleeping...)

It looks like it got to /xfn and just sat there. I could see that
there's something wrong with /xfn, since I can cd there but can't do
anything at all. I'm sure I could reboot the system and this would
clear up... but who's to say it won't happen again?

I've tried several variations of the above find's syntax to try to avoid
/xfn, but nothing seems to work. The annoying thing is, when I try a
small test in my home directory doing a similiar search (looking for a
particular file with a '+' in it.... ), it correctly comes back with my
results when I actually put a '+' in a test file.

But when I try the same syntax as root and kick it off, within minutes
it hangs at the same place. Here's some of the variations that don't work:

find / -local -name 'xfn' -prune -o -name .rhosts -exec grep '+' {} \;
find / -fstype ufs -name 'xfn' -prune -o -name .rhosts -exec grep '+' {} \;

So I'm hoping that someone out there has either dealt with this specific
problem, or can assist me with my find syntax to get it working right.

Thanks in advance!

-chris

--
Chris Jones
(to email me, just take out the NOSPAM)

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B)
This email address may not be added to any commercial mail list with out
my permission. Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

On Mon, 13 Jun 2005 14:11:29 -0400, Chris Jones
<c.r.jonesNOSPAM@larc.nasa.gov> wrote:

>
>Hi,
>
>I've got this find command running out of a cronjob nightly:
>
>find / -local -name .rhosts -exec grep '+' {} \;
>
>The script (a csh script) actually has a variable set to have the above
>find results. But the find command isn't finishing... it's just sitting
>there and then a day goes by and now I've got two sitting there, and so
>on and so on.

[ snip ]

>So I'm hoping that someone out there has either dealt with this specific
>problem, or can assist me with my find syntax to get it working right.
>
>Thanks in advance!

The "/xfn" directory is under the control of the automounter. See "man
xfn" for details. I think that you can work around this issue by
unmounting the directory before using it. Though it's been a long time
since I've had to do this as I just commented it out of the
"/etc/auto_master" configuration file so that it's no longer under
control of the automounter.

Josh

Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> wrote:
> It looks like it got to /xfn and just sat there. I could see that
> there's something wrong with /xfn, since I can cd there but can't do
> anything at all. I'm sure I could reboot the system and this would
> clear up... but who's to say it won't happen again?

If you don't need /xfn (if you don't know what it does, you most
probably don't need it either) I'd disable it. It's not a normal
filesystem - the contents of /xfn are generated dynamically by
querying various name services.

Remove the /xfn entry from /etc/auto_master (and/or from any name service
that is mentioned in the "automount:" line in /etc/nsswitch.conf), and run
"automount -v". Afterwards, /xfn should be a regular, empty directory.

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Martin Paul wrote:
> Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> wrote:
>
>>It looks like it got to /xfn and just sat there. I could see that
>>there's something wrong with /xfn, since I can cd there but can't do
>>anything at all. I'm sure I could reboot the system and this would
>>clear up... but who's to say it won't happen again?
>
>
> If you don't need /xfn (if you don't know what it does, you most
> probably don't need it either) I'd disable it. It's not a normal
> filesystem - the contents of /xfn are generated dynamically by
> querying various name services.
>
> Remove the /xfn entry from /etc/auto_master (and/or from any name service
> that is mentioned in the "automount:" line in /etc/nsswitch.conf), and run
> "automount -v". Afterwards, /xfn should be a regular, empty directory.
>
> mp.

Ok... first off I was able to get the syntax I needed with the find
command to *avoid* the /xfn directory, so here's that for anybody that
might be able to benefit from it:

what didn't work ->
find / -local -name .rhosts -exec grep '+' {} \;

what does work ->
find / \( -name xfn -prune \) -o -local -name .rhosts -exec grep '+' {}
\; -print -o -fstype nfs -prune

Since find is such a complex command, I'm sure what I did could be done
simpler... but at least I found one variation that worked. Now onto the
/xfn comments that have been made.

Folks have been saying that /xfn is under the control of automounter...
and that I was aware of. But there's nothing at all running
automounter-wise. Sure, the line '/xfn -xfn' is in the
/etc/auto_master file, but as far as I can tell, nothing is referencing
this file. I can easily comment the line out, but if automounter isn't
running (we've long since disabled it ) I wouldn't think this would do
any good. The other suggestion of running 'automount -v' after
commenting '/xfn' out of /etc/auto_master only seems to apply if I was
actually running automountd.

So... thanks for the suggestions, but they all are related to
automount'ing which doesn't apply to me. Has anybody out there who's
*not* running automounter ever seen problems with the /xfn directory?

-chris

--
Chris Jones
(to email me, just take out the NOSPAM)

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B)
This email address may not be added to any commercial mail list with out
my permission. Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> wrote:
> Folks have been saying that /xfn is under the control of automounter...
> and that I was aware of. But there's nothing at all running
> automounter-wise.

Are you sure? The truss output in you first posting showed:

open64("/xfn", O_RDONLY|O_NDELAY) = 4
fcntl(4, F_SETFD, 0x00000001) = 0
fstat64(4, 0xFFBEEF50) = 0
d=0x04180002 i=7 m=0040555 l=1 u=0 g=0 sz=1
at = Jun 8 14:17:33 EDT 2005 [ 1118254653 ]
mt = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
ct = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
bsz=8192 blks=1 fs=autofs

See "fs=autofs" in the last line. What does "cd /xfn; df -k ." show?

> So... thanks for the suggestions, but they all are related to
> automount'ing which doesn't apply to me. Has anybody out there who's
> *not* running automounter ever seen problems with the /xfn directory?

If automount isn't handling /xfn, it will be a regular, empty directory.
Besides file system inconsistencies, it's hard to imagine that it causes
hangs or errors.

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Martin Paul wrote:
> Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> wrote:
>
>>Folks have been saying that /xfn is under the control of automounter...
>>and that I was aware of. But there's nothing at all running
>>automounter-wise.
>
>
> Are you sure? The truss output in you first posting showed:
>
> open64("/xfn", O_RDONLY|O_NDELAY) = 4
> fcntl(4, F_SETFD, 0x00000001) = 0
> fstat64(4, 0xFFBEEF50) = 0
> d=0x04180002 i=7 m=0040555 l=1 u=0 g=0 sz=1
> at = Jun 8 14:17:33 EDT 2005 [ 1118254653 ]
> mt = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
> ct = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
> bsz=8192 blks=1 fs=autofs
>
> See "fs=autofs" in the last line. What does "cd /xfn; df -k ." show?
>
>
>>So... thanks for the suggestions, but they all are related to
>>automount'ing which doesn't apply to me. Has anybody out there who's
>>*not* running automounter ever seen problems with the /xfn directory?
>
>
> If automount isn't handling /xfn, it will be a regular, empty directory.
> Besides file system inconsistencies, it's hard to imagine that it causes
> hangs or errors.
>
> mp.

It is confusing, isn't it? Here's the output you asked for:

> cd /xfn
> df -k .
Filesystem kbytes used avail capacity Mounted on
-xfn 0 0 0 0% /xfn

I do agree that I should see something different than this for the 'df'
output... it should show my root filesystem. So I'm stumped.

-chris

--
Chris Jones
(to email me, just take out the NOSPAM)

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B)
This email address may not be added to any commercial mail list with out
my permission. Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> wrote:
> It is confusing, isn't it? Here's the output you asked for:
>
> > cd /xfn
> > df -k .
> Filesystem kbytes used avail capacity Mounted on
> -xfn 0 0 0 0% /xfn
>
> I do agree that I should see something different than this for the 'df'
> output... it should show my root filesystem. So I'm stumped.

Me too. And `ps -ef | grep auto` really comes up empty? What about
`grep xfn /etc/vfstab` (but fs type in vfstab doesn't take xfn as
an argument, so this can't be the reason anyway). I'm out of ideas.

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Martin Paul wrote:
> Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> wrote:
>
>>It is confusing, isn't it? Here's the output you asked for:
>>
>> > cd /xfn
>> > df -k .
>>Filesystem kbytes used avail capacity Mounted on
>>-xfn 0 0 0 0% /xfn
>>
>>I do agree that I should see something different than this for the 'df'
>>output... it should show my root filesystem. So I'm stumped.
>
>
> Me too. And `ps -ef | grep auto` really comes up empty? What about
> `grep xfn /etc/vfstab` (but fs type in vfstab doesn't take xfn as
> an argument, so this can't be the reason anyway). I'm out of ideas.
>
> mp.

Yup to both. I tell ya, I'm great at finding those "I've never seen
that before!" kinda stuff. Well, at least I have my work around with my
new 'find' syntax.

Thanks for trying though!

-chris

--
Chris Jones
(to email me, just take out the NOSPAM)

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B)
This email address may not be added to any commercial mail list with out
my permission. Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

On Tue, 14 Jun 2005 09:42:43 -0400, Chris Jones
<c.r.jonesNOSPAM@larc.nasa.gov> wrote:

>Martin Paul wrote:
>> Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> wrote:
>>
>>>Folks have been saying that /xfn is under the control of automounter...
>>>and that I was aware of. But there's nothing at all running
>>>automounter-wise.
>>
>>
>> Are you sure? The truss output in you first posting showed:
>>
>> open64("/xfn", O_RDONLY|O_NDELAY) = 4
>> fcntl(4, F_SETFD, 0x00000001) = 0
>> fstat64(4, 0xFFBEEF50) = 0
>> d=0x04180002 i=7 m=0040555 l=1 u=0 g=0 sz=1
>> at = Jun 8 14:17:33 EDT 2005 [ 1118254653 ]
>> mt = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
>> ct = Jan 24 13:31:52 EST 2005 [ 1106591512 ]
>> bsz=8192 blks=1 fs=autofs
>>
>> See "fs=autofs" in the last line. What does "cd /xfn; df -k ." show?
>>
>>
>>>So... thanks for the suggestions, but they all are related to
>>>automount'ing which doesn't apply to me. Has anybody out there who's
>>>*not* running automounter ever seen problems with the /xfn directory?
>>
>>
>> If automount isn't handling /xfn, it will be a regular, empty directory.
>> Besides file system inconsistencies, it's hard to imagine that it causes
>> hangs or errors.
>>
>> mp.
>
>It is confusing, isn't it? Here's the output you asked for:
>
> > cd /xfn
> > df -k .
>Filesystem kbytes used avail capacity Mounted on
>-xfn 0 0 0 0% /xfn
>
>I do agree that I should see something different than this for the 'df'
>output... it should show my root filesystem. So I'm stumped.

An easy way to tell if a directory is mounted by the automounter is if
the size of the directory is "1" as in the following output for the
"net" directory:

dr-xr-xr-x 1 root root 1 May 12 17:56 net

A directory listing after unmounting the directory gives the following
output:

root@ultra5# umount /net
root@ultra5# ls -ld /net
dr-xr-xr-x 2 root root 512 Feb 3 16:45 /net

Josh

Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> writes in comp.sys.sun.admin:
|Martin Paul wrote:
|> Chris Jones <c.r.jonesNOSPAM@larc.nasa.gov> wrote:
|>
|>>It looks like it got to /xfn and just sat there. I could see that
|>>there's something wrong with /xfn, since I can cd there but can't do
|>>anything at all. I'm sure I could reboot the system and this would
|>>clear up... but who's to say it won't happen again?
|>
|>
|> If you don't need /xfn (if you don't know what it does, you most
|> probably don't need it either) I'd disable it. It's not a normal
|> filesystem - the contents of /xfn are generated dynamically by
|> querying various name services.
|>
|> Remove the /xfn entry from /etc/auto_master (and/or from any name service
|> that is mentioned in the "automount:" line in /etc/nsswitch.conf), and run
|> "automount -v". Afterwards, /xfn should be a regular, empty directory.
|>
|> mp.
|
|Ok... first off I was able to get the syntax I needed with the find
|command to *avoid* the /xfn directory, so here's that for anybody that
|might be able to benefit from it:
|
|what didn't work ->
|find / -local -name .rhosts -exec grep '+' {} \;
|
|what does work ->
|find / \( -name xfn -prune \) -o -local -name .rhosts -exec grep '+' {}
|\; -print -o -fstype nfs -prune

find / -fstype ufs -name ... should work as well (unless you've got
MSDOS/pcfs or CDROM/hsfs mounts you want searched, or are part of the
ZFS beta).

--
__________________________________________________ ______________________
Alan Coopersmith * alanc@alum.calberkeley.org * Alan.Coopersmith@Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.