find: /proc/xxxx/task: No such file or directory

King4lex · 04-13-2007, 12:51 PM

Hi,

Whenever I use find, the following error is always outputted:

Code:

find: /proc/xxxx/task: No such file or directory
find: /proc/xxxx/fd: No such file or directory

where xxxx is a process id. Sometimes it lists more than two, for example

Code:

find: /proc/xxxx/task: No such file or directory
find: /proc/xxxx/fd: No such file or directory
find: /proc/xxxx/task: No such file or directory
find: /proc/xxxx/fd: No such file or directory
find: /proc/xxxx/task: No such file or directory
find: /proc/xxxx/fd: No such file or directory

and sometimes it just shows two. If I try to cd into the directory, I get

Code:

cd /proc/xxxx/task
bash: cd: /proc/xxxx/task: No such file or directory

What is causing this?

MensaWater · 04-13-2007, 12:59 PM

Does /proc/xxxx itself exist? It may be this is the process for the find itself so of course when you go to ls after the fact it is no longer there.

I don't see this problem when I do "find /proc".

Exactly what are flags/arguments are you giving to find?

King4lex · 04-13-2007, 01:07 PM

Quote:

Originally Posted by jlightner

Does /proc/xxxx itself exist? It may be this is the process for the find itself so of course when you go to ls after the fact it is no longer there.

Yes, it does exist.

Quote:

Exactly what are flags/arguments are you giving to find?

Here's an example:

Code:

[root@dedicated ~]# find / -name "account_info"
/root/account_info
find: /proc/16374/task: No such file or directory
find: /proc/16374/fd: No such file or directory
[root@dedicated ~]#

As you can see, /proc/16374 does exist:

Code:

[root@dedicated ~]# ls /proc/16374/
ls: cannot read symbolic link /proc/16374/cwd: No such file or directory
ls: cannot read symbolic link /proc/16374/root: No such file or directory
ls: cannot read symbolic link /proc/16374/exe: No such file or directory
attr  cmdline  cwd      exe  loginuid  mem     mountstats  oom_score  schedstat  stat   status  wchan
auxv  cpuset   environ  fd   maps      mounts  oom_adj     root       smaps      statm  task
[root@dedicated ~]# ls /proc/16374/fd
ls: /proc/16374/fd: No such file or directory
[root@dedicated ~]#

If I do another find, I get the exact same error, same process id and everything:

Code:

[root@dedicated ~]# find / -name "tsm_conf"
/root/tsm_conf
find: /proc/16374/task: No such file or directory
find: /proc/16374/fd: No such file or directory
[root@dedicated ~]#

MensaWater · 04-13-2007, 01:33 PM

I was able to get something similar:
find / -fstype ext3 >/dev/null
find: /proc/2307/task/2307/fd/4: No such file or directory
find: /proc/2307/fd/4: No such file or directory

However I opened a second window when I started the find and did "ps -ef |grep find" which returned:
root 2307 2101 10 14:20 pts/4 00:00:02 find / -fstype ext3
root 2313 2278 0 14:20 pts/5 00:00:00 grep find

Meaning find was complaining about its own PID (2307). This makes some sense as its state would be changing at the moment it tried to read it.

It is for such system specialized filesystems (/proc, /sys) that I exclude them from things like backups because this kind of error is quite common since they really aren't disk partition filesystems but rather memory structures Linux is showing as if they were filesystems.

King4lex · 04-13-2007, 03:46 PM

Good idea, jlightner. The process id find is giving me is 16374, so I did

Code:

[admin1@dedicated ~]$ ps -ef |grep 16374
root     16374  2075  0 04:05 ?        00:00:00 [perl] <defunct>
admin1   26182 26111  0 15:41 pts/0    00:00:00 grep 16374
[admin1@dedicated ~]$

Any idea what "[perl] <defunct>" is?

MensaWater · 04-14-2007, 07:42 AM

defunct is the same as a zombie process. Defunct/zombie processes are essentially "dead" so can't be killed. They are usually waiting for a signal from their parent process ID. On SOME occasions you can get rid of them by getting rid of the parent. The PPID is 2075 so you can check to see what has PID 2075 for a clue as to what this a child of. You may be able kill 2075 and see the child go away.
(Killing the parent will either make it go away or change its PPID to 1 which is init. If it goes to 1 the only way it would go away is at your next reboot.)

It isn't unusual to see a few defunct processes and they aren't really a problem in and of themselves. If however you saw dozens of such processes (especially if they all had the same PPID other than 1) it might indicate you have something attempting to spawn children that can't run properly.

The fact that you see "perl" in the process suggests some Perl script is the parent.

ps -ef |grep 2075