base-files: sysupgrade: Add 2 sec sleep into process KILL loop

Add 2 seconds sleep after each forcibly killed/tried-to-kill process
in the final process termination loop in sysupgrade stage2.

This is needed especially for qualcommax/ipq807x, where ath11k
wireless driver may have a long 10-20 seconds delay after termination
before actually getting killed. This often breaks sysupgrade.

The current KILL loop in kill_remaining does all 10 kill attempts
consecutively without any delay, as evidenced here in a failing sysupgrade.
It does not allow any time for the process to finalize its internal
termination.

Sat Sep  2 19:05:56 EEST 2023 upgrade: Sending TERM to remaining processes ...
Sat Sep  2 19:05:56 EEST 2023 upgrade: Sending signal TERM to hostapd (2122)
Sat Sep  2 19:05:56 EEST 2023 upgrade: Sending signal TERM to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending KILL to remaining processes ...
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2122)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep  2 19:06:00 EEST 2023 upgrade: Failed to kill all processes.
sysupgrade aborted with return code: 256

The change in this commit adds a 2 seconds delay after each kill attempt
in order to allow some processes to more gracefully handle their
internal termination.

The result is like this:

Sun Sep  3 11:15:10 EEST 2023 upgrade: Sending TERM to remaining processes ...
Sun Sep  3 11:15:10 EEST 2023 upgrade: Sending signal TERM to hostapd (2309)
Sun Sep  3 11:15:10 EEST 2023 upgrade: Sending signal TERM to hostapd (2324)
Sun Sep  3 11:15:14 EEST 2023 upgrade: Sending KILL to remaining processes ...
Sun Sep  3 11:15:14 EEST 2023 upgrade: Sending signal KILL to hostapd (2309)
[  699.827521] br-lan: port 7(hn5wpa2r) entered disabled state
[  699.908673] device hn5wpa2r left promiscuous mode
[  699.908721] br-lan: port 7(hn5wpa2r) entered disabled state
[  701.038029] br-lan: port 6(hn5wpa3) entered disabled state
Sun Sep  3 11:15:16 EEST 2023 upgrade: Sending signal KILL to hostapd (2324)
[  702.058256] br-lan: port 5(hn2wlan) entered disabled state
[  709.250063] stage2 (8237): drop_caches: 3
Sun Sep  3 11:15:25 EEST 2023 upgrade: Switching to ramdisk...

The delay introduced here only kicks in if there is some process that
does not get terminated by the first TERM call. Then there is at least
one 2 sec wait after the first KILL loop round.

This commit is related to discussion in PRs #12235 and #12632

Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
Reviewed-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 47d56ae5463f1965750d3f75390c96d69f969145)

diff --git a/package/base-files/files/lib/upgrade/stage2 b/package/base-files/files/lib/upgrade/stage2
index f4db88d31ea18f0016ae08828f9b7d6a204db43d..5ce0b3549cf68d523bab774e01841044fd558c19 100755 (executable)
--- a/package/base-files/files/lib/upgrade/stage2
+++ b/package/base-files/files/lib/upgrade/stage2
@@ -121,7 +121,7 @@ kill_remaining() { # [ <signal> [ <loop> ] ]
                        v "Sending signal $sig to $name ($pid)"
                        kill -$sig $pid 2>/dev/null
 
-                       [ $loop -eq 1 ] && run=true
+                       [ $loop -eq 1 ] && sleep 2 && run=true
                done
 
                let loop_limit--