Re: [Cooker] cron.daily: rpm
On 20 Sep 2002, Adam Williamson wrote: > On Fri, 2002-09-20 at 13:24, Götz Waschk wrote: > > Am Freitag, 20. September 2002, 13:58:31 Uhr MET, schrieb rcc: > > > do we need to have rpm in cron.daily? > > > Because like slocate it brings older computers almost to a halt. > > > > Stop whining. How long can a rpm -qa take? Not more than 10 Seconds on an > > old Pentium I guess. > > About 20 on this p2-400 with 4200rpm hard disk. Same order of magnitude... :-) Guy
Re: [Cooker] cron.daily: rpm
On Fri Sep 20 14:24 +0200, Götz Waschk wrote: > Stop whining. How long can a rpm -qa take? Not more than 10 Seconds on an > old Pentium I guess. rpmv runs for a lot longer than 10 seconds on my Duron 650. -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Love lies in pools of questions. Linux 2.4.19-9mdk 2:30pm up 2 days, 1:41, 5 users, load average: 0.17, 0.17, 0.11
Re: [Cooker] cron.daily: rpm
rcc wrote: > > do we need to have rpm in cron.daily? > > Because like slocate it brings older computers almost to a halt. Actually, i would like to be able to setup the frequency of the script lauched by cron: When a package is updated, it is reverted back to its original directory. Maybe could it be possible to have some common directory for cron scripts and a link from the cron.(hourly|daily|weekly|monthly). Something like rc?.d scripts ... Maybe to plan for 9.1 ?
Re: [Cooker] cron.daily: rpm
Le Vendredi 20 Septembre 2002 15:37, Adam Williamson a écrit : > On Fri, 2002-09-20 at 13:24, Götz Waschk wrote: > > Am Freitag, 20. September 2002, 13:58:31 Uhr MET, schrieb rcc: > > > do we need to have rpm in cron.daily? > > > Because like slocate it brings older computers almost to a halt. > > > > Stop whining. How long can a rpm -qa take? Not more than 10 Seconds on an > > old Pentium I guess. > > About 20 on this p2-400 with 4200rpm hard disk. As rpm bash programmable completion use installed package list quite a lot, better have it run once per day/night to cache the result, instead of everytime you try rpm -q I guess it has other use too, as this cron task existed before programmable completion. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
Re: [Cooker] cron.daily: rpm
On Fri, 20 Sep 2002, Götz Waschk wrote: > Am Freitag, 20. September 2002, 13:58:31 Uhr MET, schrieb rcc: > > do we need to have rpm in cron.daily? > > Because like slocate it brings older computers almost to a halt. > > Stop whining. How long can a rpm -qa take? Not more than 10 Seconds on an > old Pentium I guess. The issue may be deeper than that -- if there is a stale of corrupt set of locks left behind due to easily repairable damage in indices in the rpm database, the unit can freeze forever, doing a simple task likerpm -qa The new RPM-4.1 relase and a transition will fix this permanently -- see the RPM website at: http://www.rpm.org/ in the Hints and Kinks link, under the Repair DB sub link for more details. For older releases, detecting stale lockfiles with an external process, and periodically (weekly?) running a process to detect a corrupted database is probably a good idea. -- Russ Herrold
Re: [Cooker] cron.daily: rpm
On Fri, 2002-09-20 at 13:24, Götz Waschk wrote: > Am Freitag, 20. September 2002, 13:58:31 Uhr MET, schrieb rcc: > > do we need to have rpm in cron.daily? > > Because like slocate it brings older computers almost to a halt. > > Stop whining. How long can a rpm -qa take? Not more than 10 Seconds on an > old Pentium I guess. About 20 on this p2-400 with 4200rpm hard disk. -- adamw
Re: [Cooker] cron.daily: rpm
On Fri, 20 Sep 2002 15:28:25 +0200 Götz Waschk <[EMAIL PROTECTED]> wrote: > > and there was rpmv running. The > > thing didn't stop for the next 5 minutes I watched so I killed it. > > I see. That's the security check by msec that's enabled by default in > security level 3. You can customize that or use level 2. thanks, I'll do that, guess it's time to get deeper into msec - Mark
Re: [Cooker] cron.daily: rpm
Am Freitag, 20. September 2002, 15:17:32 Uhr MET, schrieb rcc: > I thought is was rpm because when the user complained about being unable > to do anything due to her disk thrashing for the last quarter of an hour > I looked at the processes and there was rpmv running. The thing didn't > stop for the next 5 minutes I watched so I killed it. I see. That's the security check by msec that's enabled by default in security level 3. You can customize that or use level 2. -- Götz Waschk <> master of computer science <> University of Rostock http://wwwtec.informatik.uni-rostock.de/~waschk/waschk.asc for PGP key --> Logout Fascism! <--
Re: [Cooker] cron.daily: rpm
On Fri, 20 Sep 2002 14:24:38 +0200 Götz Waschk <[EMAIL PROTECTED]> wrote: > Am Freitag, 20. September 2002, 13:58:31 Uhr MET, schrieb rcc: > > do we need to have rpm in cron.daily? > > Because like slocate it brings older computers almost to a halt. > > Stop whining. How long can a rpm -qa take? Not more than 10 Seconds on > an old Pentium I guess. you're right, it isn't rpm I thought is was rpm because when the user complained about being unable to do anything due to her disk thrashing for the last quarter of an hour I looked at the processes and there was rpmv running. The thing didn't stop for the next 5 minutes I watched so I killed it. Nevermind, I'll just adapt my post install scripts to remove the daily stuff. - Mark
Re: [Cooker] cron.daily: rpm
Am Freitag, 20. September 2002, 13:58:31 Uhr MET, schrieb rcc: > do we need to have rpm in cron.daily? > Because like slocate it brings older computers almost to a halt. Stop whining. How long can a rpm -qa take? Not more than 10 Seconds on an old Pentium I guess. -- Götz Waschk <> master of computer science <> University of Rostock http://wwwtec.informatik.uni-rostock.de/~waschk/waschk.asc for PGP key --> Logout Fascism! <--
Re: [Cooker] cron.daily: rpm
rcc wrote: >do we need to have rpm in cron.daily? > >Because like slocate it brings older computers almost to a halt. > > >- Mark > > > > > I agree, there should be some sort of option for older computers for cases like these, especially when it comes to modules, and other things that's gzip/bzip'ed, eg. it takes ages to do depmod -a since it has to decompress everything first
