FIND

Post fully complete "how to" guides and tutorials here. This is a great place to get feedback on stuff you might put in the wiki.

Moderators: MattKingUSA, khz

Thad E Ginathom
Established Member
Posts: 369
Joined: Fri Sep 23, 2011 1:03 pm

Re: FIND

Post by Thad E Ginathom »

raboof wrote: Check who started it with 'ps faux | less'.

Perhaps part of the 'updatedb' process for the 'locate' database?
raboof's idea will help you home in on it, because you will see the arguments. Again ps is complex because of its power, and supporting two [or more?] sets of args (I prefer the one with the -s), but skim the man page to get started.

The full list of processes is daunting. It's a bit shocking that the system appears to be doing so much all the time! Help to get what you wanted in your sights:

Code: Select all

$ ps faux | grep find
User avatar
briandc
Established Member
Posts: 1442
Joined: Sun Apr 29, 2012 3:17 pm
Location: Italy
Has thanked: 58 times
Been thanked: 28 times
Contact:

Re: FIND

Post by briandc »

Thad E Ginathom wrote:
raboof wrote: Check who started it with 'ps faux | less'.

Perhaps part of the 'updatedb' process for the 'locate' database?
raboof's idea will help you home in on it, because you will see the arguments. Again ps is complex because of its power, and supporting two [or more?] sets of args (I prefer the one with the -s), but skim the man page to get started.

The full list of processes is daunting. It's a bit shocking that the system appears to be doing so much all the time! Help to get what you wanted in your sights:

Code: Select all

$ ps faux | grep find
Ok. I can't make neither heads nor tails of it, but here's the result of "ps faux | grep find":

Code: Select all

root      2350  0.0  0.0   2236   548 ?        SN   16:04   0:00              \_ /bin/sh /usr/bin/updatedb.findutils
root      2358  0.0  0.0   2236   304 ?        SN   16:04   0:00                  \_ /bin/sh /usr/bin/updatedb.findutils
nobody    2384  0.0  0.0   3768  1540 ?        SN   16:04   0:00                  |   \_ su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race      \( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o      -type d -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\)' \) -prune -o -print0
nobody    2397  0.0  0.0   2236   540 ?        SN   16:04   0:00                  |       \_ sh -c /usr/bin/find / -ignore_readdir_race      \( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o      -type d -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\)' \) -prune -o -print0
nobody    2398 15.7  0.0   4788  1344 ?        DN   16:04   0:02                  |           \_ /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex \(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\) ) -prune -o -print0
brian     2406  0.0  0.0   4388   832 pts/1    S+   16:04   0:00      \_ grep --color=auto find
This last one, "nobody" with PIN 2398, is the one that's in question. Any thoughts?


brian
Have your PC your way: use linux!
My sound synthesis biome: http://www.linuxsynths.com
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: FIND

Post by raboof »

briandc wrote:
Thad E Ginathom wrote:
raboof wrote: Check who started it with 'ps faux | less'.

Perhaps part of the 'updatedb' process for the 'locate' database?
raboof's idea will help you home in on it
Ok. I can't make neither heads nor tails of it, but here's the result of "ps faux | grep find":

Code: Select all

root      2350  0.0  0.0   2236   548 ?        SN   16:04   0:00              \_ /bin/sh /usr/bin/updatedb.findutils
root      2358  0.0  0.0   2236   304 ?        SN   16:04   0:00                  \_ /bin/sh /usr/bin/updatedb.findutils
nobody    2384  0.0  0.0   3768  1540 ?        SN   16:04   0:00                  |   \_ su nobody -s /bin/sh -c /usr/bin/find (....)
So this tells you '/usr/bin/updatedb.findutils' invoked 'find'. This is (as I suspected above) the process that updated the cache that 'locate' uses in order to be so fast.

