>> [...] complaints about slocate.cron > > Every Linux box I've ever had did the same thing, so I'm not sure the > rant on Red hat is warranted. Besides, it happens at 4:00am when even > my public Internet servers don't have much of a load. > > And, given the fact that it runs at an extremely low priority (nice > +19) it should not cause a discernible slowdown in any machine. > Certainly I have never noticed such a slowdown, God forbid seeing the > entire server slow down to the point where it's a problem.
I think the "YMMV" is very appropriate in this instance, especially between a full-time real server and a small system. My observations are probably irrelevant to the original question, but may explain different perceptions about what is or is not important. The updatedb process that runs from slocate.cron does not chew significant CPU but the process does seem to get I/O bound, so the 'nice' might be largely irrelevant. I presume the kernel is optimised to new SCSI-based systems, because on older systems with IDE discs (even if they are using udma) the responsiveness (file/web serving, ssh sessions) drops dramatically once any intensive disk-scanning activity takes place. Tripwire is another process that is very noticeable on my home system. Find would be another bad idea. If you don't have a very active system you can just run 'slocate.cron' once a week instead of daily. I can usually remember where I've put things in the previous few days :-). Cameron -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
