similar to: Changes to 'upsdrvctl'

Using the HOWTO in http://keystoneit.wordpress.com/2006/09/25/network-ups-tools-nut-on-ubuntu/ I installed nut on an Ubuntu Edgy LAMP Server with an Eaton Powerware 5110 attached to it via usb. But nut fails to start properly (see the error message "Starting Network UPS Tools: (upsdrvctl failed) upsd upsmon" below). It then complains about communication with the UPS being lost ("UPS

On Jan 27, 2008 11:07 AM, Arjen de Korte <nut+devel at de-korte.org> wrote: > > >> I also think we should not encourage people to post debug output before > >> consultation with a developer. Most of the time, providing useful debug > >> output requires more than just running the driver with an arbitrary > >> number of -D flags anyway. > > Well,

Currently, the 'upsd' server uses 'ups.conf' to find out which drivers should be running and uses this information to construct the socketname it needs. This means that drivers that have not been configured in 'ups.conf' can never be seen by the server. If we ever want to autodetect (by whatever means) what drivers are started (udev?) and we start them automatically, this

All, I have built and installed nut from git on Archlinux. It uses the usbhid driver. Beginning a couple of years ago, nut begin failing to run on Archlinux without 'tweaking' or 'fudging' the install. There are two primary problems: (1) upsdrvctl cannot be launched normally i.e. (/usr/sbin/upsdrvctl start) without failing to connect: Dec 14 02:24:39 phoinix systemd[1]:

On 12/14/2013 02:06 PM, David C. Rankin wrote: > 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 > far, either manually setting the gid or hand-rolling the udev files to do the

Just installed version 2.2.1 and have the same problem reported in this chain. I have Mandriva Linux 2008.1 with a Tripplite USB 500 no break. When I start the upsdrvctl I get the "Startup timer elapsed, continuing..." message and then a upsd can't connect error. I copied the file usbhid-ups from version 2.2.0 from another Mandriva system and everything works fine now. Its not

Hi Arjen, in server/upsd.c r731, you moved the call conf_load() from after check_perms() (~ l.1020) to before setupsignals() (~ l.989). The problem is that conf_load() needs to open the ups driver socket, and it assumes that STATEPATH is the current working directory. The directory is only set in l.1016. Therefore, the first attempt to open a socket will always fail. From the user's point of

Hello, We have a Tripplite SMART1500RMXL2U and nut-2.2.0-6.el5 installed on Centos 5.3. I've been unsuccessful on getting upsmon to work. usdrvctl seems to start despite some warnings/errors: # upsdrvctl start smart1500 Network UPS Tools - UPS driver controller 2.2.0- Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.11.1 (2.2.0-) Warning: This is an experimental driver. Some

2006/11/16, Arjen de Korte <adkorte-guest@alioth.debian.org>: > Author: adkorte-guest > Date: Thu Nov 16 21:16:40 2006 > New Revision: 585 > > Modified: > trunk/ChangeLog > trunk/conf/upsd.conf.sample > trunk/server/conf.c > trunk/server/upsd.c > trunk/server/upsd.h > Log: > upsd: add MAXINIT parameter to upsd.conf to make the time upsd

Charles, All, Arjen (if he is still kicking), I have run CyberPower ups's with NUT for a number of years, and aside from newer model voltage scaling, etc.., the usbhid driver installs have always just worked. I ended up with another CP UPS and installed 2.7.4-5 from the AUR package for Arch. As soon as I plugged the UPS in, it was found instantly, so I expected no problems with the

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

Hi, one user found problem with restarting nut. upsdrvctl does not wait for drivers being really terminated. In init scripts we have following: killproc upsmon killproc upsd upsdrvctl stop and then upsdrvctl start upsd upsmon problem is upsdrvctl stop only sends terminating signals but does not wait for driver termination. This makes driver fail to start sometimes when old driver is still

Great, thanks Arjen! Now we need an autoconf test to set HAVE_IPV6 automatically. I will look into what functionality needs to be tested; the test can be refined as problems arise later. -- Peter Arjen de Korte wrote: > > Author: adkorte-guest > Date: Sat Jan 6 19:39:08 2007 > New Revision: 710 > > Modified: > trunk/ChangeLog > trunk/clients/upsc.c >

I'll be back one more time perhaps I found the reason of these errors Nov 13 11:09:22 mezenc upsmon[3865]: Poll UPS [mgeups at localhost] failed - Data stale it happens when daemon upsd et upsmon are started after the boot obviously, there isn't any errors when upsd and upsmon are started at boot following later ... -----Message d'origine----- De : goudard sabine Envoy? : mardi

With the Ipv6 patch (r708), I get: upsclient.c: In function `upscli_connect': upsclient.c:469: `AI_ADDRCONFIG' undeclared (first use in this function) upsclient.c:469: (Each undeclared identifier is reported only once upsclient.c:469: for each function it appears in.) Even if it doesn't break IPv4 support, it may break portability, as IPv6 seems to require specific functions that are

While browsing the sources of the nss-ssl-port sources I noticed that client certificates were added. What is the reason behind this? As far as I can see, using a server certificate and validating it in the upsmon client should provide us with a secure channel. Authorizations for the server will then be handled by the settings in upsd.users by logging into the server with user and

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

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

I think I have found a way to deal with the issue of the spurious message on startup of NUT. Before implementing it, I would like to see what the other developers think of this idea. My proposal is not to wait for DUMPDONE in the startup of upsd for a duration of MAXINIT seconds, but rather to send the fake "INIT" status in response to a ups.status request. As soon as DUMPDONE hits, or

> Feature Requests item #310492, was opened at 07/01/2008 09:57 > Status: Open > Priority: 3 > Submitted By: Arnaud Quette (aquette) > Assigned to: Nobody (None) > Summary: Allow to specify hostnames in ACL (upsd.conf) > Category: None > Group: None > > > Initial Comment: > allow a new ACL form: > ACL hostname/mask > > example: > ACL localhost