LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 07-19-2016, 03:52 PM   #1
naikin
Member
 
Registered: Jun 2015
Posts: 41

Rep: Reputation: Disabled
find: WARNING: Hard link count is wrong for `/proc/fs'


I am trying to use find but whenever I include the root partition in the search I am getting an error:
Quote:
find: WARNING: Hard link count is wrong for `/proc/fs' (saw only st_nlink=8 but we already saw 6 subdirectories): this may be a bug in your file system driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.
From my search I found that my filesystem might be corrupt so I ran fsck on my root, home and efi partitions (made sure they are unmounted and I use proper partition type). fsck said that they are all fine.

Here is the relevant output from
Quote:
fdisk -l
Quote:
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 206847 204800 100M EFI System
/dev/nvme0n1p2 206848 210943 4096 2M BIOS boot
/dev/nvme0n1p3 210944 50542591 50331648 24G Linux swap
/dev/nvme0n1p4 50542592 239286271 188743680 90G Linux filesystem
/dev/nvme0n1p5 239286272 1000215182 760928911 362.9G Linux filesystem
I am normally using UEFI mode to boot. I only made the bios boot partition in case I need to boot in legacy mode. Can this partition be related to the problem?

Here is also the output from
Quote:
mount | column -t
Quote:
/dev/nvme0n1p4 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/nvme0n1p5 on /home type ext4 (rw)
/dev/nvme0n1p1 on /boot/efi type vfat (rw)
gvfsd-fuse on /home/niko/.gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=niko)
I should also mention that the first time I ran found it also said
Quote:
find: `/proc/3002': No such file or directory
. Subsequent executions of find did not report this. I checked after that and this entry does not exist in /proc:

Quote:
niko@dell-xps15: ~ $ ls /proc
1/ 1185/ 1236/ 1327/ 1424/ 1512/ 1562/ 158/ 1692/ 1760/ 185/ 1949/ 2034/ 214/ 23/ 264/ 3/ 3532/ 41/ 596/ 72/ 78/ 84/ 902/ devices kallsyms misc softirqs vmstat
10/ 1187/ 1237/ 1328/ 1439/ 1534/ 1563/ 1584/ 17/ 177/ 186/ 1950/ 205/ 215/ 2307/ 265/ 30/ 3590/ 42/ 624/ 727/ 79/ 840/ 906/ diskstats kcore modules stat zoneinfo
1085/ 1189/ 1253/ 1330/ 1443/ 1536/ 1564/ 1585/ 170/ 1774/ 187/ 1953/ 2056/ 216/ 2317/ 266/ 3048/ 3617/ 43/ 626/ 728/ 8/ 841/ acpi/ dma key-users mounts@ swaps
1087/ 1195/ 1269/ 1332/ 1446/ 1537/ 1565/ 1586/ 1710/ 178/ 188/ 196/ 2058/ 2161/ 2354/ 267/ 3098/ 3673/ 44/ 633/ 73/ 80/ 842/ asound/ driver/ keys mpt/ sys/
11/ 1196/ 1270/ 1335/ 1449/ 154/ 1567/ 1594/ 1711/ 179/ 189/ 197/ 206/ 2163/ 238/ 268/ 31/ 37/ 45/ 634/ 735/ 81/ 85/ buddyinfo execdomains kmsg mtrr sysrq-trigger
1113/ 1201/ 1278/ 1352/ 1451/ 1541/ 1568/ 16/ 172/ 18/ 19/ 198/ 2062/ 217/ 2403/ 269/ 32/ 38/ 46/ 657/ 736/ 82/ 852/ bus/ fb kpagecgroup net@ sysvipc/
1128/ 1211/ 1279/ 1392/ 1455/ 155/ 1569/ 160/ 1727/ 180/ 190/ 2/ 2068/ 218/ 247/ 27/ 3208/ 3844/ 47/ 676/ 737/ 820/ 853/ cgroups filesystems kpagecount pagetypeinfo thread-self@
1136/ 1216/ 1283/ 14/ 1468/ 1551/ 1573/ 162/ 1732/ 181/ 191/ 200/ 208/ 219/ 248/ 270/ 3238/ 3865/ 48/ 677/ 739/ 824/ 86/ cmdline fs/ kpageflags partitions timer_list
1138/ 1232/ 13/ 1416/ 1499/ 1557/ 1575/ 164/ 174/ 1816/ 192/ 2000/ 209/ 22/ 25/ 271/ 33/ 39/ 49/ 680/ 74/ 826/ 866/ config.gz interrupts loadavg sched_debug tty/
1149/ 1233/ 1318/ 1417/ 15/ 1559/ 1576/ 166/ 1747/ 182/ 193/ 2005/ 21/ 2220/ 250/ 2728/ 3357/ 3946/ 5/ 686/ 75/ 83/ 87/ consoles iomem locks scsi/ uptime
1159/ 1234/ 1319/ 1420/ 1501/ 1560/ 1578/ 167/ 175/ 183/ 194/ 201/ 210/ 2251/ 251/ 2839/ 34/ 4/ 51/ 7/ 76/ 838/ 88/ cpuinfo ioports mdstat self@ version
1165/ 1235/ 1326/ 1421/ 1509/ 1561/ 1579/ 169/ 176/ 184/ 1945/ 202/ 211/ 2296/ 26/ 29/ 35/ 40/ 52/ 71/ 77/ 839/ 9/ crypto irq/ meminfo slabinfo vmallocinfo
Any idea how to fix this. It is driving me crazy because I cannot use find at all. I am running Slackware 14.2.
 
Old 07-19-2016, 04:42 PM   #2
hydrurga
LQ Guru
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 20 MATE
Posts: 8,048
Blog Entries: 5

Rep: Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917
According to this link: http://linux.derkeiler.com/Mailing-L...5-06/2818.html

Quote:
The problem with the link count in /proc is that it changes every time a
process is created or terminates, so the number of directories that
'find' sees during processing might not agree with the link count that
it read at the start. I admit that doesn't seem terribly likely unless
the system is quite busy, but it can certainly happen.

I almost always use the "-xdev" option to prevent 'find' from descending
into file systems other than the ones I explicitly specified, e.g.,

find -xdev / /usr /var ...
 
Old 07-19-2016, 05:27 PM   #3
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,140
Blog Entries: 4

Rep: Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227
The /proc and /sys directories are not actually files at all: they are kernel APIs.

If you think that they are somehow providing incorrect characteristics, such that some utility finds their numbers alarning, you should probably report that to the kernel developers as a possible bug.

But otherwise, you should exclude these directories from searching or consideration. They do not exist, and you're causing unnecessary overhead (so to speak) by including them.

Last edited by sundialsvcs; 07-19-2016 at 05:28 PM.
 
2 members found this post helpful.
Old 07-19-2016, 05:46 PM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,907

Rep: Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510
They are not errors.

/proc normally should not be searched with find. Specifically, the process ids come/go and if find is searching the contents of a /proc/<pid> directory you get the same errors you get if you delete a directory tree find is searching elsewhere.

I do use find on /proc - but usually because I am looking for something else (not the pid files), so I ignore any <pid> reported errors.
 
1 members found this post helpful.
Old 07-19-2016, 06:29 PM   #5
naikin
Member
 
Registered: Jun 2015
Posts: 41

Original Poster
Rep: Reputation: Disabled
Thanks, I did not know that, when I was using the same kernel on old machine I did not have this problem. Is there a way to make find exclude pids automatically, e.g. when I want to search the /proc directory. Is there a conf file that I can use to exclude directories or the best solution would be to use an alias.
 
Old 07-19-2016, 06:40 PM   #6
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,702

Rep: Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548
Not that I am aware of.
Rethink your workflow - if you need to process /proc, specify the pid directly - you can use "pidof" or "pgrep" for that.
If you are merely looking for say if something generic exists, /proc/self will always be there to run against. Makes a good testbench.
 
Old 10-05-2016, 04:00 PM   #7
BW-userx
LQ Guru
 
Registered: Sep 2013
Location: Somewhere in my head.
Distribution: Slackware (current), FreeBSD, Win10, It varies
Posts: 9,952

Rep: Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148
Quote:
Originally Posted by jpollard View Post
They are not errors.

/proc normally should not be searched with find. Specifically, the process ids come/go and if find is searching the contents of a /proc/<pid> directory you get the same errors you get if you delete a directory tree find is searching elsewhere.

I do use find on /proc - but usually because I am looking for something else (not the pid files), so I ignore any <pid> reported errors.
rye

Bouncing in on this as someone lead me here because I just posted about the same thing. and within here during the last part of the posting prior to this one (mine) people are saying well you shouldn't be using find on /proc

well I have used
Code:
find / -name whatever
and find does what it does and I have never seen this warning before ever never! in all of the other distros I've ever used, even back before Slackware 14.2 as I have had Slackware 14.1 installed before and I am really sure I've issued a find / -name whatever before on Slackware 14.1 , and never have I ever seen this warning before. so I think something is a awry here.

Last edited by BW-userx; 10-05-2016 at 04:02 PM.
 
Old 10-05-2016, 05:23 PM   #8
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,907

Rep: Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510
Quote:
Originally Posted by BW-userx View Post
rye

Bouncing in on this as someone lead me here because I just posted about the same thing. and within here during the last part of the posting prior to this one (mine) people are saying well you shouldn't be using find on /proc

well I have used
Code:
find / -name whatever
and find does what it does and I have never seen this warning before ever never! in all of the other distros I've ever used, even back before Slackware 14.2 as I have had Slackware 14.1 installed before and I am really sure I've issued a find / -name whatever before on Slackware 14.1 , and never have I ever seen this warning before. so I think something is a awry here.
Well. What happens is that you are very likely to get errors due to entire directories being removed when the process exits (and gets reaped). This can leave find working in a directory that suddenly doesn't exist.

This situation CAN happen in regular filesystems - but is MUCH less likely as the contents of a directory must be deleted before the directory itself - which gives the find utility a better chance of recovery. With /proc entries, they disappear within the same cycle as what is being removed is done within a lock. Find does not work with the kernel locks... so it isn't protected.

You can use find on /proc if you want, it isn't forbidden. But you have to understand what can happen, and know that the errors that get reported may be bogus, and that there can be a LOT of errors reported (the more active the system, the more errors there will be).
 
Old 10-05-2016, 05:26 PM   #9
BW-userx
LQ Guru
 
Registered: Sep 2013
Location: Somewhere in my head.
Distribution: Slackware (current), FreeBSD, Win10, It varies
Posts: 9,952

Rep: Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148
Quote:
Originally Posted by jpollard View Post
Well. What happens is that you are very likely to get errors due to entire directories being removed when the process exits (and gets reaped). This can leave find working in a directory that suddenly doesn't exist.

This situation CAN happen in regular filesystems - but is MUCH less likely as the contents of a directory must be deleted before the directory itself - which gives the find utility a better chance of recovery. With /proc entries, they disappear within the same cycle as what is being removed is done within a lock. Find does not work with the kernel locks... so it isn't protected.

You can use find on /proc if you want, it isn't forbidden. But you have to understand what can happen, and know that the errors that get reported may be bogus, and that there can be a LOT of errors reported (the more active the system, the more errors there will be).
it is strange I've never encountered this before in all of my years of using find / on any other system before until now with Slackware 14.2

and I am not personally doing anything with the system but using find and waiting for results.
 
Old 10-05-2016, 05:45 PM   #10
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,907

Rep: Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510Reputation: 1510
Quote:
Originally Posted by BW-userx View Post
it is strange I've never encountered this before in all of my years of using find / on any other system before until now with Slackware 14.2
It doesn't happen very often on single user workstations. But if you work on large, active servers, you get the errors because users will create/delete directories at will - and if find is working within such a directory and it gets deleted, you get errors.

Quote:

and I am not personally doing anything with the system but using find and waiting for results.
If you are searching /proc, expect errors when processes are reaped.
 
Old 10-05-2016, 07:16 PM   #11
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,140
Blog Entries: 4

Rep: Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227
There are certain specific "directories" in any Linux system ... /proc, /sys, and perhaps nowadays /dev, which should be "excluded from consideration" because they are not "real."

In the first two cases, these directories literally "don't actually exist." They are, in fact, an API into the operating system itself, presented "as a directory" for the convenience of shell-scripts and other programs. In the third case, you're basically looking at the operating system's physical-device table, once again presented as "a directory."

You should therefore ignore any "error messages" if they happen to involve these directories, and, generally speaking, you should not attempt to find anything-at-all in them.
 
Old 10-05-2016, 08:59 PM   #12
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,547

Rep: Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082
Quote:
Originally Posted by jpollard View Post
Well. What happens is that you are very likely to get errors due to entire directories being removed when the process exits (and gets reaped). This can leave find working in a directory that suddenly doesn't exist.
That scenario is true for /proc itself, but the specific error here is about /proc/fs, and the content of that directory should change only when a filesystem driver is loaded or unloaded. That is not a very frequent occurrence.

What does "ls -la /proc/fs" show?
 
Old 10-06-2016, 12:06 AM   #13
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2 and Slackware64 -current (AKA Slackware64 15)
Posts: 3,769

Rep: Reputation: 2127Reputation: 2127Reputation: 2127Reputation: 2127Reputation: 2127Reputation: 2127Reputation: 2127Reputation: 2127Reputation: 2127Reputation: 2127Reputation: 2127
BW-userx came from here.


I ran his command
Code:
sudo find / -iname dropbox
on my box and got a similar error.
Code:
find: WARNING: Hard link count is wrong for `/proc/fs' (saw only st_nlink=7 but we already saw 5 subdirectories): this may be a bug in your file system driver.  Automatically turning on find's -noleaf option.  Earlier results may have failed to include directories that should have been searched.
As for your question...
Code:
$ ls -la /proc/fs
total 0
dr-xr-xr-x   7 root root 0 Oct  6 00:05 ./
dr-xr-xr-x 498 root root 0 Oct  3 18:51 ../
dr-xr-xr-x   7 root root 0 Oct  6 00:05 ext4/
dr-xr-xr-x   7 root root 0 Oct  6 00:05 jbd2/
dr-xr-xr-x   2 root root 0 Oct  6 00:05 lockd/
dr-xr-xr-x   2 root root 0 Oct  6 00:05 nfsd/
dr-xr-xr-x   2 root root 0 Oct  6 00:05 nfsfs/
dr-xr-xr-x   2 root root 0 Oct  6 00:05 xfs/
 
