Bug 162418 - RFE: Improve the warning when user runs find on /proc
RFE: Improve the warning when user runs find on /proc
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
http://forums.fedoraforum.org/showthr...
:
: 150468 164191 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-04 07:52 EDT by Rahul Sundaram
Modified: 2015-01-04 17:20 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-10 16:48:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
this should take care of i_nlink handling for procfs root (1.68 KB, patch)
2005-07-28 07:14 EDT, Alexander Viro
no flags Details | Diff
Workaround as "/usr/local/bin/find", it is not bulletproof. (164 bytes, application/octet-stream)
2006-08-10 15:20 EDT, Jan Kratochvil
no flags Details
Workaround as "/usr/local/bin/find", it is not bulletproof. (164 bytes, application/octet-stream)
2006-08-10 15:23 EDT, Jan Kratochvil
no flags Details
Workaround as "/usr/local/bin/find", it is not bulletproof. (164 bytes, application/octet-stream)
2006-08-10 15:28 EDT, Jan Kratochvil
no flags Details
Workaround as "/usr/local/bin/find", it is not bulletproof. (164 bytes, application/octet-stream)
2006-08-10 15:31 EDT, Jan Kratochvil
no flags Details

  None (edit)
Description Rahul Sundaram 2005-07-04 07:52:27 EDT
Description of problem:

When a user runs find on /proc it provides this "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." which is rather confusing since it
isnt clear whether its a error or warning. 


Expected results:

