Page 2 of 3
Re: FIND
Posted: Sat May 24, 2014 6:35 pm
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:
Re: FIND
Posted: Sun May 25, 2014 2:06 pm
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:
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
Re: FIND
Posted: Mon May 26, 2014 7:17 am
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.
Re: FIND
Posted: Mon May 26, 2014 7:34 am
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
Re: FIND
Posted: Mon May 26, 2014 8:27 am
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.
Re: FIND
Posted: Mon May 26, 2014 5:27 pm
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.
Re: FIND
Posted: Mon Jun 02, 2014 8:05 am
by DepreTux
You can disable cron and anacron using rcconf.
And you can kill find with "sudo killall -9 find".
Good luck!
Re: FIND
Posted: Mon Jun 02, 2014 12:21 pm
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.
Re: FIND
Posted: Tue Jun 03, 2014 2:33 pm
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
Re: FIND
Posted: Tue Jun 03, 2014 4:58 pm
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?
Re: FIND
Posted: Wed Jun 04, 2014 12:09 pm
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!
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!
Re: FIND
Posted: Sat Jun 07, 2014 9:17 am
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.
Re: FIND
Posted: Sat Jun 07, 2014 10:47 am
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?
Re: FIND
Posted: Sat Jun 07, 2014 10:49 am
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'
Re: FIND
Posted: Sat Jun 07, 2014 11:16 pm
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!