Bug 117023

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.