Should be improve to be less confusing for the end users if its generally safe
to ignore and expected to happen.
Comment 1 Tim Waugh 2005-07-04 07:59:22 EDT
It's quite clear: in fact, it's even in capitals!
Comment 2 Tim Waugh 2005-07-04 08:16:34 EDT
Can we get confirmation from the kernel team about whether this indicates a
kernel bug?  Here is the comment from find.c:

                  /* This is a subdirectory, but the number of directories we
                   * have found now exceeds the number we would expect given
                   * the hard link count on the parent.   This is likely to be
                   * a bug in the filesystem driver (e.g. Linux's
                   * /proc filesystem) or may just be a fact that the OS
                   * doesn't really handle hard links with Unix semantics.
                   * In the latter case, -noleaf should be used routinely.
Comment 3 Moke 2005-07-04 11:46:33 EDT
A statement like:

[root@fc4 /]find / -name something

will also produce the error. FWIW- Adding an option to mask a newly introduce 
error is confusing for all users.
Comment 4 Dave Jones 2005-07-15 17:43:23 EDT
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.
Comment 5 long 2005-07-21 12:57:44 EDT
I think this "bug" still exists in 2.6.12-1.1398_FC4:

[root@griffon 13514]# find /proc -name something
find: WARNING: Hard link count is wrong for /proc/13514: 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.
[root@griffon 13514]# uname -a
Linux griffon.cc.ku.edu 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686
i686 i386 GNU/Linux
Comment 6 Dave Jones 2005-07-28 03:40:47 EDT
*** Bug 164191 has been marked as a duplicate of this bug. ***
Comment 7 Alexander Viro 2005-07-28 07:14:41 EDT
Created attachment 117227 [details]
this should take care of i_nlink handling for procfs root
Comment 8 Alexander Viro 2005-07-28 07:18:59 EDT
At least part of that (wrong link count on procfs root directory) is
due to thinko in proc_root_lookup() - it uses nr_threads to calculate
the number of subdirectories instead of nr_process().  As soon as you
get a process with several threads and do a lookup on /proc/<whatever>
you are getting overestimated link count for /proc.

BTW, lookup is not a good place to recalculate the i_nlink of parent -
we have much simpler way to do it these days - ->getattr().  Patch in
the attachment above should take care of that; whether we have other
directories in procfs with miscalculated i_nlink remains to be seen.
Comment 9 Dave Jones 2005-07-28 15:46:07 EDT
Lovely, we have the same issue with sysfs too..

(15:44:52:davej@nwo:~)$ find /sys/ > /dev/null
find: WARNING: Hard link count is wrong for /sys/devices: 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.
Comment 10 Dave Jones 2005-08-03 18:17:29 EDT
fixed in cvs.
Comment 11 Dave Jones 2005-08-31 10:48:48 EDT
seems even with the above fix, something still isn't right.

find /proc/sys spews..

....
./kernel/ostype
find: WARNING: Hard link count is wrong for .: 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.
./fs
.....
Comment 12 Dave Jones 2005-08-31 19:15:43 EDT
*** Bug 150468 has been marked as a duplicate of this bug. ***
Comment 13 Jeff Bambrough 2005-09-24 09:41:22 EDT
Still exists in 2.6.12-1.1456_FC4smp
Comment 14 Dave Jones 2005-09-30 03:15:27 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 15 long 2005-10-04 11:32:38 EDT
Still seems to appear in 2.6.13-1.1526_FC4smp:


find: WARNING: Hard link count is wrong for /proc/11495: 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.
Comment 16 James W. Spring 2005-11-01 10:04:53 EST
Still seems to appear in 2.6.13-1.1532_FC4
Comment 17 Dave Jones 2005-11-10 15:24:09 EST
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.
Comment 18 John Ellson 2005-11-10 15:41:12 EST
No more warnings seen on Rawhide with kernel-2.6.14-1.1657_FC5 on i686 or x86_64

root@froth:~# uname -a
Linux froth 2.6.14-1.1657_FC5 #1 Wed Nov 9 16:59:05 EST 2005 i686 i686 i386
GNU/Linux
root@froth:~# find /proc -name something

root@ontap:~# uname -a
Linux ontap.ellson.com 2.6.14-1.1657_FC5 #1 SMP Wed Nov 9 16:58:41 EST 2005
x86_64 x86_64 x86_64 GNU/Linux
root@ontap:~# find /proc -name something

Comment 19 Andrew Zitnay 2005-11-11 08:15:40 EST
Fixed for me on 2.6.14-1.1637_FC4smp.

Drew
Comment 20 Quint van Drosthagen 2005-12-22 11:10:42 EST
It is back/not fixed in kernel 2.6.14-1.1653_FC4smp
Comment 21 David Tonhofer 2006-03-22 15:19:02 EST
Seems to be ok for /proc in 2.6.15-1.2054_FC5 ... but not fro /selinux (grin)

find: WARNING: Hard link count is wrong for /selinux: 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.
Comment 22 Richard Halon 2006-05-14 01:23:55 EDT
I get the bug on a fresh Fedora FC4 install.

root@px-012 [~]# uname -a
Linux px-012.chicago.serverchange.com 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56
EDT 2005 i686 i686 i386 GNU/Linux

root@px-012 [~]# find --version
GNU find version 4.2.20
Features enabled: D_TYPE O_NOFOLLOW(enabled)

root@px-012 [~]# find / -type f -size +26000k -exec ls -lh {} \; | awk '{ print
$8 ": " $5 }' >> ~/big_files.txt
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.

Tried doing a kernel update with yum but it's saying no updates exist. What's
the deal here, kernel bug or find bug and how do I go about fixing it?

Thanks.
Comment 23 Rahul Sundaram 2006-05-14 13:26:44 EDT
(In reply to comment #22)
> I get the bug on a fresh Fedora FC4 install.
> 

Update to the latest kernel. Kindly avoid commenting on closed bug reports. If
you still find the problem with the latest kernel, file a separate bug report
referencing this one. 
Comment 24 Kiran Annaiah 2006-08-10 14:48:56 EDT
Hello there,

I am running Redhat Enterprise Linux:

$uname -a
Linux ccapps 2.6.9-34.0.2.ELsmp #1 SMP Fri Jun 30 10:32:04 EDT 2006 x86_64
x86_64 x86_64 GNU/Linux

I get the find command warning as well. From reading the entries here, seems
like there isnt a fix yet?
Any more developments since the last post here in fixing this?


Basically One of my applications could not execute the "find" command and quit
with the following message:

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


----------
When i run the  find command independently, it gives me the warning but goes on
to complete the task.


please do suggest any solution..if there is one.

thank you
Comment 25 Kiran Annaiah 2006-08-10 14:51:06 EDT
Hello there,

I am running Redhat Enterprise Linux:

$uname -a
Linux ccapps 2.6.9-34.0.2.ELsmp #1 SMP Fri Jun 30 10:32:04 EDT 2006 x86_64
x86_64 x86_64 GNU/Linux

I get the find command warning as well. From reading the entries here, seems
like there isnt a fix yet?
Any more developments since the last post here in fixing this?


Basically One of my applications could not execute the "find" command and quit
with the following message:

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


----------
When i run the  find command independently, it gives me the warning but goes on
to complete the task.


please do suggest any solution..if there is one.

thank you
Comment 29 Jan Kratochvil 2006-08-10 15:31:07 EDT
Created attachment 133976 [details]
Workaround as "/usr/local/bin/find", it is not bulletproof.

As a temporary workaround you may store this script as your:
/usr/local/bin/find
Rather also type afterwards (to use the right one): hash -r
If some application uses directly "/usr/bin/find", wrap your binary
appropriately ("mv /usr/bin/find /usr/bin/find" and edit this wrapper placed as
"/usr/bin/find" to reference "/usr/bin/find-orig" instead).

If you would like a priority hotfix for RHEL, please file a new Issue Tracker
request instead.
Comment 30 chenbaolin 2006-11-24 21:24:33 EST
Linux localhost.localdomain 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005
i686 athlon i386 GNU/Linux

i have this problem.

[root@localhost local]# find / -name mod_dav_svn.so
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.
/usr/lib/httpd/modules/mod_dav_svn.so

Note You need to log in before you can comment on or make changes to this bug.