similar to: standardizing debug log levels [was: passing nut_debug_level from upsdrvctl to drivers]

Is there any reason why we couldn't pass the -D flags (counted by nut_debug_level) from upsdrvctl to the individual drivers? It seems a little strange to suggest to users that they should start the drivers with upsdrvctl normally, but then start them by hand for debugging. (If we want to debug upsdrvctl itself, we could use another flag for that, instead of -D.) -- - Charles Lepple

On Tue, Jan 27, 2009 at 04:39:13PM +0100, Arnaud Quette wrote: > Hi Kirill, > > 2009/1/27 Kirill Smelkov <kirr at mns.spb.ru> > > > On Tue, Jan 13, 2009 at 05:58:23PM +0300, Kirill Smelkov wrote: > > > Arjen, Arnaud, > > > first of all, I'm sorry for my late reply. > > > > > > If it's not too late, here is updated al175: >

(Arjen - I apologize if you get two copies, I sent the first one to the old de-korte.org address) Arjen, all, I've run into a usbhid-ups problem with nut on Arch Linux with the new 2.6.35 kernels. (latest is 2.6.35.4-1) For some reason when you get to the udev events on boot and it tries to load the usbhid-ups driver, it hangs until the 120 sec timeout occurs and then boot continues but

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()

In order to improve the diagnostics for serial connected devices, I would like to add the possibility to differentiate between errors and timeouts. For the ser_get_char() and ser_get_buf_len() we might do this by changing the return value. For the first, return value -1 would be an error, 0 a timeout and 1 success. The latter could return -1 on error, between 0 and (buflen-1) for a

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,

> ---------- Forwarded message ---------- > From: Arjen de Korte > To: nut-commits at lists.alioth.debian.org > Date: Mon, 27 Aug 2007 18:33:00 +0000 > Subject: svn commit r1076 - in trunk: . drivers > Author: adkorte-guest > Date: Mon Aug 27 18:33:00 2007 > New Revision: 1076 > > Log: > * drivers/libhid.[ch],libshut.[ch],libusb.[ch]: > - Cut the libshut and

2010/12/22 Arjen de Korte <adkorte-guest at alioth.debian.org> > Author: adkorte-guest > Date: Wed Dec 22 20:31:42 2010 > New Revision: 2777 > URL: http://trac.networkupstools.org/projects/nut/changeset/2777 > > Log: > Don't version generated files > > Deleted: > trunk/scripts/hal/ups-nut-device.fdi.in > trunk/scripts/hotplug/libhid.usermap >

Hi Kirill, just to notify you that your al175 driver is being removed from the NUT tree, as of 2.4.0-pre1. if you wish to see it entering the tree again, please contact the Development mailing list to talk about it. Merry Christmas and happy New Year. Arnaud -- Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops Network UPS Tools (NUT) Project Leader -

Sorry for a bit longer delay than I anticipated, I was stuffed with the work. This is the next iteration of the patch adding some functionality to apcsmart driver, and relying on 'ignorelb' recently added. Follow up from previous thread: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02331.html Main differences is that V3 is split into many small patches, so the

This patch introduces a handful of new options, I mentioned earlier in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02088.html See the large commit message in the follow-up for the details and rationale. I realize it's a bit larger diff - so if it's required I can split it into few smaller ones. Michal Soltys (1): APC smart driver update and new features.

Hi, In Red Hat /etc/init.d/halt script, it expects upsdrvctl to be in /sbin rather than /bin which sounds normal considering the power of that command. If I move this file to sbin, this is what I get when invoking it: [root@serveur1.sassine.eu nut-2.0.5]# mv /bin/upsdrvctl /sbin/ [root@serveur1.sassine.eu nut-2.0.5]# which upsdrvctl /sbin/upsdrvctl [root@serveur1.sassine.eu nut-2.0.5]#

Le 23/06/2011 14:00, nut-upsuser-request at lists.alioth.debian.org a ?crit : > Send Nut-upsuser mailing list submissions to > nut-upsuser at lists.alioth.debian.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser > or, via email, send a message with subject or body 'help' to >

This is 2nd version of the earlier patch featuring a few new features and fixes to the apcsmart driver, following the remarks in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02294.html Major changes from v1: - handle battery.charge and battery.runtime checks at main.c level - handle "immutable but writable" conflict gracefully at driver level -

Hi again, it seems to me that "upsdrvctl shutdown" fails to pass the "-u" flag to the driver. See drivers/upsdrvctl.c:shutdown_driver(), and compare to start_driver() in the same file. This has been so since ancient history (I checked back to 1.5.0), so there must be a reason, but I can't think of any. I have a good reason for passing "-u root": at the time

Arjen de Korte wrote: > > * drivers/libhid.c: > - The 'exact' matcher now also matches the Bus too (this won't > change as long as the USB plug is not removed). If you don't like > this, use the 'regex' matcher instead. Ooh, I don't like this last one at all. One of the main reasons a device might get disconnected is that the user physically unplugs it

Per the message printed by upsdrvctl: upsdrvctl start Network UPS Tools - UPS driver controller 2.6.3 Network UPS Tools - Generic HID driver 0.35 (2.6.3) USB communication driver 0.31 This TrippLite device (09ae:3016) is not (or perhaps not yet) supported by usbhid-ups. Please make sure you have an up-to-date version of NUT. If this does not fix the problem, try running the driver with the

I can run "upsdrvctl start" and it starts fine. On computer boot, however, it doesn't start properly. I'm trying to find the logs which would give more detail, but I'm not sure where they are. I see no logs in /etc/nut or /var/log. I don't know if this helps, but it looks like there's a problem with the PID file generation: when I run "upsdrvctl stop"

The change of the PID file names for the drivers causes some problems when upgrading from a previous version of NUT. The new 'upsdrvctl' will not be able to find the PID from drivers started by a previous version (since it looks for the new names only). To prevent shooting ourselves in the foot when upgrading, I slapped together a 'status' function in 'upsdrvctl' to see

I did a test shutdown on a nut controlled UPS and it all went as expected except that when it got to: /usr/local/ups/bin/upsdrvctl shutdown Nothing happened. So the halt script went on and shut down the system. I waited a while but the UPS never turned itself off. Am I doing something wrong, or does this UPS not support this function? Thank you, David Mathog mathog at caltech.edu Manager,