| Message ID | 20251113085818.371086-1-fe@dev.tdt.de |
|---|---|
| State | New |
| Headers | show |
| Series | base-files: stage2: stop Wi-Fi service on firmware upgrade | expand |
> Le 13 nov. 2025 à 09:58, Florian Eckert <fe@dev.tdt.de> a écrit : > > It may happen that the WiFi service cannot be stopped with a 'TERM' and > 'KILL' signal. As a result the firmware upgrade is failing with the > following log messages. > > Mon Nov 3 21:28:06 CET 2025 upgrade: Sending KILL to remaining processes ... > Mon Nov 3 21:28:06 CET 2025 upgrade: Sending signal KILL to hostapd (5664) > Mon Nov 3 21:28:09 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:11 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:13 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:15 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:17 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:19 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:22 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:24 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:26 CET 2025 upgrade: Sending signal KILL to hostapd (5688) > Mon Nov 3 21:28:28 CET 2025 upgrade: Failed to kill all processes. > sysupgrade aborted with return code: 256 > > It appears that this is because clients remain connected to the system > via Wi-Fi during the system upgrade. The script call '/sbin/wifi down' > before sending the 'TERM' and 'KILL' signal fixes the problem and the > sysupgrade is completed successfully. Err, isn’t this working around the actual issue here? It seems like a (serious?) problem that a process cannot be KILLed. This is bound to affect regular reboots as well, which in turn will have other consequences for end users. IMHO hostapd should be fixed instead. My 2c, T.
On 2025-11-13 10:04, Thibaut wrote: >> Le 13 nov. 2025 à 09:58, Florian Eckert <fe@dev.tdt.de> a écrit : >> >> It may happen that the WiFi service cannot be stopped with a 'TERM' >> and >> 'KILL' signal. As a result the firmware upgrade is failing with the >> following log messages. >> >> Mon Nov 3 21:28:06 CET 2025 upgrade: Sending KILL to remaining >> processes ... >> Mon Nov 3 21:28:06 CET 2025 upgrade: Sending signal KILL to hostapd >> (5664) >> Mon Nov 3 21:28:09 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:11 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:13 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:15 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:17 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:19 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:22 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:24 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:26 CET 2025 upgrade: Sending signal KILL to hostapd >> (5688) >> Mon Nov 3 21:28:28 CET 2025 upgrade: Failed to kill all processes. >> sysupgrade aborted with return code: 256 >> >> It appears that this is because clients remain connected to the system >> via Wi-Fi during the system upgrade. The script call '/sbin/wifi down' >> before sending the 'TERM' and 'KILL' signal fixes the problem and the >> sysupgrade is completed successfully. > > Err, isn’t this working around the actual issue here? It seems like a > (serious?) problem that a process cannot be KILLed. You may be right. When creating the patch, I thought about why hostapd does not respond to KILL! > This is bound to affect regular reboots as well, which in turn will > have other consequences for end users. I haven't seen any problems with that. The reboot has always worked so far. The problem with KILL doesn't seem to be relevant on reboot. > IMHO hostapd should be fixed instead. Of course, that would be the best solution, but currently it is a problem and I do not believe that the problem will be found quickly. I don't know where to start in hostpad. It may also depend on drivers (ath10k, ath11k, ...) and Wi-Fi firmware? -- Florian
Am Thu, Nov 13, 2025 at 10:24:04AM +0100, schrieb Florian Eckert: > On 2025-11-13 10:04, Thibaut wrote: > > IMHO hostapd should be fixed instead. > > Of course, that would be the best solution, but currently it is a > problem and I do not believe that the problem will be found quickly. > > I don't know where to start in hostpad. It may also depend on drivers > (ath10k, ath11k, ...) and Wi-Fi firmware? This sounds interesting. Where (at which hardware) does the issue occur?
Hello Jonas, On 2025-11-13 13:03, Jonas Lochmann wrote: > Am Thu, Nov 13, 2025 at 10:24:04AM +0100, schrieb Florian Eckert: >> On 2025-11-13 10:04, Thibaut wrote: >> > IMHO hostapd should be fixed instead. >> >> Of course, that would be the best solution, but currently it is a >> problem and I do not believe that the problem will be found quickly. >> >> I don't know where to start in hostpad. It may also depend on drivers >> (ath10k, ath11k, ...) and Wi-Fi firmware? > > This sounds interesting. Where (at which hardware) does the issue > occur? I have encountered this on my openwrt-23.05 target with the following setup. Hardware: 0007:01:00.0 Network controller: Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter (rev 01) Software: ath11k-firmware-wcn6855 - 20230804-1 kmod-ath11k - 5.15.189-6.1.145-1-1 kmod-ath11k-pci - 5.15.189-6.1.145-1-1 hostapd-common - 2023-09-08-e5ccbfc6-8 hostapd-utils - 2023-09-08-e5ccbfc6-8 Unfortunately, I cannot test my setup on an openwrt-24.10/master branch because the router is not supported there.I will test WLAN-Modul in another router running openwrt-24.10 when I have time or check if the error is also presented with an other WLAN-Modul. Best Regards Florian
diff --git a/package/base-files/files/lib/upgrade/stage2 b/package/base-files/files/lib/upgrade/stage2 index 5ce0b3549c..00c957c8eb 100755 --- a/package/base-files/files/lib/upgrade/stage2 +++ b/package/base-files/files/lib/upgrade/stage2 @@ -154,6 +154,11 @@ killall -9 telnetd 2>/dev/null killall -9 dropbear 2>/dev/null killall -9 ash 2>/dev/null +[ -f /sbin/wifi ] && { + v "Stopping Wi-Fi service" + /sbin/wifi down +} + kill_remaining TERM sleep 4 kill_remaining KILL 1
It may happen that the WiFi service cannot be stopped with a 'TERM' and 'KILL' signal. As a result the firmware upgrade is failing with the following log messages. Mon Nov 3 21:28:06 CET 2025 upgrade: Sending KILL to remaining processes ... Mon Nov 3 21:28:06 CET 2025 upgrade: Sending signal KILL to hostapd (5664) Mon Nov 3 21:28:09 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:11 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:13 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:15 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:17 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:19 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:22 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:24 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:26 CET 2025 upgrade: Sending signal KILL to hostapd (5688) Mon Nov 3 21:28:28 CET 2025 upgrade: Failed to kill all processes. sysupgrade aborted with return code: 256 It appears that this is because clients remain connected to the system via Wi-Fi during the system upgrade. The script call '/sbin/wifi down' before sending the 'TERM' and 'KILL' signal fixes the problem and the sysupgrade is completed successfully. Signed-off-by: Florian Eckert <fe@dev.tdt.de> --- package/base-files/files/lib/upgrade/stage2 | 5 +++++ 1 file changed, 5 insertions(+)