Displaying 9 results from an estimated 9 matches for "upsdrvquery".
2023 Apr 19
2
Enhanced driver troubleshooting
Cheers,
With https://github.com/networkupstools/nut/pull/1906 and
https://github.com/networkupstools/nut/pull/1912 (and probably some more
later), I've been enhancing NUT driver framework with support for live
reload of configuration, primarily to acknowledge changes to debug_min
setting in ups.conf - but made in a generic fashion that specific drivers
may take advantage of for their
2023 Apr 19
2
Enhanced driver troubleshooting
Cheers,
With https://github.com/networkupstools/nut/pull/1906 and
https://github.com/networkupstools/nut/pull/1912 (and probably some more
later), I've been enhancing NUT driver framework with support for live
reload of configuration, primarily to acknowledge changes to debug_min
setting in ups.conf - but made in a generic fashion that specific drivers
may take advantage of for their
2025 May 12
1
Questions about failover architecture
Hello Jim,
I am following the direction of the `clone` drivers, although using the
modern `upsdrvquery.c` API.
Essentially I am parsing the protocol lines directly reading from the
driver sockets, as the clone drivers do.
As for ups.conf, I start up as follows without problems:
[ups]
driver = dummy-ups
port = /etc/nut/5E.dev
[ups2]
driver = dummy-ups
port = /etc/nut/APC.dev
[failover]
driver = f...
2025 May 09
2
Questions about failover architecture
Hi all,
Yesterday?s PR #2945 got me thinking about my basic failover setup and
raised
some questions I didn?t want to derail the PR with?hope this is the right
place
to ask. Apologies if not.
The PR includes this note:
> NOTE: There is currently no support for "multiplexing" information or
> commands for devices with multiple-media/multiple-driver access, e.g. to
> gain
2025 May 12
2
Questions about failover architecture
...esponses so far, I am still exploring some areas
of the NUT ecosystem. :-)
Sebastian
Am Mo., 12. Mai 2025 um 16:02 Uhr schrieb Sebastian Kuttnig <
sebastian.kuttnig at gmail.com>:
> Hello Jim,
>
> I am following the direction of the `clone` drivers, although using the
> modern `upsdrvquery.c` API.
> Essentially I am parsing the protocol lines directly reading from the
> driver sockets, as the clone drivers do.
>
> As for ups.conf, I start up as follows without problems:
>
> [ups]
> driver = dummy-ups
> port = /etc/nut/5E.dev
>
> [ups2]
> driver = dumm...
2025 May 12
1
Questions about failover architecture
...> of the NUT ecosystem. :-)
>
> Sebastian
>
> Am Mo., 12. Mai 2025 um 16:02 Uhr schrieb Sebastian Kuttnig <
> sebastian.kuttnig at gmail.com>:
>
>> Hello Jim,
>>
>> I am following the direction of the `clone` drivers, although using the
>> modern `upsdrvquery.c` API.
>> Essentially I am parsing the protocol lines directly reading from the
>> driver sockets, as the clone drivers do.
>>
>> As for ups.conf, I start up as follows without problems:
>>
>> [ups]
>> driver = dummy-ups
>> port = /etc/nut/5E.dev
>...
2025 May 09
1
Questions about failover architecture
...; we need a way (automatic and/or user-tunable) to select which variant we
> prefer (exclusively, or what to try first - in case of commands or
> writeable settings).
> * The approach of `clone*` drivers (which talk to another driver directly
> over local socket) and recent advances in `upsdrvquery.{c,h}` may be more
> applicable than using a `dummy-ups` driver (is a NUT networked protocol
> client when going in relay/proxy mode) that I initially thought could be
> useful here.
>
> But so far nothing has been fleshed out beyond that (AFAIK)...
>
> Hope this helps,
> Ji...
2025 May 12
1
Questions about failover architecture
...>> Sebastian
>>
>> Am Mo., 12. Mai 2025 um 16:02 Uhr schrieb Sebastian Kuttnig <
>> sebastian.kuttnig at gmail.com>:
>>
>>> Hello Jim,
>>>
>>> I am following the direction of the `clone` drivers, although using the
>>> modern `upsdrvquery.c` API.
>>> Essentially I am parsing the protocol lines directly reading from the
>>> driver sockets, as the clone drivers do.
>>>
>>> As for ups.conf, I start up as follows without problems:
>>>
>>> [ups]
>>> driver = dummy-ups
>>...
2025 May 12
1
Questions about failover architecture
Sounds great, thanks for the update!
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