upssched: fix cmd exec to be async (in timer) #3115
Description
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 CMDSCRIPT line were so configured.
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.
CC @clepple @aquette : WDYT? Is there any reason NOT to fix this? Did I misunderstand something in that code?