On a machine (sles9) with postfix installed, and a file called sendmail in the /usr/sbin directory, when I do a find as so: rpcweb:/ # find / -name sendmail -ls the results I get are: find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find rpcweb:/ # But, the file is there ... rpcweb:/usr/sbin # ls -l sendmail -rwxr-xr-x 1 root root 122142 Jun 27 2005 sendmail rpcweb:/usr/sbin # why does find not FIND it? as you can see below, this syntax actually finds something when finding 'php' but not when finding 'freetds' or even 'apache' (both things that in fact exist) -- what gives, here? rpcweb:/ # find / -name freetds -ls find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find rpcweb:/ # find / -name php -ls 1015866 4 drwxr-xr-x 8 root root 4096 Feb 27 18:55 /home/httpd/include/php 1000955 4 drwxr-xr-x 14 root root 4096 Feb 9 13:54 /home/httpd/lib/php 999927 6324 -rwxr-xr-x 1 root root 6460639 Feb 27 18:55 /home/httpd/bin/php find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find rpcweb:/ # I am thinking the cause of this has something to do with the files being hidden? Or perhaps sym links, or some such? Or, is my find just broken ... and if so, how do I fix it? Peter
Peter Van Lone wrote:
On a machine (sles9) with postfix installed, and a file called sendmail in the /usr/sbin directory, when I do a find as so:
rpcweb:/ # find / -name sendmail -ls
the results I get are:
find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find rpcweb:/ #
But, the file is there ...
rpcweb:/usr/sbin # ls -l sendmail -rwxr-xr-x 1 root root 122142 Jun 27 2005 sendmail rpcweb:/usr/sbin #
why does find not FIND it?
as you can see below, this syntax actually finds something when finding 'php' but not when finding 'freetds' or even 'apache' (both things that in fact exist) -- what gives, here?
rpcweb:/ # find / -name freetds -ls find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find
rpcweb:/ # find / -name php -ls 1015866 4 drwxr-xr-x 8 root root 4096 Feb 27 18:55 /home/httpd/include/php 1000955 4 drwxr-xr-x 14 root root 4096 Feb 9 13:54 /home/httpd/lib/php 999927 6324 -rwxr-xr-x 1 root root 6460639 Feb 27 18:55 /home/httpd/bin/php find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find rpcweb:/ #
I am thinking the cause of this has something to do with the files being hidden? Or perhaps sym links, or some such?
Or, is my find just broken ... and if so, how do I fix it?
Peter
I had the same problem with 'locate'. Reason why 'locate' was working was that the package findutils wasn't installed. Never had to install findutils in the past but with 10.1........ <sigh> Cheers. -- This computer is environment-friendly and is running on OpenSuSE 10.1
* Basil Chupin <blchupin@tpg.com.au> [08-08-06 21:33]:
I had the same problem with 'locate'. Reason why 'locate' was working was that the package findutils wasn't installed. Never had to install findutils in the past but with 10.1........ <sigh>
well, sigh some more. findutils does not provide locate. It is provided by findutils-locate. And, iirc, it has not been standard since .. 9.0 ?? (ie: required specific selection). -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On 8/8/06, Patrick Shanahan <ptilopteri@gmail.com> wrote:
well, sigh some more. findutils does not provide locate. It is provided by findutils-locate. And, iirc, it has not been standard since .. 9.0 ?? (ie: required specific selection).
any idea why "sendmail" is not found, with the command I issued? Is find broken? Is it fixable? Can I trust the results of future finds that I execute? peter
On Wednesday 09 August 2006 03:11, Peter Van Lone wrote:
On 8/8/06, Patrick Shanahan <ptilopteri@gmail.com> wrote:
well, sigh some more. findutils does not provide locate. It is provided by findutils-locate. And, iirc, it has not been standard since .. 9.0 ?? (ie: required specific selection).
any idea why "sendmail" is not found, with the command I issued? Is find broken? Is it fixable?
Can I trust the results of future finds that I execute?
peter
I tried your "find" and it worked for me (apart from one blip). Have you tried searching for another item in "/usr/sbin" to see if it crashes out at the same point? Maybe there is something wrong with your file system - have you run "fsck" on it? My "find" for sendmail blipped with this error near the end "find: WARNING: Hard link count is wrong for /proc/2690: 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." but carried on. Try the "-noleaf" option with find to see if it makes a difference regards Ian
I HAVE TRIED EVERYTHING I KNOW TO UNSUBSCRIBE FROM THIS LIST BUT NOTHING WORKS. HOW DO I UNSUBSCRIBE? On Wednesday, August 09, 2006, at 04:23PM, ianseeks <ianseeks@dsl.pipex.com> wrote:
On Wednesday 09 August 2006 03:11, Peter Van Lone wrote:
On 8/8/06, Patrick Shanahan <ptilopteri@gmail.com> wrote:
well, sigh some more. findutils does not provide locate. It is provided by findutils-locate. And, iirc, it has not been standard since .. 9.0 ?? (ie: required specific selection).
any idea why "sendmail" is not found, with the command I issued? Is find broken? Is it fixable?
Can I trust the results of future finds that I execute?
peter
I tried your "find" and it worked for me (apart from one blip). Have you tried searching for another item in "/usr/sbin" to see if it crashes out at the same point? Maybe there is something wrong with your file system - have you run "fsck" on it? My "find" for sendmail blipped with this error near the end "find: WARNING: Hard link count is wrong for /proc/2690: 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." but carried on. Try the "-noleaf" option with find to see if it makes a difference
regards
Ian
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Wed, 09 Aug 2006 16:35:51 -0400 James Swanson <reitajim@mac.com> wrote:
I HAVE TRIED EVERYTHING I KNOW TO UNSUBSCRIBE FROM THIS LIST BUT NOTHING WORKS. HOW DO I UNSUBSCRIBE?
There are a couple of alternatives: 1. Have you paid the fee? It's $75 to be paid via paypal. 2. Read the headers -- Thanks http://www.911networks.com
On Aug 9, 2006, at 4:44 PM, suse@911networks.com wrote:
On Wed, 09 Aug 2006 16:35:51 -0400 James Swanson <reitajim@mac.com> wrote:
I HAVE TRIED EVERYTHING I KNOW TO UNSUBSCRIBE FROM THIS LIST BUT NOTHING WORKS. HOW DO I UNSUBSCRIBE?
There are a couple of alternatives: 1. Have you paid the fee? It's $75 to be paid via paypal. 2. Read the headers
-- Thanks http://www.911networks.com
First, #1 is my line! If you are going to use my line at least get it right. It's $75 per person on the list, for each time you send the message to the list. Second, why should anyone have to follow the directions from when they signed up? This is only for this list only... the rest of the world does things differently. Third, writing in all caps helps. it raises the fee from $75 to $100. Have a nice f*cking day! Thanks, George
On Wednesday 09 August 2006 21:35, James Swanson wrote:
I HAVE TRIED EVERYTHING I KNOW TO UNSUBSCRIBE FROM THIS LIST BUT NOTHING WORKS. HOW DO I UNSUBSCRIBE?
pruned ...
Check the headers for your unsubscription address have you done what it says above and checked the headers ..? ie ...
list-unsubscribe: <mailto:suse-linux-e-unsubscribe-reitajim=mac.com> i believe is the line you need ... pete
On Wed, 2006-08-09 at 16:35 -0400, James Swanson wrote:
I HAVE TRIED EVERYTHING I KNOW TO UNSUBSCRIBE FROM THIS LIST BUT NOTHING WORKS. HOW DO I UNSUBSCRIBE?
First off shouting at everyone else on the list won't get you much sympathy. Try sending a _NEW_ email message to the following address: suse-linux-e-unsubscribe-reitajim=mac.com@suse.com Which is in the headers of -every- email you receive from the list server. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
On Wednesday, August 09, 2006, at 04:23PM, ianseeks <ianseeks@dsl.pipex.com> wrote:
On Wednesday 09 August 2006 03:11, Peter Van Lone wrote:
On 8/8/06, Patrick Shanahan <ptilopteri@gmail.com> wrote:
well, sigh some more. findutils does not provide locate. It is provided by findutils-locate. And, iirc, it has not been standard since .. 9.0 ?? (ie: required specific selection).
any idea why "sendmail" is not found, with the command I issued? Is find broken? Is it fixable?
Can I trust the results of future finds that I execute?
peter
I tried your "find" and it worked for me (apart from one blip). Have you tried searching for another item in "/usr/sbin" to see if it crashes out at the same point? Maybe there is something wrong with your file system - have you run "fsck" on it? My "find" for sendmail blipped with this error near the end "find: WARNING: Hard link count is wrong for /proc/2690: 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." but carried on. Try the "-noleaf" option with find to see if it makes a difference
regards
Ian
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Peter, On Tuesday 08 August 2006 18:20, Peter Van Lone wrote:
...
rpcweb:/ # find / -name freetds -ls find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find
On Tuesday 08 August 2006 19:11, Peter Van Lone wrote:
...
any idea why "sendmail" is not found, with the command I issued? Is find broken? Is it fixable?
Those of us who've been around long enough and whose memory is good enough will remember this problem from SuSE Linux ca. 9.?. Eventually it was fixed. Are you up-to-date w.r.t. to fixes and patches for your release? If not, perhaps you'd consider upgrading. Bumps along the way notwithstanding, SuSE Linux progresses rapidly in the space of a year or two and despite the work of a major version upgrade, it's worth it every now and then. If there's no readily available or applicable source for a fixed version of find, what you need to do is avoid running it on /proc, /dev or any auto-mounted file system. If you do that, you should get proper, predictable operation.
Can I trust the results of future finds that I execute?
You can trust most programs to operate deterministically. Well, you could, up until the introduction of HyperThreading, multi-core and multi-processor systems. Now we're open to concurrency bugs that never raised their heads before on uniprocessor systems! Oh, joy!
peter
Randall Schulz
Peter, On Wednesday 09 August 2006 19:59, Randall R Schulz wrote:
Peter,
...
If there's no readily available or applicable source for a fixed version of find, what you need to do is avoid running it on /proc, /dev or any auto-mounted file system. If you do that, you should get proper, predictable operation.
Sorry. Instead of /dev, which is an ordinary directory tree, even if it's one free of plain files, I meant to say /sys, which is another synthetic file system whose contents are invented by the kernel on the fly, as it /proc. When in doubt, run find on a single directory (such as /proc or an auto-mounted file system) and you should (or may sometimes) see the "find: . changed during execution of find" diagnostic.
...
Randall Schulz
Patrick Shanahan wrote:
* Basil Chupin <blchupin@tpg.com.au> [08-08-06 21:33]:
I had the same problem with 'locate'. Reason why 'locate' was working was that the package findutils wasn't installed. Never had to install findutils in the past but with 10.1........ <sigh>
well, sigh some more. findutils does not provide locate. It is provided by findutils-locate. And, iirc, it has not been standard since .. 9.0 ?? (ie: required specific selection).
<sigh>...<sigh>...<sigh>...<sigh>... (is this enough sighing or do I go on for a bit longer?) :-) Well, I do not remember ever having to install findutils-locate and yet was able to use it a short time ago - and then after the reinstall of 10.1 it vanished. Aaaah! Just worked it out! :-) . It is part of the Experienced User selection group of packages which I normally automatically select for installation but this time omitted this group during reinstallation of 10.1. (I knew I wasn't - yet - losing my marbles.) Cheers. -- This computer is environment-friendly and is running on OpenSuSE 10.1
Basil Chupin wrote:
I had the same problem with 'locate'. Reason why 'locate' was working was that the package findutils wasn't installed. Never had to install findutils in the past but with 10.1........ <sigh>
Maybe it's been moved to a different YaST collection? I got it installed by default. /Per Jessen, Zürich
Per Jessen wrote:
Basil Chupin wrote:
I had the same problem with 'locate'. Reason why 'locate' was working was that the package findutils wasn't installed. Never had to install findutils in the past but with 10.1........ <sigh>
Maybe it's been moved to a different YaST collection? I got it installed by default.
See my reply to Patrick. It's part of the packages group called Experienced User which I would normally select and install during a new install but this time, when doing a reinstall, I left this group out and so findutils-locate wasn't installed (and I had to install the rpm separately). 'Find' and 'locate' are both part of this findutils package. Cheers. -- This computer is environment-friendly and is running on OpenSuSE 10.1
On Wednesday 09 August 2006 03:20, Peter Van Lone wrote:
On a machine (sles9) with postfix installed, and a file called sendmail in the /usr/sbin directory, when I do a find as so:
rpcweb:/ # find / -name sendmail -ls
the results I get are:
find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find
This line is your problem. You have some directory being automounted, probably /media/cdrom or something similar, using subfs. find doesn't like this at all. When it enters the automounted directory, the system mounts it, and the contents changes from under find's feet, and it assumes something broke and it stops searching. In your 'php' example, it is in /home, and I suspect the reason it is found is that /home is searched before the automounted directory. If you disable the automounting, find should start working normally again Anders
Peter Van Lone wrote:
On a machine (sles9) with postfix installed, and a file called sendmail in the /usr/sbin directory, when I do a find as so:
rpcweb:/ # find / -name sendmail -ls
the results I get are:
find: /proc/32239/task: No such file or directory find: /proc/32465/task: No such file or directory find: . changed during execution of find rpcweb:/ #
But, the file is there ...
rpcweb:/usr/sbin # ls -l sendmail -rwxr-xr-x 1 root root 122142 Jun 27 2005 sendmail rpcweb:/usr/sbin #
why does find not FIND it?
I think because it stops before it gets that far.
as you can see below, this syntax actually finds something when finding 'php' but not when finding 'freetds' or even 'apache' (both things that in fact exist) -- what gives, here?
Again, I think find is traversing your filesystem in a certain order, so some things will be found, others not before it hits that situation with '. changed during execution of find'. Note that 'php' is alphabetically before 'proc', but 'sendmail' is after. I don't know what the story with 'freetds' is. You're on SLES9 - have you upgraded find recently? My 'find' on 10.1 works fine. It's from findutils-4.2.27-12 /Per Jessen, Zürich
participants (12)
-
Anders Johansson -
Basil Chupin -
ianseeks -
James Swanson -
Ken Schneider -
Patrick Shanahan -
Per Jessen -
Peter Nikolic -
Peter Van Lone -
Randall R Schulz -
suse＠911networks.com -
suse_gasjr4wd＠mac.com