aboutsummaryrefslogtreecommitdiff
path: root/rc.sysinit
diff options
context:
space:
mode:
authorDan McGee <dan@archlinux.org>2009-11-10 14:06:09 -0600
committerDan McGee <dan@archlinux.org>2009-11-10 14:51:26 -0600
commit7e479ce340e8014da3921f62f1a4f4b8e3c4f595 (patch)
tree26fd789df2385ed99473055b74f45a5f82fae8fa /rc.sysinit
parentbdf8fdb363c9e38bfaad927caac0fecbe989df6b (diff)
downloadinitscripts-7e479ce340e8014da3921f62f1a4f4b8e3c4f595.tar.xz
rc.sysinit: background hwclock calls
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>
Diffstat (limited to 'rc.sysinit')
-rwxr-xr-xrc.sysinit11
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: