# find: WARNING: Hard link count is wrong for /proc

## nephros

Hi.

Today I encountered an error message the likes of which I have never seen before.

```
[scourge]~ # find / -user <username>

find: WARNING: Hard link count is wrong for /proc: this may be a bug in your filesystem driver.  Automatically turning on find's -noleaf option.  Earlier results may have failed to include directories that should have been searched.

find: /proc/4310/task/4310/fd/4: No such file or directory

find: /proc/4310/fd/4: No such file or directory
```

I understand that this is most likely harmless, /proc being a very special filesystem, but I am still curious what happens here. My theory is that the process with PID 4310 exited (or at least closed fd 4) while find was traversing /proc/4310, causing the kernel to remove that directory, which confused find.

I read the man page entry on -noleaf but it just added to the confusion.

Can anyone shed a light on this?

----------

## cfd

I just got this one for the first time tonight as well.

I recently rebooted.

I get it repeatedly while searching / (root)

I don't get the last two specific 'find' errors, Just:

```
find: WARNING: Hard link count is wrong for /proc: this may be a bug in your filesystem driver.  Automatically turning on find's -noleaf option.  Earlier results may have failed to include directories that should have been searched.
```

----------

## anfpunk

Same thing here with 2.6.11-hardened-r1 on ext3.

I am only getting the first part as well.  Not the no file errors.

----------

## Sandman.173rd.

Encountering same problem on ext3 FS with kernel 2.6.10 aswell as 2.6.11.3 (I tried a newer version in the hope of resolving this issue)

washington ~ # find / -name Search

find: WARNING: Hard link count is wrong for /proc: this may be a bug in your filesystem driver.  Automatically turning on find's -noleaf option.  Earlier results may have failed to include directories that should have been searched.

----------

## zeveck

Encountering same problem with kernel linux-2.6.9-gentoo-r13 and ext3. =(

----------

## nephros

ext3 has nothing to do with it as /proc has a special filesystem not ext3.

Now I did a bit of researching on what a hard link count and a hard link is (namely what is usually called a directory), it's easy to show that find is actually right:

```
[scourge]3345 # /bin/pwd

/proc/3345

[scourge]3345 # ls -la

total 0

dr-xr-xr-x    3 root root 0 Mar 20 22:21 .

dr-xr-xr-x  182 root root 0 Mar 20 14:57 ..

-r--------    1 root root 0 Mar 20 22:21 auxv

-r--r--r--    1 root root 0 Mar 20 22:21 cmdline

lrwxrwxrwx    1 root root 0 Mar 20 22:21 cwd -> /

-r--------    1 root root 0 Mar 20 22:21 environ

lrwxrwxrwx    1 root root 0 Mar 20 22:21 exe -> /usr/sbin/syslogd

dr-x------    2 root root 0 Mar 20 22:21 fd

-r--r--r--    1 root root 0 Mar 20 22:21 maps

-rw-------    1 root root 0 Mar 20 22:21 mem

-r--r--r--    1 root root 0 Mar 20 22:21 mounts

lrwxrwxrwx    1 root root 0 Mar 20 22:21 root -> /

-r--r--r--    1 root root 0 Mar 20 22:21 stat

-r--r--r--    1 root root 0 Mar 20 22:21 statm

-r--r--r--    1 root root 0 Mar 20 22:21 status

dr-xr-xr-x    3 root root 0 Mar 20 22:21 task

-r--r--r--    1 root root 0 Mar 20 22:21 wchan
```

The second field in the ls -l output is the "hard link count", the number of directories in a dir. For /proc/<SOMEPID> dirs, this is always 3, but should be 4 because every such dir has ".", "..", "fd" and "task"

If you copy the <SOMEPID> dir onto a real filesystem, the hard link count shows up correct, 4:

```
[scourge]3345 # cd /var/tmp

[scourge]tmp # cp -a /proc/3345/ .

cp: reading `/proc/3345/task/3345/mem': No such process

cp: reading `/proc/3345/mem': No such process

[scourge]tmp # cd 3345

[scourge]3345 # ls -la

total 37

dr-xr-xr-x   4 root root 408 Mar 20 22:21 .

drwxrwxrwt  17 root root 520 Mar 20 22:30 ..

-r--------   1 root root 144 Mar 20 22:21 auxv

-r--r--r--   1 root root  27 Mar 20 22:21 cmdline

lrwxrwxrwx   1 root root   1 Mar 20 22:30 cwd -> /

-r--------   1 root root 375 Mar 20 22:21 environ

lrwxrwxrwx   1 root root  17 Mar 20 22:30 exe -> /usr/sbin/syslogd

dr-x------   2 root root 576 Mar 20 22:21 fd

-r--r--r--   1 root root 936 Mar 20 22:21 maps

-rw-------   1 root root   0 Mar 20 22:30 mem

-r--r--r--   1 root root 831 Mar 20 22:21 mounts

lrwxrwxrwx   1 root root   1 Mar 20 22:30 root -> /

-r--r--r--   1 root root 187 Mar 20 22:21 stat

-r--r--r--   1 root root  21 Mar 20 22:21 statm

-r--r--r--   1 root root 503 Mar 20 22:21 status

dr-xr-xr-x   3 root root  72 Mar 20 22:21 task

-r--r--r--   1 root root   1 Mar 20 22:21 wchan
```

Strange, strange...

----------

## Sandman.173rd.

https://bugs.gentoo.org/show_bug.cgi?id=86031

still waiting for a reply  :Evil or Very Mad: 

----------

## anfpunk

 *Sandman.173rd. wrote:*   

> https://bugs.gentoo.org/show_bug.cgi?id=86031
> 
> still waiting for a reply :evil:

 

Still nothing on the bug.  :(

----------

## nephros

Patience folks.

Its not like its in anyway critical or something.

It also looks like an upstream problem if it's a problem at all.

----------

## Sandman.173rd.

Seems to be resolved ... but how do I apply the attached patch?

patch -p ????

----------

## Sandman.173rd.

I have applied it by hand  :Mr. Green: 

----------

## racoontje

patch -p0, or other numbers depending on patchlevel

----------

## nephros

Hey a problem I found found its way up to Andrew Morton! Thats nice.

Thanks Sandman.173rd and dsd!

----------

## dsd

yeah- thanks! and you also made me realise another error case: /proc/<PID>/task always has a hardlink count of 3, which is obviously wrong for multithreaded apps which will have more than one child. sent in another patch to andrew.

----------

