start_watchdog() and reset_watchdog() exist, but stop logic is inlined.
Giving it a name seems better.
No functional change.
Feedback? Objection? OK?
Questions wrt. upgrade.site(5) prompted me to look at whether execution of
/upgrade.site execution is subject to this timeout: it is, finish_up()
runs $MODE.site and the watchdog gets stopped afterwards.
Index: install.sub
===================================================================
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1241
diff -u -p -r1.1241 install.sub
--- install.sub 7 Apr 2023 13:48:42 -0000 1.1241
+++ install.sub 13 Apr 2023 15:14:31 -0000
@@ -3452,11 +3452,8 @@ do_upgrade() {
# Perform final steps common to both an install and an upgrade.
finish_up
- if [ -f /tmp/wdpid ]; then
- kill -KILL "$(cat /tmp/wdpid)" 2>/dev/null
- # do not bother waiting
- rm -f /tmp/wdpid
- fi
+
+ stop_watchdog
}
check_unattendedupgrade() {
@@ -3483,6 +3480,7 @@ WATCHDOG_PERIOD_SEC=$((30 * 60))
# Restart the background timer.
reset_watchdog() {
local _pid
+
if [ -f /tmp/wdpid ]; then
_pid=$(cat /tmp/wdpid)
kill -KILL -$_pid 2>/dev/null
@@ -3501,6 +3499,14 @@ start_watchdog() {
) >/dev/null 2>&1 &
echo $! > /tmp/wdpid
set +m
+}
+
+stop_watchdog() {
+ if [ -f /tmp/wdpid ]; then
+ kill -KILL "$(cat /tmp/wdpid)" 2>/dev/null
+ # do not bother waiting
+ rm -f /tmp/wdpid
+ fi
}
# return if we only want internal functions