Old 10-06-2016, 09:03 AM   #14
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,547

Rep: Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082Reputation: 2082
Quote:
Originally Posted by Richard Cranium View Post
As for your question...
Code:
$ ls -la /proc/fs
total 0
dr-xr-xr-x   7 root root 0 Oct  6 00:05 ./
dr-xr-xr-x 498 root root 0 Oct  3 18:51 ../
dr-xr-xr-x   7 root root 0 Oct  6 00:05 ext4/
dr-xr-xr-x   7 root root 0 Oct  6 00:05 jbd2/
dr-xr-xr-x   2 root root 0 Oct  6 00:05 lockd/
dr-xr-xr-x   2 root root 0 Oct  6 00:05 nfsd/
dr-xr-xr-x   2 root root 0 Oct  6 00:05 nfsfs/
dr-xr-xr-x   2 root root 0 Oct  6 00:05 xfs/
That is indeed showing the inconsistency. With the 6 subdirectories shown, the link count for "." should be 8, not 7. It's not really a big deal. The "proc" filesystem tries to look like a regular filesystem, but it isn't one, and sometimes the emulation breaks down. I just looked in Fedora 23 (I don't have a Slackware installation handy), and a similar thing happens there -- 5 subdirectories, link count is 6, not 7. But, the find command there does not complain. Perhaps that command has a built-in exception for the "proc" filesystem type.
 
Old 10-06-2016, 09:05 AM   #15
BW-userx
LQ Guru
 
Registered: Sep 2013
Location: Somewhere in my head.
Distribution: Slackware (current), FreeBSD, Win10, It varies
Posts: 9,952

Rep: Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148
Quote:
Originally Posted by rknichols View Post
That is indeed showing the inconsistency. With the 6 subdirectories shown, the link count for "." should be 8, not 7. It's not really a big deal. The "proc" filesystem tries to look like a regular filesystem, but it isn't one, and sometimes the emulation breaks down. I just looked in Fedora 23 (I don't have a Slackware installation handy), and a similar thing happens there -- 5 subdirectories, link count is 6, not 7. But, the find command there does not complain. Perhaps that command has a built-in exception for the "proc" filesystem type.
Exactly that's what I'm talking bout' cuz as I have said I've never seen that warning before ever until this install of Slackware 14.2 ...
 
  


Reply

Tags
filesystem, find command, proc


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
find: WARNING: Hard link count is wrong.... andrew.46 Slackware 2 11-13-2015 08:16 PM
Hard link count is wrong dwarf007 Linux - General 1 09-30-2008 01:34 PM
find: WARNING: Hard link count is wrong for /proc/1: Ramonvel Slackware 2 05-27-2008 10:28 PM
Error when using 'find' -- "WARNING: Hard link count is wrong..." xGreenmanx Linux - Software 6 03-11-2006 06:35 PM
WARNING: Hard link count is wrong for /proc Fr33B5D Linux - General 1 08-30-2005 06:41 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 02:17 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration