hwclock calls appear to block somewhere between 1 and 2 seconds when we have back-to-back calls. My theory (without looking at the code) is that hwclock has to synchronize to the 1 second intervals of the hardware clock, so it can sometimes take up to a second to complete. To get around this unpleasant behavior, we can background the calls at point X in the boot sequence, and then later at point Y in the script (when we absolutely need the clock actions to be complete), we wait on the subprocess. This allows the rest of the boot sequence, after the hwclock code block, to continue until the point where we wait on the subprocess. Signed-off-by: Dan McGee <dan@archlinux.org> --- rc.sysinit | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 0c934c7..e948074 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -281,9 +281,13 @@ if [ "$TIMEZONE" != "" -a -e "/usr/share/zoneinfo/$TIMEZONE" ]; then /bin/cp "/usr/share/zoneinfo/$TIMEZONE" /etc/localtime fi +clock_pid="" if [ -n "$HWCLOCK_PARAMS" ]; then + ( /sbin/hwclock --adjust #Adjust for system drift /sbin/hwclock $HWCLOCK_PARAMS + ) & + clock_pid=$! fi stat_done @@ -396,7 +400,12 @@ fi /bin/dmesg >| /var/log/dmesg.log +# final hwclock setting needs to be done at this point +if [ -n "$clock_pid" ]; then + wait $clock_pid +fi + run_hook sysinit_end # End of file -# vim: set ts=2 noet: +# vim: set ts=2 sw=2 noet: -- 1.6.5.5