[fix] Install SIGUSR1/USR2 handlers before the main loop#263
[fix] Install SIGUSR1/USR2 handlers before the main loop#263MichaelUray wants to merge 1 commit into
Conversation
The SIGUSR1/USR2 traps were installed only around the interval sleep and cleared immediately after, so the first configuration cycle after boot -- and every work phase -- ran under the default signal disposition, where SIGUSR1/USR2 terminate the process. A SIGUSR1 sent by openwisp.hotplug when the management interface comes up, or a SIGUSR2 sent by "openwisp-config --force-update", typically arrives shortly after boot during that first configuration apply. In that window the signal killed the agent instead of being handled (interrupt sleep or force update); procd restarts it, but the restart happens mid-apply and can leave the applying_conf lockfile behind. Install both handlers once, before the loop, and keep them for its whole lifetime. The handlers only log and (for USR2) drop the checksum files, so they are safe to run at any point, and the signals are now always handled and never fatal. Signed-off-by: Michael Uray <michaeluray@users.noreply.github.com>
|
Warning Review limit reached
Next review available in: 1 minute Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (1 files)
Reviewed by step-3.7-flash · Input: 64.8K · Output: 4K · Cached: 433.4K |
1 participant
Problem
The
SIGUSR1/SIGUSR2traps are installed only inside the main loop,immediately around the interval
sleep, and cleared again right after. Thevery first configuration cycle after boot — and in fact every work phase —
therefore runs under the default signal disposition, where
SIGUSR1/SIGUSR2terminate the process.A
SIGUSR1sent byopenwisp.hotplugwhen the management interface comes up,or a
SIGUSR2sent byopenwisp-config --force-update, typically arrivesshortly after boot during that first configuration apply. In that window the
signal kills the agent instead of being handled. procd restarts it, but the
restart happens mid-apply and can leave the
applying_conflockfile behind.Fix
Install both handlers once, before the loop, and keep them for its whole
lifetime, removing the per-iteration set/clear. The handlers only log and (for
USR2) drop the checksum files, so they are safe to run at any point; thesignals are now always handled and never fatal.
Testing
shellcheck,shfmt,./run-qa-checksand./runtestsall pass.