Thanks for that. The problem I have with running crons in the early hours is that my system is not up 247. However I am interested in msec. I had been concentrating on rpm and rpmv since I could see why it would want to run grep, sed and sort. I could also understand the length of time required to plough through the complete RPM database and I could see that cron.daily/rpm was calling sort. However, I had not realised that msec also does RPM DB checks and rebuilds. How long have the RPM DB checks and rebuilds been in security.sh ?? (Forever, I know :-) ). Perhaps setting RPM_CHECK to "no" will make the system a bit more usable :-)
However, there is surely an issue with running cron jobs that cause such a user impact, without either setting them at a very low priority or giving the user the option to run them in some other manner. I well remember a large group of people all laughing at the Power Point presentation that was brought to a halt because Window$ had decided to run its equivilant of slocate ! Perhaps having cron.daily/rpm and cron.daily/msec both hammering the RPM DB is not such a good idea ? Any way, mystery over ! Thanks for that. Owen On Monday 11 Feb 2002 10:45 pm, you wrote: > On Monday 11 February 2002 17:35, you wrote: > > Hello, > > > > Could someone PLEASE tell me how to stop : (Oh boy - here we go. It's > > just taken over a minute to launch a console.) > > 1566 ? 00:00:00 run-parts > > 1750 ? 00:00:00 msec > > 1828 ? 00:06:20 rpmv > > 1829 ? 00:00:00 grep > > 1830 ? 00:00:00 sed > > 1831 ? 00:00:00 sort > > Owen, > > Check in your /etc/cron.hourly, /etc/cron.daily and also /etc/crontab for > these jobs. Remove the ones you don't wish to run and then send syslogd > the HUP signal (killall -HUP syslogd) to apply the changes. On my system > here msec runs at 4am so I don't usually notice the sudden slowdown and > loss of performance. If you are familiar with using cron you may wish to > simply change the times at which the jobs run. Hope this helps.
