<div dir="ltr"><div>Cheers all,</div><div><br></div><div>  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)?</div><div><br></div><div>  As I posted at <a href="https://github.com/networkupstools/nut/issues/3115">https://github.com/networkupstools/nut/issues/3115</a> :<div class="gmail-markdown-body"><div class="gmail-Box-sc-g0xbh4-0 gmail-markdown-body gmail-NewMarkdownViewer-module__safe-html-box--dKCgP"><p dir="auto">During discussion of issue <a class="gmail-issue-link gmail-js-issue-link" href="https://github.com/networkupstools/nut/issues/3003">#3003</a> it dawned on me that <code class="gmail-notranslate">upssched.c</code> only calls <code class="gmail-notranslate">fork()</code> to begin a backgrounded timer daemon. All <code class="gmail-notranslate">exec_cmd</code> related operations just call <code class="gmail-notranslate">system()</code> which might use a backgrounding-capable shell, and that only if a <code class="gmail-notranslate">CMDSCRIPT</code> line (or script itself) were so written.</p>
<p dir="auto">This seems to mean (and so I documented via PR <a class="gmail-issue-link gmail-js-issue-link" href="https://github.com/networkupstools/nut/pull/3110">#3110</a>)
 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 <code class="gmail-notranslate">mailx</code> or <code class="gmail-notranslate">wall</code>
 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).</p>
<p dir="auto">Note that <code class="gmail-notranslate">upsmon</code> calls each <code class="gmail-notranslate">NOTIFYCMD</code> in a separate sub-process, so <code class="gmail-notranslate">upssched</code> <code class="gmail-notranslate">EXECUTE</code>
 directives should get handled asynchronously and for practical 
purposes, several "notification" operations can run in parallel. However
 for <code class="gmail-notranslate">upssched</code> timers, there is one daemon and one loop in it.</p><p dir="auto">Consider forking (or doing a WIN32 async thread like in upsmon) when timers fire, so the <code class="gmail-notranslate">upssched</code> loop can go on and not delay any other timers (and/or can queue additional operations - currently a CLI tool instance of <code class="gmail-notranslate">upssched</code>
 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.</p>Jim Klimov</div></div></div><div><br></div></div>