From jimklimov+nut at gmail.com Mon Oct 6 22:28:53 2025 From: jimklimov+nut at gmail.com (Jim Klimov) Date: Mon, 6 Oct 2025 23:28:53 +0200 Subject: [Nut-upsdev] It seems that upssched exec_cmd() is not async... Message-ID: Cheers all, It seems that upssched exec_cmd() is not async; if true - is this a problem? Should this be fixed (or rather, are there any reasons not to - could something rely on `CMDSCRIPT` call-outs being sequential)? As I posted at https://github.com/networkupstools/nut/issues/3115 : During discussion of issue #3003 it dawned on me that upssched.c only calls fork() to begin a backgrounded timer daemon. All exec_cmd related operations just call system() which might use a backgrounding-capable shell, and that only if a CMDSCRIPT line (or script itself) were so written. This seems to mean (and so I documented via PR #3110 ) that each launched operation has to wait for that copy of the notification process to complete, and only then another may start. This may be a little problem for mailx or wall calls, but a bigger one if the called process takes a long while (e.g. stop some database and wait for its init script to complete, or SSH into some appliance to turn it off early in case of pending FSD). Note that upsmon calls each NOTIFYCMD in a separate sub-process, so upssched EXECUTE directives should get handled asynchronously and for practical purposes, several "notification" operations can run in parallel. However for upssched timers, there is one daemon and one loop in it. Consider forking (or doing a WIN32 async thread like in upsmon) when timers fire, so the upssched loop can go on and not delay any other timers (and/or can queue additional operations - currently a CLI tool instance of upssched would probably hang while the daemon is busy). Also we probably should not exit the timer daemon (as it does now if quiet for too long) while any children still exist. Jim Klimov -------------- next part -------------- An HTML attachment was scrubbed... URL: