<div dir="auto">Definitely a valid point for any multiplexing driver, for failover probably less so as individual devices are involved which each need shutting down to successfully kill all power.</div><div dir="auto"><br></div><div dir="auto">Maybe for the multiplexing issue a settable flag on any individual driver "nokill" could instruct upsdrvctl to exclude that duplicate driver from wholesale "upsdrvctl shutdown", so that the user can decide which driver does shutdown best.</div><div dir="auto"><br></div><div dir="auto">But yes, probably an issue for another day. :-) </div><div dir="auto"><br></div><div dir="auto">Again, many thanks for the insights and discussion!</div><div dir="auto"><br></div><div dir="auto">Sebastian</div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>> schrieb am Mo. 12. Mai 2025 um 17:54:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thinking of it, the service-aware nut-driver-enumerator script has ways to set dependencies of a driver on other units in the system, depending on driver type. A couple of lines added there would be useful to ensure the failover/multiplex driver(s) start after the "real" driver units they scrape data from, and it would be a "soft" dependency (real driver unit may crash without impacting the failover/multiplexor).</div><div><br></div><div>But I guess this (and a myriad other nuances that would pop up) can also be tackled after an actual driver appears :)</div></div><div dir="ltr"><div><br></div><div>Jim</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 5:40 PM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Good point, I guess I thought it knew which UPSes are getting the FSD treatment.</div><div><br></div><div>Maybe this should also get revised eventually (e.g. a "primary" monitoring system not fed by the UPS it is wired to should never FSD itself due to the outage, but should ensure that UPS gets powered off or power-cycled when no "secondary" clients remain).</div><div><br></div><div>Then maybe not much is needed at this time, and we'd revisit this as we hit any issues. <br></div><div><br></div><div>One point I remain concerned about is the UPS getting confused about receiving the same commands over different protocols/media in short sequence. Or similar but conflicting commands because one driver knows how to request "load.off" and another knows about "shutdown.stayoff" or "shotdown.reboot" leading to different code paths in the UPS controller
- can't exclude some firmware getting wedged about this.</div><div><br></div><div>In this case `upsdrvctl shutdown` should somehow know to only try one of the drivers at a time (perhaps `sdorder` can be useful to at least somehow separate these attempts in time), or to just start both "real" drivers in a mode with `allow_killpower` (but not with `-k`) so that the failover/multiplex driver can decide which one to call, and when/whether to call another. The tool uses a common NUT config parser, so might be taught about special driver names (failover) and their port values as inputs for its work or lack thereof. Probably "upsdrvctl shutdown realdriver" should work as it did, but
"upsdrvctl shutdown failoverdriver"
or "upsdrvctl shutdown" (for all UPSes) should do these tricks.</div><div><br></div><div>Jim</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 5:25 PM Sebastian Kuttnig via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" target="_blank">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>P.S. To articulate better what I am unclear about from your message:</div><div><br></div><div>`nutshutdown` seems to run `@SBINDIR@/upsdrvctl shutdown`.</div><div>From my understanding, this would command - all - `ups.conf` UPS to shutdown.</div><div>So this would already include the UPS monitored by any failover/multiplexing driver.</div><div>In contrast, `upsdrvctl shutdown` would start up all these drivers again, respectively.</div><div><br></div><div>What kind of specific orchestration would be required for the "proxying" driver?</div><div><br></div><div>My initial understanding was it would simply not support a shutdown command itself</div><div>and `upsdrvctl` would command all supporting UPS to shutdown/start regardless of it.</div><div>So similar to the clone* drivers, which seem not to have any special handling there.</div><div><br></div><div>Thanks for the detailed responses so far, I am still exploring some areas of the NUT ecosystem. :-)</div><div><br></div><div>Sebastian</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 12. Mai 2025 um 16:02 Uhr schrieb Sebastian Kuttnig <<a href="mailto:sebastian.kuttnig@gmail.com" target="_blank">sebastian.kuttnig@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello Jim,</div><div><br></div><div>I am following the direction of the `clone` drivers, although using the modern `upsdrvquery.c` API.</div><div>Essentially I am parsing the protocol lines directly reading from the driver sockets, as the clone drivers do.</div><div><br></div><div>As for ups.conf, I start up as follows without problems:<br><br><div style="margin-left:40px">[ups]<br>driver = dummy-ups<br>port = /etc/nut/5E.dev<br><br>[ups2]<br>driver = dummy-ups<br>port = /etc/nut/APC.dev<br><br>[failover]<br>driver = failover<br>port = dummy-ups-ups,dummy-ups-ups2</div><div style="margin-left:40px"><br></div>Is this what you had in mind?</div><div>Appreciate any pointers regarding the `upsdrvctl` and `nutshutdown` specifics.
</div><div><br></div><div>Sebastian</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 12. Mai 2025 um 15:53 Uhr schrieb Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Sounds great, thanks for the update!</div><div><br></div><div>For communications with the other drivers (from failover or multiplexor), I suggest using the local driver socket line the clone* drivers do: this removes a dependency on `upsd` both for the service startup (no chicken-and-egg issue of drivers before upsd, but upsd before the failover driver) and for FSD end-game (after all services stopped, we just need to start the drivers to talk to the UPS, no need for upsd so they can see each other).</div><div><br></div><div>Speaking of the latter, the `nutshutdown` script (or `upsdrvctl`) may need an update to know to start those additional drivers. Or perhaps do them one by one in case of shutdown command specifically (or any command generally), until one succeeds.</div><div><br></div><div>Jim</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 3:22 PM Sebastian Kuttnig via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" target="_blank">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello again,<br><br>I can report back that my failover driver is progressing nicely, and a lot of<br>things seem to overlap with what could very well also be useful and maybe used<br>eventually for a future multiplexing driver.<br><br>Basically, my failover logic takes driver names (sockets) in comma-separated<br>form from the `port` variable and keeps track of these drivers, monitoring<br>their information and failing over where necessary. Basic configuration looks<br>like:<br><br> [failover]<br> driver = failover<br> port = dummy-ups-ups,dummy-ups-ups2<br><br>I could well picture a multiplexing driver accepting a similar format, merging<br>variables of both drivers and resolving conflicts by port argument order<br>(`dummy-ups-ups`, then `dummy-ups-ups2`) in its most basic form.<br><br>Additionally, this could be extended with preference arguments, such as:<br><br> prefer.ups.status = dummy-ups-ups<br> prefer.battery.voltage.nominal = dummy-ups-ups2<br><br>Such definitions would take precedence over the port argument order, for more<br>granular control. This could be similar to what is used in `ups.conf` for<br>`default.<variable>` or `override.<variable>`, format-wise.<br><br>If either driver were to drop offline, the other driver could take over with<br>its full set of variables, regardless of other set preferences.<br><br>Just a rough sketch of what I have in my mind. Time permitting, I'll start<br>working on this at some point after I finish my failover explorations.<br><br>Sebastian<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 12. Mai 2025 um 14:16 Uhr schrieb Greg Troxel via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" target="_blank">nut-upsdev@alioth-lists.debian.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wow, that's quite the tale!<br>
<br>
I take away from this:<br>
<br>
There is a real example of wanting to merge two information sources.<br>
<br>
It's very complicated.<br>
<br>
Anybody wishing to succeed in a very complicated situation needs to<br>
really pay attention, to twice as many things as they thought when<br>
they started.<br>
<br>
It's unclear how to generalize from this to a solution that will work<br>
for the next person.<br>
<br>
but if someone wants to write soemthing that is an aggregating driver<br>
(looks like a driver, talks to N driver), and do so in a way that<br>
doesn't cause any significant pain for others that seems like a fine<br>
thing for them to do.<br>
<br>
I would suggest having some sort of config file that for each variable<br>
says which driver to prefer, and some kind of timeout for not available<br>
to flip to the backup. I guess for starters, one could configure two<br>
drivers in "fancier/less-reliable" and "old-school" slots, and prefer<br>
fancier for all except shutdown and status.<br>
<br>
I fear that the next layer is merging status from two where they don't<br>
quite match.<br>
<br>
<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div></div>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>