search for: upsnames

...nction has this comment: /* split [upsname@]hostname[:port] into separate components */ To me, this implies that "upsname@" is optional, but I think this is left over from an older version of NUT (since you have to specify an upsname for upsc). I was thinking that listing all available upsnames would be done like this: "upsc -l hostname[:port]". In order to reuse the upscli_splitname() code, I was thinking that I could modify it to simply return NULL in *upsname if there is no '@' sign. The alternative would be to have a flag (also an API change) or create upscli_splith...

Great, thanks! Two questions: * what is a domain literal? Is this something like 192.168.0.1? In this case, the '[]' are probably unnecessary. * are you sure you want to use fprintf(stderr, ...) in a library? This doesn't seem like a good idea to me. Wouldn't it be more consistent to extend upscli_errlist[] ? -- Peter Arjen de Korte wrote: > > Author:

After launching the command several times, with debug (posted by new code in a new branch for the investigation) confirming that the same daemon handles operations from the new client instances, its strace now has numerous FDs to report after select() - so I guess it is a problem of detecting an exit of the counterpart. 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT

After launching the command several times, with debug (posted by new code in a new branch for the investigation) confirming that the same daemon handles operations from the new client instances, its strace now has numerous FDs to report after select() - so I guess it is a problem of detecting an exit of the counterpart. 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT

> On Aug 13, 2018, at 06:17, Charles Lepple <clepple at gmail.com> wrote: > > On Aug 12, 2018, at 11:03 PM, Kevin Mychal M. Ong <kevindd992002 at yahoo.com> wrote: >> >> Hi, >> >> I installed apcupsd through pfsense and noticed some discrepancy with the NUT package. I'm not sure if this is a bug regarding the BATTDATE (apcupsd) and battery.date

Hi everybody, i'm trying to use the UPSNAME environment variable within the script launched by upssched, and although it is correctly written and thus read by my script, it doesn't get updated when multiple UPSes are configured. To be more precise i'm monitoring 2 UPSes and using AT *EVENT* * *OPERATION* *handle *to manage events in upssched.conf. Am i wrong somewhere? I'm

Until the release of nut-2.0.5 it was possible to have a working configuration without configuring anything in 'ups.conf'. Since then, this no longer works, as the server will only look for driver sockets for UPSes that have been configured in 'ups.conf' (since the socket is named after the UPSname). Drivers will use the old naming scheme '<driver>-<port>' if

Here is patch 1 of 2. Roger diff -rup nut-2.7.4.orig/clients/upsmon.c nut-2.7.4.dev/clients/upsmon.c --- nut-2.7.4.orig/clients/upsmon.c 2015-12-29 13:08:34.000000000 +0100 +++ nut-2.7.4.dev/clients/upsmon.c 2016-07-01 09:46:21.567766415 +0200 @@ -525,6 +525,18 @@ static int get_var(utype_t *ups, const c numq = 2; } + /* Subcommands for polling SIGUSR1, SIGUSR2 RP */ + if (strcmp(var,

On Dec 14, 2013, at 4:19 AM, David C. Rankin wrote: > lsusb shows: > > Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS I am guessing that 'ls -l /dev/bus/usb/004/002' shows that the device node is not owned by the NUT gid? > Why doesn't > "upsdrvctl start" allow nut to find the UPS when it can find it without a > problem with

Hi Bj?rn, 2009/10/9 Bj?rn Torkelsson > Public bug reported: > > Binary package hint: nut > > I have recently upgraded from hardy to intrepid to jaunty. After > upgrading to Intrepid the megatec_usb stopped recognizing my Trust PW- > 4130M ups, it still does not work on Jaunty. It worked without any > problems in hardy. > > I tried the megatec_usb driver from hardy

So, got some good news: I hear(*) I managed to reproduce the problem with current NUT master and an adapted copy of your posted configs and script :D Experimental debugging now sounds possible. (*) PC under the desk wails with all its cooling fans as soon as I started the client which spawned a daemon and itself had exited: $ UPSNAME=heartbeat at localhost NOTIFYTYPE=ONBATT

So, got some good news: I hear(*) I managed to reproduce the problem with current NUT master and an adapted copy of your posted configs and script :D Experimental debugging now sounds possible. (*) PC under the desk wails with all its cooling fans as soon as I started the client which spawned a daemon and itself had exited: $ UPSNAME=heartbeat at localhost NOTIFYTYPE=ONBATT

Hi, Great work Jim! I?m glad you could reproduce the problem and found a potential culprit. Just for my own interest I restored upsshed from my backups (version 2.7.4-13) and it seems to running ok, so no big runtime changes regarding that with Debian 12. It is not hogging CPU. From the daemon log the heartbeat seems to be working ok. Only difference between the old logs (pre Debian 12 update)

Hi, Great work Jim! I?m glad you could reproduce the problem and found a potential culprit. Just for my own interest I restored upsshed from my backups (version 2.7.4-13) and it seems to running ok, so no big runtime changes regarding that with Debian 12. It is not hogging CPU. From the daemon log the heartbeat seems to be working ok. Only difference between the old logs (pre Debian 12 update)

Hello guys Yesterday i started do configure my Mustek Powermust650 with nut using the megatec_usb driver. Everything works fine except for the mailing when something happens. My upsmon looks like this: MONITOR powermust650 at localhost 1 local controller master MINSUPPLIES 1 SHUTDOWNCMD "/sbin/shutdown -h +0" NOTIFYCMD /root/upsmailer POLLFREQ 10 POLLFREQALERT 5 HOSTSYNC 15

On 12/14/2013 07:20 AM, Charles Lepple wrote: > On Dec 14, 2013, at 4:19 AM, David C. Rankin wrote: > >> lsusb shows: >> >> Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS > > > I am guessing that 'ls -l /dev/bus/usb/004/002' shows that the device node is > not owned by the NUT gid? > crw-rw-r-- 1 root root 189, 385 Dec

On 12/14/2013 12:37 PM, David C. Rankin wrote: > I will test with the new ubs dev permission and report back. Thank you for your > help Charles. Charles, Setting uid:gid to root:nut on /dev/bus/usb/004/002 seemed to be the issue. The question now become how to automate this process so that the user isn't required to manually hunt down the usb dev and change gid to the nut gid? So

So... determining that FD is to be reaped proved hard. Internet lore suggests fcntl() and poll() on the FD, but it just seems valid to them. The errno is also usually not raised (once I saw a "111: Connection refused" though). So the best dumb idea so far is to bail out if we spent the whole loop (128 attempts) and only got zero-sized read replies and no errors.

So... determining that FD is to be reaped proved hard. Internet lore suggests fcntl() and poll() on the FD, but it just seems valid to them. The errno is also usually not raised (once I saw a "111: Connection refused" though). So the best dumb idea so far is to bail out if we spent the whole loop (128 attempts) and only got zero-sized read replies and no errors.

On 12/16/2013 09:06 AM, Charles Lepple wrote: > If you want, we can take a look at the output of the aforementioned udevd > command from your system. Please compress the output, and if the list bounces > it, I'll extract the relevant portion from the bounce message. > > I have a funny feeling we might either have a Debian-specific dependency on > 91-permissions.rules, or