Bugzilla – Bug 117023
cron.daily should not run when on battery
Last modified: 2006-02-15 11:59:01 UTC
after installing a new RPM package, the system shutdown takes very long, the machine spends lots of time in "/etc/init.d/boot.preload_early stop". Maybe the "Laying out..." stuff should be done after package install with SUSEconfig or something like that, but certainly not at system shutdown. This takes much more time than the preload feature saves at boot.
i just tested: a machine set to shut down at 1% battery, which is normally enough to shut down, powers off hard during "Laying out..." after installing an extra RPM.
how about: strolchi:/etc/init.d # diff /tmp/boot.preload_early . -u --- /tmp/boot.preload_early 2005-09-15 20:57:43.000000000 +0200 +++ ./boot.preload_early 2005-09-15 20:58:02.000000000 +0200 @@ -15,11 +15,11 @@ . /etc/rc.status rc_reset -/usr/bin/update_preload case "$1" in start) + /usr/bin/update_preload & /sbin/preload < /var/cache/preload/boot.preload rc_status -v ;; this makes it boot slower the next time after a package install, but it is dog slow for shutdown now anyway and at least it will continue booting and not _stop and wait_ for the preload cache to be rebuilt. If there is nothing to update, update_preload is basically a noop and it does not matter if it is put into the background. We still should call update_preload in the yast packagemanager after a package installation, shouldn't we?
your fix is wrong as the next line needs the file generated/updated. We need to introduce a SUSEconfig script and then the init script can stay as it is - as it's a noop if nothing changed as you say.
but nothing bad happens if the file is not updated yet. I tested this on 8 machines here with different scenarios, and even if i touch the rpm database after shutdown (from rescue system), my method is booting faster than yours. The system can continue booting and does not have to wait for more than one minute until the preload cache is rebuilt. If i have to wait on boot or on shutdown does not really matter if it is not a "battery critical" shutdown, but it just does not seem right to wait a minute on shutdown for something we could do in the background during the next boot.
Preload Cache only needs to be updated if something new is added to /etc/preload.d - so that the preload cache ( /var/cache/preload/ ) needs to be regenerated. You can safly turn off update_preload within init. Perhaps we can think about a new yast module that helps adding new scripts to preload.d - but i really don't think update_preload should be executed after package installations, as newly installed packages are not automatically preloaded. Best Regards Marcus
As a first step, please just move /usr/bin/update_preload to the start action without backgrounding it.
What about putting it into cron.daily?
still the same with CODE10beta3
*** Bug 147673 has been marked as a duplicate of this bug. ***
package to be submitted
*** Bug 149575 has been marked as a duplicate of this bug. ***
Could you please post a short summary of the changes? There were several suggestions when to run update_preload - which one(s) did you choose?
The udpate is triggered via cron. But after looking at the cronjob, we might still need to add a check if we are running on battery or not.
*** Bug 150952 has been marked as a duplicate of this bug. ***
Christoph is right, but I don't think this is specific to that very cron.daily
I think this is already done: A look into /usr/lib/cron/run-crons : # # Don't run jobs on laptops, that are AC-offline # if test -x /usr/bin/on_ac_power ; then on_ac_power -q if [ "$?" = "1" ]; then exit 0 fi fi So, if preload-scripts are now done with cron, this should be fixed. Please re-open if you see cron-jobs running on battery. (cron-jobs gthat are NOT created by users themself)
Just coming from Bug 150952, I don't think a cron.daily solution is really a clever solution, at least for the /etc/preload.d/boot part. If you have installed a new kernel, your /lib/modules/`uname -r`/... don't exist any more, update_preload gives error messages because of this. And the modules of the new kernel are not preloaded. Furthermore, cron.daily is already loaded with heavy stuff, all running at the same time. And tweaking invocation time is a real pain, fiddling with "touch -d" in /var/spool/cron/lastrun. For me, a sane, simple and working solution would just be: --- boot.preload_early.orig 2006-02-15 10:51:37.000000000 +0000 +++ boot.preload_early 2006-02-15 10:21:58.000000000 +0000 @@ -15,12 +15,12 @@ . /etc/rc.status rc_reset -/usr/bin/update_preload case "$1" in start) /sbin/preload < /var/cache/preload/boot.preload + nice -19 /usr/bin/update_preload & rc_status -v ;;
we won't do that.