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
---
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