You could look into the locate/updatedb documentation to perhaps tweak it to run less often, but that'd make 'locate' less useful.
User avatar
briandc
Established Member
Posts: 1442
Joined: Sun Apr 29, 2012 3:17 pm
Location: Italy
Has thanked: 58 times
Been thanked: 28 times
Contact:

Re: FIND

Post by briandc »

raboof wrote:

Code: Select all

root      2350  0.0  0.0   2236   548 ?        SN   16:04   0:00              \_ /bin/sh /usr/bin/updatedb.findutils
root      2358  0.0  0.0   2236   304 ?        SN   16:04   0:00                  \_ /bin/sh /usr/bin/updatedb.findutils
nobody    2384  0.0  0.0   3768  1540 ?        SN   16:04   0:00                  |   \_ su nobody -s /bin/sh -c /usr/bin/find (....)
So this tells you '/usr/bin/updatedb.findutils' invoked 'find'. This is (as I suspected above) the process that updated the cache that 'locate' uses in order to be so fast.

You could look into the locate/updatedb documentation to perhaps tweak it to run less often, but that'd make 'locate' less useful.[/quote]

Ok, I'll check the locate and updatedb docs and see what I can find. I don't remember ever activating this feature though.. is it a default with Ubuntu Studio? If so, then I suppose that everyone who installs this distro has the same experience..


brian
Have your PC your way: use linux!
My sound synthesis biome: http://www.linuxsynths.com
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: FIND

Post by raboof »

briandc wrote:I don't remember ever activating this feature though.. is it a default with Ubuntu Studio?
The 'locate' utility is default with pretty much any Linux distro - not sure it should have such a huge impact though.
SR
Established Member
Posts: 218
Joined: Wed May 07, 2008 6:01 pm
Location: Houston, Tx

Re: FIND

Post by SR »

In Fedora I believe it's started from anacron in cron.daily. So basically that means if your machine is on all the time it would probably run at 4am daily. If you only power your machine up when you use it then updatedb would probably run soon afterward. I don't use Ubuntu, but if it starts from anacron you could probably move it to cron.weekly or disable it entirely if you never use the locate command.
DepreTux
Established Member
Posts: 135
Joined: Tue Jul 23, 2013 9:36 am

Re: FIND

Post by DepreTux »

You can disable cron and anacron using rcconf.
And you can kill find with "sudo killall -9 find".

Good luck!
SR
Established Member
Posts: 218
Joined: Wed May 07, 2008 6:01 pm
Location: Houston, Tx

Re: FIND

Post by SR »

DepreTux wrote:You can disable cron and anacron using rcconf.
Probably not advisable since you'd also be disabling prelink and various other scheduled housekeeping processes.
User avatar
briandc
Established Member
Posts: 1442
Joined: Sun Apr 29, 2012 3:17 pm
Location: Italy
Has thanked: 58 times
Been thanked: 28 times
Contact:

Re: FIND

Post by briandc »

DepreTux wrote: And you can kill find with "sudo killall -9 find".

Good luck!
This would probably do the trick, although if I find the actual setting where find is called at every power-on, it'd be better. But it's handy to have the "killall -9" command, for "emergencies." :) Besides, the kill pid command in Top wasn't stopping the process. (maybe because I wasn't root? or because the process was run by "nobody," maybe I had to change user to nobody..?)

brian
Have your PC your way: use linux!
My sound synthesis biome: http://www.linuxsynths.com
SR
Established Member
Posts: 218
Joined: Wed May 07, 2008 6:01 pm
Location: Houston, Tx

Re: FIND

Post by SR »

briandc wrote:This would probably do the trick, although if I find the actual setting where find is called at every power-on
Do you have something like /etc/cron.daily/mlocate?
Thad E Ginathom
Established Member
Posts: 369
Joined: Fri Sep 23, 2011 1:03 pm

Re: FIND

Post by Thad E Ginathom »

DepreTux wrote:You can disable cron and anacron using rcconf.
Better not... without a good understanding of what they do.

A slightly better alternative is to go through all the crontab files (are they still called that?) and take out the things that you don't want to happen. Still, an experienced administrator would do this only with great care. Linux is configurable: that does not mean it is good to abuse it!
And you can kill find with "sudo killall -9 find".

Good luck!
The jobs that you might leave half done could be more trouble.

All this sort of advice I greet with an EEEK! It is not what we know that counts, it is what we do not know.

But hey, I did not choose my Unix career, I had it thrust upon me, and I did my learning on a live, commercial system, which was, at times, deeply embarrassing! :oops: There is nothing like having 40 people waiting for you to find and fix your mistake!

Just one thing: before changing any system file, make a copy of it, and always make sure that you have the original copy by using a naming convention like copy.0, copy.1, copy.2 etc. It's essential to be able to go back to square one, but it is nice to be able to back up step by step too.

And one more thing: have a back of of your root file system, separate to any data. It is sooo much easier than having to do a reinstall followed by all the tweaks and changes some of which one can't even remember!
DepreTux
Established Member
Posts: 135
Joined: Tue Jul 23, 2013 9:36 am

Re: FIND

Post by DepreTux »

It certainly is what we do not know that counts. Still, how does an audio setup harm from killing find? Also, what specific needs do you have for cron on your audio system?

You might be in the middle of a mix and happen to have forgotten the daemon is running and all of the sudden face the problem that motivated this thread.

I should have said the advice I gave is my practice on my systems for the past 3 years or so. It may not be the standard UNIX practice though.
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: FIND

Post by raboof »

DepreTux wrote:Still, how does an audio setup harm from killing find?
Removing 'find' itself? That'll possibly break all kinds of software, including audio tools.

Removing updating the locatedb from cron? well, you won't be able to use 'locate' anymore - might not be a huge deal.

Removing cron entirely? That *could* prevent useful housekeeping from being done. I'm not sure what I find more risky: the risk of a cronjob suddenly kicking in, or the risk of a useful cronjob never running. (it'd be nice to be able to 'suspend' cronjobs and have them run after you finish e.g. your recording session or low-on-battery-commute :) )
DepreTux wrote:You might be in the middle of a mix and happen to have forgotten the daemon is running and all of the sudden face the problem that motivated this thread.
I'm not sure we're overstating the "problem" here: find traversing your disk and causing some CPU and I/O usage shouldn't interfere with realtime work on any properly configured system, right?
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: FIND

Post by raboof »

raboof wrote:it'd be nice to be able to 'suspend' cronjobs and have them run after you finish e.g. your recording session or low-on-battery-commute :)
... and of course you can: '/etc/init.d/cron stop' '/etc/init.d/cron start'
DepreTux
Established Member
Posts: 135
Joined: Tue Jul 23, 2013 9:36 am

Re: FIND

Post by DepreTux »

raboof wrote:
DepreTux wrote:Still, how does an audio setup harm from killing find?
Removing 'find' itself? That'll possibly break all kinds of software, including audio tools.
kill != remove
raboof wrote:Removing updating the locatedb from cron? well, you won't be able to use 'locate' anymore - might not be a huge deal.
You don't need to remove it, just disable it at startup with rcconf or whatever your distro provides for the task.
raboof wrote: Removing cron entirely? That *could* prevent useful housekeeping from being done. I'm not sure what I find more risky: the risk of a cronjob suddenly kicking in, or the risk of a useful cronjob never running. (it'd be nice to be able to 'suspend' cronjobs and have them run after you finish e.g. your recording session or low-on-battery-commute :) )
You can still do "updatedb" as root whenever you want to rebuild the cache.
raboof wrote: I'm not sure we're overstating the "problem" here: find traversing your disk and causing some CPU and I/O usage shouldn't interfere with realtime work on any properly configured system, right?
Depends on how much stress you're putting on the CPU, the hard drive. For big projects it could be an issue.

Have a good one!
Post Reply