On 1/29/07, James G. Sack (jim) <[EMAIL PROTECTED]> wrote:
Carl Lowenstein wrote:
> On 1/29/07, Serge Rey <[EMAIL PROTECTED]> wrote:
>> On Mon, Jan 29, 2007 at 12:26:43PM -0800, Carl Lowenstein wrote:
>> > This morning I looked in at my Thinkpad T30 (1.8GHz P4M) after it had
>> > been running a screensaver all night, and found that everything
>> > user-interactive had slowed to a crawl.
>> >
>> carl,
>>
>> did you turn these services on yourself, or were they set up out of
>> the box?
>> the reason i ask is i'm running a fresh fedora core 6 install on a
>> desktop and
>> don't see those guys running.
>
> Fresh out of the box. Note that all but yum-updatesd are started from
> cron.daily. So I can reduce the average impact by moving them to
> cron.weekly.
>
> But I still don't understand why several of these services should be
> thrashing the disk simultaneously. I haven't yet looked into
> run-parts which is what actually sequences them.
Well, you've probably already looked and found that run-parts simply
runs all executables (with some fancy qualifications) in the directory
it's told to use ..
I don't offhand see that run-parts starts everything at once.
It looks to me like (very simplified)
for i in $1/* ; do
if [ -x ] $i ; then
$i
fi
done
This doesn't seem to put any process in the background, so the second
one shouldn't start until the first one is finished. --- unless a
process puts itself into the background --- Not immediately obvious
that this might happen, from briefly looking at some of the scripts in
/etc/cron.daily.
.. by /etc/crontab
If you want to split things out of cron.daily (which _all_ run at the
same time, then you would have to separately schedule them. The
cron.daily is a neat idea for most things -- but evidently not all.
Perhaps beagle should be separately scheduled -- look into /etc/cron.d
for other utils that set their own preferred times.
Or, perhaps you've been hit by either:
- a one-time occurrence of initial runs (eg, beagle?)
- a hw/sw bug, where something is retrying forever?
I think it was probably a yum-updatesd bug, triggered by having some
70-odd updates to do. This tied up the system and caused everything
else to run very slowly.
When I made yum list the things to be updated, included on the list
were yum and yum-updatesd. So I did
$ sudo yum update yum
$ sudo yum update
I also modified yum-updatesd in the rc.d /rc[35].d so it won't be
started at boot time, so maybe I'll never know if it got fixed.
Trying to be a good GUI guy, I did this with System -> Administration
-> Services. And then looked at the files to see that the GUI did
what I would have done manually.
carl
--
carl lowenstein marine physical lab u.c. san diego
[EMAIL PROTECTED]
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
