Nut upsdev - Oct 2025 - It seems that upssched exec_cmd() is not async...

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
<https://github.com/networkupstools/nut/issues/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
<https://github.com/networkupstools/nut/pull/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:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20251006/f1a87157/attachment.htm>