Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On Monday 03 April 2017 16:39:30 Stuart D. Gathman wrote: > On Mon, 3 Apr 2017, Gene Heskett wrote: > >>> Nut, IIRC, can do a periodic battery test by putting it offline, > >>> using the battery, for a predetermined length of time, weekly, > >>> monthly etc, > >> > >> We definitely don't want that in this instance either! > > > > Why not? If the battery has a holdup time of 5 minutes when its > > fresh, > > Because in this instance it crashes your system, corrupts filesystems, > etc, etc. > But it does that because you have tried to get 12 years out of a gell cell battery that is doing really really well if you get 4 years out of it. I am not saying you should do that _now_, without first replacing that thoroughly boiled dry battery, but as something you should set it up to do once you have a serviceable battery set installed in it. That way, you would be getting warnings before this replacement battery is deep into its failure. THIS is how you best prevent these surprise failures that are probably causing recovery nightmares and lost profit opportunities because of the downtime. A good manager isn't the one who spends less money, thinking it improves the P report. He is the one who spends the money wisely to maintain as close to 100% uptime as he can. Do that, and the P report will take care of itself. > >> We want the ALARM that the nut driver is > >> generating, and upsd is passing on - to be acted on in some way by > >> upsmon. Which NOTIFYCMD is run when there is an ALARM? Have you specified that in your upsmon.conf? And have you verified that the resources it needs to send that warning message are available on your systems? See man wall and test the default. You will have to compose a one line file, and name that file in order to send the contents of that file to users. Create that file: echo "I need a fresh battery" >rplbat. Then do wall rplbat and get this on every screen on the system: gene@coyote:~$ sudo wall rplbat Broadcast Message from gene@coyo (/dev/pts/2) at 18:56 ... I need a fresh battery Which can be embellished by naming the ups that needs the battery I believe. Now, I'll bow out and let the nut maintainers advise from here. I am just a happy nut user trying to help. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On Monday 03 April 2017 14:13:08 Stuart D. Gathman wrote: Back on the mailing list, where such belongs. > On Mon, 3 Apr 2017, Gene Heskett wrote: > > Nut, IIRC, can do a periodic battery test by putting it offline, > > using the battery, for a predetermined length of time, weekly, > > monthly etc, > > We definitely don't want that in this instance either! Why not? If the battery has a holdup time of 5 minutes when its fresh, and a downtime of 30 seconds takes it down .2 volts, it can and will stand a weekly 30 seconds on battery test once a week for 2 or 3 years, which is about the life of a jellcell anyway, the point being that if at the end of that 30 second test, the battery is down say .5 volts, its time visit your version of batteries.com and get another set headed your way. > (Unless it is > a dual PS server.) Which quite likely will not load the battery significantly as it will draw power from the highest voltage source, usually the powerline. > We want the ALARM that the nut driver is > generating, and upsd is passing on - to be acted on in some way by > upsmon. Which NOTIFYCMD is run when there is an ALARM? I've not read the docs in ages, but if there isn't something mentioned in a man upsmon, I would be unpleasantly surprised. According to my copy, it does a -wall (warn all) by default, and it looks like REPLBATT is one such message, and the default time for a repeat is 12 hours. The -wall type message shows on every open terminal on the system's network, so someone should see it. From the upsmon.conf file: NOTIFYCMD command upsmon calls this to send messages when things happen. This command is called with the full text of the message as one argument. The environment string NOTIFYTYPE will contain the type string of whatever caused this event to happen. If you need to use upssched(8), then you must make it your NOTIFYCMD by listing it here. Note that this is only called for NOTIFY events that have EXEC set with NOTIFYFLAG. See NOTIFYFLAG below for more details. Making this some sort of shell script might not be a bad idea. For more information and ideas, see pager.txt in the docs directory. Remember, this command also needs to be one element in the configuration file, so if your command has spaces, then wrap it in quotes. NOTIFYCMD "/path/to/script --foo --bar" This script is run in the background—that is, upsmon forks before it calls out to start it. This means that your NOTIFYCMD may have multiple instances running simultaneously if a lot of stuff happens all at once. Keep this in mind when designing complicated notifiers. NOTIFYMSG type message upsmon comes with a set of stock messages for various events. You can change them if you like. NOTIFYMSG ONLINE "UPS %s is getting line power" NOTIFYMSG ONBATT "Someone pulled the plug on %s" Note that %s is replaced with the identifier of the UPS in question. Note that %s is replaced with the identifier of the UPS in question. The message must be one element in the configuration file, so if it contains spaces, you must wrap it in quotes. NOTIFYMSG NOCOMM "Someone stole UPS %s" Possible values for type: ONLINE UPS is back online ONBATT UPS is on battery LOWBATT UPS is on battery and has a low battery (is critical) FSD UPS is being shutdown by the master (FSD = "Forced Shutdown") COMMOK Communications established with the UPS COMMBAD Communications lost to the UPS SHUTDOWN The system is being shutdown REPLBATT The UPS battery is bad and needs to be replaced NOCOMM A UPS is unavailable (can’t be contacted for monitoring) NOTIFYFLAG type flag[+flag][+flag]... By default, upsmon sends walls global messages to all logged in users) via /bin/wall and writes to the syslog when things happen. You can change this. Examples: There is more in that file than what I've quoted here. Recommended reading. But unless you actually do the weekly or even monthly, short "on battery" test, its not likely you will ever see a replace batteries message because I don't think that flag sets set by a power failure that takes you down. Not time enough to set the flag. The TANSTAAFL principle applies here, same as everyplace else. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http:/
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On Monday 03 April 2017 11:41:56 Jon Bendtsen wrote: > On 03/04/17 17.24, Roger Price wrote: > > On Mon, 3 Apr 2017, Jon Bendtsen wrote: > >> On 03/04/17 17.10, Roger Price wrote: > >>> On Mon, 3 Apr 2017, Jon Bendtsen wrote: > >>>> Power seem to be lost immediately. > >>>> But my APC Smart-UPS 1500 always reported everything OK. > >>>> battery.charge : 100 > >>> > >>> ... > >>> > >>>> battery.mfr.date : 2005/08/26 > >>> > >>> Hi, Could you confirm that the battery is nearly 12 years old? > >>> Roger > >> > >> yeah, it most likely is that old > > > > That's probably the cause of the immediate power loss. A new > > battery should fix the problem. Roger > > yeah a new battery will most likely make it go away. However, that is > not why I wrote the email. I wrote the email because I want NUT to > tell me much more clearly that something is wrong, and NUT currently > does not do that. > > > > JonB > Nut, IIRC, can do a periodic battery test by putting it offline, using the battery, for a predetermined length of time, weekly, monthly etc, and IIRC recording the battery voltage just as it switches back to line power. The comparative voltage level at the switchback point is a pretty good indication of the battery condition, and I think that could be used to trigger an "I need a new battery" email message well ahead of an unexpected total fail shutdown. I have a 20kw nat gas fired standby generator thats typically live in 5 seconds since the Mrs. has COPD, so I have never set that up here, but I believe you can find that in the Nut docs. Unless its been elided in the last 15 years. :( Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] unexpected shutdown, had to reinstall xorg.server
Greetings all; I expect that I may not have the shutdown properly configured, but my site was subjected to some bad weather related intermittent power losses a week+ back, and I have an automatic standby plant, a 20kw, that usuall fires up and has the lights back on in 7 or 8 seconds. So while the power folks were reclosing substation breakers to see where the next tree limb was shorting things out, the standby was shut down and then restarted quickly 3 or 4 times. Somewhere in all the bounces, the UPS, a belkin, shut off its AC input without making any advise me noise in the logs, which I was tailing at that point. The net result being that I've had commercial power for 10 minutes or so and I am replying to an email message when click and the whole system is dead from a low battery shutdown. So why did the ups do a powerdown? Restarting the UPS with a long push on its power button was done, and I expected a normal reboot to bring things back to life. Wrong... No X, and virtual crickets in the logs. Actually no xorg.0.log. /usr/bin/X nowhere to be found. Pointed shotgun at apt-get install --reinstall xorg./server* and it reinstalled 34 packages. sudo reboot and it was back to the usual everything starts on the same screen & has to be moved to put it on the screens I am used to mess. This is a debian wheezy based install, and the system drive is ext4, and the 2nd drive is ext3, for amanda's use as backup medium using virtual tapes. I should probably make that one an ext4 drive also. Just never found my round tuit. A upsd -V says 2.6.4 which is pretty ancient by now. Whats the best way to proceed to avoid this in the future? As an aside, neither of the /etc/nut/*.html files will display the ups status, displaying the source text in place of the values expected. Configuration error? Main man page for describing that plz. However a "upsc myups" shows the expected results. I've asked several questions. Hopefully they all have an answer. Thanks all. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] unexpected shutdown, had to reinstall xorg.server
Greetings all; I expect that I may not have the shutdown properly configured, but my site was subjected to some bad weather related intermittent power losses a week+ back, and I have an automatic standby plant, a 20kw, that usuall fires up and has the lights back on in 7 or 8 seconds. So while the power folks were reclosing substation breakers to see where the next tree limb was shorting things out, the standby was shut down and then restarted quickly 3 or 4 times. Somewhere in all the bounces, the UPS, a belkin, shut off its AC input without making any advise me noise in the logs, which I was tailing at that point. The net result being that I've had commercial power for 10 minutes or so and I am replying to an email message when click and the whole system is dead from a low battery shutdown. So why did the ups do a powerdown? Restarting the UPS with a long push on its power button was done, and I expected a normal reboot to bring things back to life. Wrong... No X, and virtual crickets in the logs. Actually no xorg.0.log. /usr/bin/X nowhere to be found. Pointed shotgun at apt-get install --reinstall xorg./server* and it reinstalled 34 packages. sudo reboot and it was back to the usual everything starts on the same screen & has to be moved to put it on the screens I am used to mess. This is a debian wheezy based install, and the system drive is ext4, and the 2nd drive is ext3, for amanda's use as backup medium using virtual tapes. I should probably make that one an ext4 drive also. Just never found my round tuit. A upsd -V says 2.6.4 which is pretty ancient by now. Whats the best way to proceed to avoid this in the future? As an aside, neither of the /etc/nut/*.html files will display the ups status, displaying the source text in place of the values expected. Configuration error? Main man page for describing that plz. However a "upsc myups" shows the expected results. I've asked several questions. Hopefully they all have an answer. Thanks all. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT support for APC BackUPS Pro 900VA
On Thursday 21 January 2016 17:36:15 Juergen Edner wrote: > Hi all, > I'm trying to configure Nut to connect to an APC BackUPS Pro 900VA. > This ups uses a serial port on which _simple_ or _smart_ signaling > should be spoken. I've connected the UPS to a serial port using the > original 940_0128A cable from APC. > Unfortunately I've not yet managed to read any data from the ups. > If I try to load the apcsmart driver it tells me that it cannot > communicate with the ups. > > Does anyone be able to configure Nut so that the mentioned BackUPS > is recognized properly. If someone could give me a hint how I need > to configure nut, I would appreciate it. > > Just to mention, Nut is already working with older SmartUPS devices > without any problems. So it isn't a general but a device specific > problem. > > Thank you in advance! > > Regards > Juergen This might not be helpfull, but is udev now setting the permissions on that serial port restrictive enough that nut cannot use it? After heyu was refused at midnight 1/1/16 when I have a cron job upload the next years schedule for some lights on the front deck, I found /dev/ttyUSB0 was set to root:root for ownership, and 0700 permissions. Meaning only root could use it. I just had a similar situation using heyu on /dev/ttyUSB0. I could not find the udev rule that had changed it, so I took the next best route, got root and put a chmod and a chown of that port in my /etc/rc.local file, which runs last at bootup. And heyu is once again a happy camper. This might not be your problem, but its something to check. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] access to upsrw
On Tuesday 29 December 2015 17:25:46 Charles Lepple wrote: > On Dec 29, 2015, at 3:27 PM, Gene Heskett <ghesk...@wdtv.com> wrote: > > Greetings Charles; > > > > I hope you had a nice Christmas, and will have a happy and > > prosperous new year in 2016. > > Hi Gene, > > Thanks, and same to you! > > > You mentioned upsrw in a message earlier, so I ran it, and found the > > shutdown timeout was only 20 seconds. > > ... > > > So I tried to reset that to 120 seconds, which the battery can do > > nicely, and I have a 20kw in the back yard that is up and running, > > lights back on in 16 or 17 seconds, so is 98% moot, but found I > > cannot, even as root, adjust this. > > > > gene@coyote:~$ upsrw -s ups.delay.shutdown=120 myups > > Username (gene): gene > > Password: my user pw here > > Unexpected response from upsd: ERR ACCESS-DENIED > > See "man upsrw" or > http://www.networkupstools.org/docs/man/upsrw.html#_diagnostics > > > Nut was never given a pw on this system. I, and ups however are > > members of group nut, and that has always seemed sufficient until > > now. > > Why it defaults to the username of the logged-in user is beyond me, > and lost in the history of NUT. It's tempting to change that Username > message to at least point out that the username is being looked up in > upsd.users. Since NUT typically drops root privileges early, it makes > it complicated to use the system password file (especially on systems > like Ubuntu where /etc/shadow is only readable by root). > > However, back to your original goal of changing the shutdown delay: > the "upsrw" command seems to have been designed for UPSes like the > original APCs that stored settings in an EEPROM. I don't think many of > the newer USB-based UPSes have a similar EEPROM (or maybe we override > that), but the upsrw settings for the usbhid-ups driver (assuming you > are still using the Belkin UPS you mentioned previously) are not > permanent. > > I think you want to set "offdelay = 120" (and "ondelay = 150" or so) > in /etc/nut/ups.conf to allow two minutes between NUT starts the > shutdown, and when the UPS finally cuts power. Thanks Charles. I saw a couple other things I changed, but the help above shows in upsrw that it has been changed. So we'll have to see how it goes if I am present at the next power fail event. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] access to upsrw
Greetings Charles; I hope you had a nice Christmas, and will have a happy and prosperous new year in 2016. You mentioned upsrw in a message earlier, so I ran it, and found the shutdown timeout was only 20 seconds. gene@coyote:~$ upsrw myups [input.transfer.high] High voltage transfer point (V) Type: STRING Value: 140 [input.transfer.low] Low voltage transfer point (V) Type: STRING Value: 88 [ups.delay.shutdown] Interval to wait after shutdown with delay command (seconds) Type: STRING Value: 20 [ups.delay.start] Interval to wait before (re)starting the load (seconds) Type: STRING Value: 30 That 20 seconds is insufficient to allow a gracefull shutdown on this system as it seems to need 40 or more seconds to begin a reboot by entering the BIOS post routine. So I tried to reset that to 120 seconds, which the battery can do nicely, and I have a 20kw in the back yard that is up and running, lights back on in 16 or 17 seconds, so is 98% moot, but found I cannot, even as root, adjust this. gene@coyote:~$ upsrw -s ups.delay.shutdown=120 myups Username (gene): gene Password: my user pw here Unexpected response from upsd: ERR ACCESS-DENIED Nut was never given a pw on this system. I, and ups however are members of group nut, and that has always seemed sufficient until now. Obviously I don't have something adequately configured, the question of course is what? Thanks. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Need the date included in nuts -wall msgs.
Greetings all; Is it possible to set a logging option in one of the config files so that when we have a 1 second power bump, the date is included, both in the log, and in the -wall broadcast? We apparently have a substation regulator in the process of failing, and the recycle isn't normally slow enough to reset the clocks, but it killing one of my computers w/o actually causing a reboot. And I need to be able to quote bible and verse to the local electron peddlars in order to get them to service the failing piece of gear. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Need the date included in nuts -wall msgs.
On Tuesday 18 August 2015 09:50:32 Charles Lepple wrote: On Aug 18, 2015, at 3:27 AM, Gene Heskett ghesk...@wdtv.com wrote: Greetings all; Is it possible to set a logging option in one of the config files so that when we have a 1 second power bump, the date is included, both in the log, and in the -wall broadcast? Hey Gene, The syslog entry should have one-second resolution in the timestamps, and you could use the EXEC option in NOTIFYFLAG in upsmon.conf to call your own script on the ONBATT and ONLINE events (which would allow you to pass whatever message you want to wall). The syslog does not date that specific event: == UPS myups@localhost on battery Aug 12 22:56:10 coyote kernel: [432322.384570] usb 1-1.4.1: new high-speed USB device number 14 using ehci_hcd Aug 12 22:56:10 coyote kernel: [432322.494061] usb 1-1.4.1: New USB device found, idVendor=04f9, idProduct=0053 Aug 12 22:56:10 coyote kernel: [432322.494065] usb 1-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Aug 12 22:56:10 coyote kernel: [432322.494068] usb 1-1.4.1: Product: HL-3170CDW series Aug 12 22:56:10 coyote kernel: [432322.494071] usb 1-1.4.1: Manufacturer: Brother Aug 12 22:56:10 coyote kernel: [432322.494073] usb 1-1.4.1: SerialNumber: U63478A3J114945 Aug 12 22:56:10 coyote kernel: [432322.495101] usblp0: USB Bidirectional printer dev 14 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0053 Aug 12 22:56:10 coyote mtp-probe: checking bus 1, device 14: /sys/devices/pci:00/:00:02.1/usb1/1-1/1-1.4/1-1.4.1 Aug 12 22:56:10 coyote mtp-probe: bus: 1, device: 14 was not an MTP device Broadcast Message from nut@coyo (somewhere) at 22:56 ... UPS myups@localhost on line power === But it bumps the printer just long enough to generate the above entries. And that pops up a bogus advisory that it cannot find the drivers for it. I cannot put that printer on the 1500 WA UPS, as its drum heaters kicking in at the start of a job or at power up, cause the UPS to do an instant, protective shutdown. But these bumps are so short the printer does not forget its turned on, but does trigger a re-init cycle. However, for a one-second glitch, many of the NUT drivers might miss that in their polling cycle. (This usually isn't a problem, since an UPS with a good battery should be able power the load for much longer than one poll interval.) This is one of the few cases where a dumb contact-closure UPS and a dedicated serial port monitor program might be a better fit. Which driver(s) are you using? Its a Belkin, ups.conf:driver=usbhid-ups. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New batteries and another attempt to get nut running
On Sunday 01 March 2015 19:16:47 Charles Lepple wrote: On Sun, Mar 1, 2015 at 2:23 PM, Gene Heskett ghesk...@wdtv.com wrote: Hi Charles; I hope this finds you well. Hi Gene, Here is dmesg output: gene@coyote:~$ dmesg |grep Belkin [3.315667] usb 2-3: Product: Belkin UPS [3.315669] usb 2-3: Manufacturer: Belkin [4.084258] generic-usb 0003:050D:0751.0009: hiddev0,hidraw4: USB HID v1.11 Device [Belkin Belkin UPS] on usb-:00:02.0-3/input I have configured it to use this generic-usb, Configured NUT, udev, or the kernel? Udev kernel are as installed except for the renumbering of the udebv rule, since reverted. (For most Linux distributions on PC hardware, the stock kernel should work, since NUT can kick out the hiddev and hidraw drivers at runtime.) and probably made it less secure by adding myself to /etc/group/nut and changing many of the perms to 0660 or 0664 so I can edit this stuff as me. Those of course are fixable later if needed. But I use dd-wrt here, and no one has ever succeeded in getting past it to do anything but look and dl from my web page (in sig) Just to be clear, the UPS is directly connected to the Debian wheezy box you mentioned before, correct? (This seems to have a much higher chance of success than dd-wrt, since the USB drivers for non-PC systems seem to be lacking in general.) Yes, plugged into a usb2 port on this machine. Then I setup some defaults as I can sort of recall them from previous setups. Stepping into /etc/init.d and doing this, isn't getting me there according to the response: gene@coyote:/etc/init.d$ sudo ./nut-server restart [ ok ] Restarting NUT - power devices information server and drivers: upsd (driver(s) failed) (driver(s) failed). upsd. However: gene@coyote:/etc/init.d$ ps axu|grep nut nut 31366 0.0 0.0 2256 524 ?Ss 14:01 0:00 /sbin/upsd gene 31740 0.0 0.0 3488 764 pts/6S+ 14:09 0:00 grep nut says upsd is running. From that I get that generic-usb is the wrong driver. The generic-usb driver name seems to be coming from the kernel. It is somewhat disconnected from the NUT driver names, though. Unfortunately, Debian suppresses all the useful diagnostic messages. Since the driver failed to start, you can try starting it with the NUT-specific 'sudo /sbin/upsdrvctl start', which will show startup messages. Based on the USB IDs in the kernel message (the 050D:0751, which is what lsusb would print), the NUT driver I think you are looking for is usbhid-ups. More better: gene@coyote:/etc/nut$ sudo /etc/init.d/nut-server restart [ ok ] Restarting NUT - power devices information server and drivers: upsd (driver(s) failed) driver(s). upsd. gene@coyote:/etc/nut$ sudo /etc/init.d/nut-server stop [ ok ] Stopping NUT - power devices information server and drivers: upsd driver(s). gene@coyote:/etc/nut$ sudo /sbin/upsdrvctl start Network UPS Tools - UPS driver controller 2.6.4 Network UPS Tools - Generic HID driver 0.37 (2.6.4) USB communication driver 0.32 Using subdriver: Belkin HID 0.15 And that looks a lot more promising. Stop that, and restart nut-server, no errors this time. And gene@coyote:/etc/nut$ upsc myups@localhost battery.charge: 100 battery.charge.low: 30 battery.charge.warning: 30 battery.runtime: 120 battery.type: PbAc battery.voltage: 27.8 battery.voltage.nominal: 24 device.mfr: Belkin device.model: Belkin UPS device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyUSB0 driver.version: 2.6.4 driver.version.data: Belkin HID 0.15 driver.version.internal: 0.37 input.frequency: 60.0 input.frequency.nominal: 60 input.transfer.high: 140 input.transfer.high.max: 144 input.transfer.high.min: 140 input.transfer.low: 88 input.transfer.low.max: 88 input.transfer.low.min: 84 input.voltage: 123.8 input.voltage.nominal: 120 output.frequency: 59.9 output.voltage: 124.1 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.firmware: 1 ups.load: 21 ups.mfr: Belkin ups.model: Belkin UPS ups.power.nominal: 1500 ups.productid: 0751 ups.serial: ups.status: OL CHRG ups.test.result: No test initiated ups.timer.shutdown: 0 ups.timer.start: 0 ups.type: offline ups.vendorid: 050d So thats working now. Next, upsmon friends so I can look at it in iceweasal or ? If that works, we can try to tweak the text in the HCL, so that it is easier to look up based on the markings on the UPS: Which, despite my shaving it with a strong LED flashlight looking for bumps that resemble text in that black on black environment. I can't find a model number on it. Except for a previous battery change maybe 3 years ago, its been sitting there, with me generally ignoring it for at least 6 years now. HCL? Not a familiar acronym to me. Ah, the link. http://www.networkupstools.org/stable-hcl.html
[Nut-upsuser] New batteries and another attempt to get nut running
Hi Charles; I hope this finds you well. Here is dmesg output: gene@coyote:~$ dmesg |grep Belkin [3.315667] usb 2-3: Product: Belkin UPS [3.315669] usb 2-3: Manufacturer: Belkin [4.084258] generic-usb 0003:050D:0751.0009: hiddev0,hidraw4: USB HID v1.11 Device [Belkin Belkin UPS] on usb-:00:02.0-3/input I have configured it to use this generic-usb, and probably made it less secure by adding myself to /etc/group/nut and changing many of the perms to 0660 or 0664 so I can edit this stuff as me. Those of course are fixable later if needed. But I use dd-wrt here, and no one has ever succeeded in getting past it to do anything but look and dl from my web page (in sig) Then I setup some defaults as I can sort of recall them from previous setups. Stepping into /etc/init.d and doing this, isn't getting me there according to the response: gene@coyote:/etc/init.d$ sudo ./nut-server restart [ ok ] Restarting NUT - power devices information server and drivers: upsd (driver(s) failed) (driver(s) failed). upsd. However: gene@coyote:/etc/init.d$ ps axu|grep nut nut 31366 0.0 0.0 2256 524 ?Ss 14:01 0:00 /sbin/upsd gene 31740 0.0 0.0 3488 764 pts/6S+ 14:09 0:00 grep nut says upsd is running. From that I get that generic-usb is the wrong driver. I tried to use usbview to determine the correct driver, but it says none of the stuff it needs is compiled into this 3.4-9-amd64 kernel. So how to I best proceed thru this cornfield maze of getting a functional install? Thanks Charles. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 [driver selection and starting]
On Friday, February 20, 2015 08:40:50 AM Charles Lepple wrote: On Feb 19, 2015, at 11:23 PM, Gene Heskett ghesk...@wdtv.com wrote: Almost $800 dollars and worthless on wheezy. I am asking a few ?? over that on their mailing list as it worked perfectly on ubuntu-10.04.4 LTS. If you still have a backup of /etc from the Ubuntu install, there might be some clues in /etc/cups about the duplex settings (or which drivers support duplex, more likely). My printer is still chugging along from the grad school days where I didn't have nearly that much to spend on a printer, so I tend to do the manual duplex method: print odd-numbered pages, flip the stack over, make a sacrifice to the gods of static electricity, and print the even pages. I don't even know if I am using the correct driver, the ups-scanner seems only to exist in my 2.7.2 src tree, but its not installed as its looking for a much older libssl than I now have. I can't say I really buy into the nut-scanner notion. For the amount of work that went into it, I feel that we could have written some better procedural documentation that would have worked with whatever tools were on hand. And I don't think it's capable of saying try this driver, but if that doesn't work, here are the older ones that might also work. So let's do it the manual way. Brand name? Any vendor-included software that is currently being used as a beverage coaster? USB or serial? If USB, what does lsusb say about it? (Might have to run lsusb as root, if the udev permissions are working as intended.) See previous post for dmesg report, Belkin something or other, here's a fresh copy: [4.242066] usb 2-3: Product: Belkin UPS [4.242069] usb 2-3: Manufacturer: Belkin [4.336423] usb 1-2.3: new full-speed USB device number 8 using ehci_hcd [4.453420] usb 1-2.3: New USB device found, idVendor=0403, idProduct=6001 [4.453425] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 And the error messages from an attempted start are so generic they aren't a lot of help. So and so didn't start, but no reason why is given. Don't laugh, but there are two levels of indirection between /etc/init.d/nut-server and the driver. There's the init script itself, and upsdrvctl. Both were optimized for starting several drivers. We probably should be more explicit in the documentation about the possibility of starting the drivers manually at first (or using upsdrvctl -D, with the appropriate number of -Ds to print the driver name). Once the driver works on its own (and you can add -D to that command line to get more detail), you can kill the driver (important) and either try upsdrvctl or jump straight to the init.d script. After mv'ing that file, I still get: root@coyote:/etc/init.d# ./nut-server start [ ok ] Starting NUT - power devices information server and drivers: (driver(s) failed). upsd. Why can it not name the failed driver, so I would know to try another? The debian maintainers switched to systemd from the init.d scripts, Wheezy is still using init.d for 99% of it. and that caused a release-critical bug in the Debian package of NUT for new installations. (Upgrades from pre-systemd days just worked, but if NUT was not configured yet, the post-install script would error out.) They were not willing to drop back to the init.d compatibility wrappers (which I think Ubuntu is still using) so I don't know if NUT is even going to make it into jessie, the release after wheezy. So that doesn't really answer your question, but it should explain a bit of the mess behind the init scripts. (And at the same time, we have been trying to coordinate a release of NUT 2.7.3.) If you have a github account, I would recommend creating an issue so that we don't forget about printing the driver name(s) at startup: https://github.com/networkupstools/nut/issues I don't have one of those critters, Charles. (The combination of cold temperatures and a recent power outage seems to have taken out the one UPS in the house that I can't easily replace without voiding warranties: the DC supply for the broadband connection. While pairing a bluetooth keyboard to a smartphone works for the occasional email, the screen is a bit small to actually do anything useful on github, and I need to stop staring at the tiny screen for a while.) That has the fingerprints of an EMP coming in on the broadband cable. - Charles I hear that, its warmed up a bit but it was -9F here this morning. We are hybernating or working on software for a 30 yo computer. And currently waiting for the author of the software that hooks its printer facility up to a modern printer, my assembly listings leave single space, arrive on paper double spaced. A nilmerg of some sort. But every thing I try to do on wheezy shows me something else broken. I have no clue how so much stuff can be broken and its still as stable
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
On Wednesday, February 18, 2015 08:11:13 PM Charles Lepple wrote: [...] On recent Debian and Ubuntu with 2.7.2 and earlier, there was an issue where the udev rules file needed to be renamed from 62-nut* to 52-nut* in order to not be overridden by another set of rules. It lives somewhere like /lib/udev/rules.d Charles; I assume this is the message you refered to, so I just checked my wheezy at that location, and its already been done. ISTR there was a udev update recently. So wheezy, if up to date, looks to be on top of it. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
On Thursday, February 19, 2015 10:16:41 PM Charles Lepple wrote: On Feb 19, 2015, at 8:55 AM, Gene Heskett ghesk...@wdtv.com wrote: On Wednesday, February 18, 2015 08:11:13 PM Charles Lepple wrote: [...] On recent Debian and Ubuntu with 2.7.2 and earlier, there was an issue where the udev rules file needed to be renamed from 62-nut* to 52-nut* in order to not be overridden by another set of rules. It lives somewhere like /lib/udev/rules.d Charles; I assume this is the message you refered to, so I just checked my wheezy at that location, and its already been done. ISTR there was a udev update recently. So wheezy, if up to date, looks to be on top of it. Gene, As I mentioned to Rob, I got that backwards, and the file should be named 62-nut... to override the earlier defaults. (It is extra-confusing because we still have an IPMI rules file that starts with 52.) I guess I didn't see that, thanks, done. I haven't made much progress, got side tracked trying to print the .pdf and found that there is no known way in wheezy to make a duplex capable printer, actually print in duplex mode. Almost $800 dollars and worthless on wheezy. I am asking a few ?? over that on their mailing list as it worked perfectly on ubuntu-10.04.4 LTS. Wheezy is dead stable, but actually getting something done with it is almost always a maddening battle of wits. I have a single sided printout, 88 pages of 24 lb, but IIRC my 3 hole punch, a good one, is out in the machine shed where I was last updating my LinuxCNC doc's. And its currently +2F nearly a foot of snow to plow to go get it. And of coarse I'll need to find a 3 ring binder that I can recycle to be a nut doc holder. 1 step forward seems to be a 2 step backwards in real life. I don't even know if I am using the correct driver, the ups-scanner seems only to exist in my 2.7.2 src tree, but its not installed as its looking for a much older libssl than I now have. And the error messages from an attempted start are so generic they aren't a lot of help. So and so didn't start, but no reason why is given. After mv'ing that file, I still get: root@coyote:/etc/init.d# ./nut-server start [ ok ] Starting NUT - power devices information server and drivers: (driver(s) failed). upsd. Why can it not name the failed driver, so I would know to try another? - Charles Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] One more try at nut, this time on debian 7.8 (wheezy)
On Wednesday, February 18, 2015 10:10:37 PM Charles Lepple wrote: On Feb 18, 2015, at 7:56 PM, Gene Heskett ghesk...@wdtv.com wrote: Even though I installed nut-doc, there are no man pages so I am running in the dark again. They seem to be in the file list: https://packages.debian.org/wheezy/amd64/nut-client/filelist Is $MANPATH set to something strange? Empty, LF terminated string. Or maybe the echo terminated it. Where is the initial config and startup procedure to be found? ISTR it was a web page at one time. This? http://www.networkupstools.org/docs/user-manual.chunked/ar01s06.html I believe it is, thanks Charles. While Roger Price's guide is for openSuse, it is a little more approachable than the NUT manual (which is more of a reference, I guess). http://rogerprice.org/NUT.html I'll take a look at that too. Also note my post from earlier this evening- wheezy might also be affected by that Debian bug, if you have a USB UPS. I believe it can be either, connected to usb ATM. - Charles Thanks Charles, I'll pursue this when I have both eyes open. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] One more try at nut, this time on debian 7.8 (wheezy)
Greetings Charles; I eventually gave up making it work on ubuntu-10.04.4 LTS, and that drive is slowly curling up its toes, so I am running wheezy on a fresher drive now. I have installed all the nut stuffs from the repo, and now have two more scripts in /etc/init.d called nut-client and nut-server. dmesg |grep Belkin - : root@coyote:/etc/nut# dmesg|grep Belkin [4.242066] usb 2-3: Product: Belkin UPS [4.242069] usb 2-3: Manufacturer: Belkin [4.975284] generic-usb 0003:050D:0751.0001: hiddev0,hidraw0: USB HID v1.11 Device [Belkin Belkin UPS] on usb-:00:02.0-3/input0 I have added this stanza to /etc/nut/nut.conf: [myups] driver=generic-usb port=/dev/ttyUSB0 Some attempts to start nut-server: root@coyote:/etc/nut# /etc/init.d/nut-server start [ ok ] Starting NUT - power devices information server and drivers: (driver(s) failed). upsd. root@coyote:/etc/nut# /etc/init.d/nut-server stop [ ok ] Stopping NUT - power devices information server and drivers: upsd (driver(s) failed). root@coyote:/etc/nut# /etc/init.d/nut-server start [ ok ] Starting NUT - power devices information server and drivers: (driver(s) failed). upsd. root@coyote:/etc/nut# /etc/init.d/nut-server status Checking status of NUT - power devices information server and drivers [ ok ] upsd is running. Even though I installed nut-doc, there are no man pages so I am running in the dark again. Where is the initial config and startup procedure to be found? ISTR it was a web page at one time. Thanks Charles. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] puzzle, need magic incantation
Hi Charles; I had nut working from before, but managed to lock up something and had to reboot. Nut is in the stuff to start at boot time, but is not now capable to being restarted with the nut script in /etc/init.d, claiming it is disabled: gene@coyote:/usr/src/nut-2.7.2/docs/man$ sudo service nut start * nut disabled, please adjust the configuration to your needs * Then set MODE to a suitable value in /usr/local/ups/etc/nut/nut.conf to enable it gene@coyote:/usr/src/nut-2.7.2/docs/man$ service nut start * nut disabled, please adjust the configuration to your needs * Then set MODE to a suitable value in /usr/local/ups/etc/nut/nut.conf to enable it So I look at that file and see it has only one active line: mode=standalone So where do I go from here? Minor rant: FWIW, before I asked, I redid the nut ./configure --with-doc=auto, then a make. Then I step into the docs directory and do a sudo make install, which it appears to do. But no manpages were install despite the command line echo showing that they were when I did the sudo make install, but I am forced to go into the docs directory and a man ./name-of-man-page to read it, and mode is only mentioned briefly in the example line which shows mode=none. That is a 10-33 torr suckage. This I think can be alleviated by setting up the env variable MANPATH, which is not apparently configured. Export that and it works. So put it in my .bashrc But since every other manpage on the system works without that env setting of $MANPATH, showing /usr/local/ups/share/man:/usr/share/man when queried now, why should i have to do it for nuts man pages? Boggles the mind. End minor rant. And I still cannot start it, see above. The error msg says its disabled, but not why, so I've exactly no clue what is really wrong. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] puzzle, need magic incantation (nut.conf)
On Monday 01 December 2014 20:35:15 Charles Lepple did opine And Gene did reply: On Dec 1, 2014, at 9:43 AM, Gene Heskett ghesk...@wdtv.com wrote: Hi Charles; I had nut working from before, but managed to lock up something and had to reboot. Nut is in the stuff to start at boot time, but is not now capable to being restarted with the nut script in /etc/init.d, claiming it is disabled: gene@coyote:/usr/src/nut-2.7.2/docs/man$ sudo service nut start * nut disabled, please adjust the configuration to your needs * Then set MODE to a suitable value in /usr/local/ups/etc/nut/nut.conf to enable it gene@coyote:/usr/src/nut-2.7.2/docs/man$ service nut start * nut disabled, please adjust the configuration to your needs * Then set MODE to a suitable value in /usr/local/ups/etc/nut/nut.conf to enable it So I look at that file and see it has only one active line: mode=standalone Hi Gene, Is the MODE token capitalized? Yes. The one in /usr/local/ups/etc is the only one it can find Copy/paste: MODE=standalone Aha! The paths in the /etc/init.d/nut script were wrong. Fixed that up and a sudo service nut restart seems to have fired it right up. Except that /usr/local/ups/bin/upsc myups is connection refused. And it is not visible in htop. Next? Thank you Charles (The nut.conf file is included in the startup shell script, which is case-sensitive.) Here is the original nut.conf with its comments: https://github.com/networkupstools/nut/blob/587d5f828c03d961f0cbeb11c6a 19a7944ec6ccd/conf/nut.conf.sample Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] puzzle, need magic incantation (man pages)
On Monday 01 December 2014 20:43:37 Charles Lepple did opine And Gene did reply: On Dec 1, 2014, at 9:43 AM, Gene Heskett ghesk...@wdtv.com wrote: FWIW, before I asked, I redid the nut ./configure --with-doc=auto, then a make. Then I step into the docs directory and do a sudo make install, which it appears to do. But no manpages were install despite the command line echo showing that they were when I did the sudo make install, but I am forced to go into the docs directory and a man ./name-of-man-page to read it, and mode is only mentioned briefly in the example line which shows mode=none. That is a 10-33 torr suckage. I think that other link I sent to the sample nut.conf has all of the possible values there - not sure what happened to those comments in your original file. This I think can be alleviated by setting up the env variable MANPATH, which is not apparently configured. Export that and it works. So put it in my .bashrc But since every other manpage on the system works without that env setting of $MANPATH, showing /usr/local/ups/share/man:/usr/share/man when queried now, why should i have to do it for nuts man pages? Boggles the mind. If you run ./configure without passing, say, --prefix=/usr/local, it will default to --prefix=/usr/local/ups which has the advantage of putting everything in one directory. To clean up, you just delete /usr/local/ups. Cleaning up after a botched install to /usr/local is painful, either involving backups, or surgically removing files from bin/, sbin/, etc/, man/man?/, etc. BTDT, not fun. Thanks Charles Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Still trying to make nut work, failing miserably
On Tuesday 11 November 2014 22:35:58 Charles Lepple did opine And Gene did reply: On Nov 11, 2014, at 9:41 PM, Gene Heskett ghesk...@wdtv.com wrote: Can't claim USB device [050d:0751]: could not detach kernel driver from interface 0: Operation not permitted Driver failed to start (exit status=1) In /dev/ttyUSB0 is owned by root. /dev/usb/hiddev3, the last one, has a slow data marching out of it if I sudo cat /etc/dev/usb/hiddev3 Hi Gene, I wish we had a good way to print a more specific error message (libusb doesn't return enough information to do so), but it's none of the above. The Linux box only has a serial UPS attached at the moment, but we'll pretend my mouse is the UPS: $ lsusb -d 046d: Bus 001 Device 008: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse (In your case, you would run lsusb -d 050d:0751) The Bus 001 Device 008 part maps to names under /dev/bus/usb. In this case: And I get: gene@coyote:/usr/local/ups/etc$ lsusb -d 050d:0751 Bus 001 Device 002: ID 050d:0751 Belkin Components $ ls -l /dev/bus/usb/001/008 crw-rw-r-T 1 root root 189, 7 Nov 4 19:53 /dev/bus/usb/001/008 And I get: gene@coyote:/usr/local/ups/etc$ ls -l /dev/bus/usb/001/002 crw-rw-r-- 1 root root 189, 1 2014-11-05 10:03 /dev/bus/usb/001/002 This is the /dev node that needs to be owned by the NUT user. That 050d:0751 identifier is in /lib/udev/rules.d/52-nut-usbups.rules, I changed the group from nobody to nut and issued a sudo service udev restart, but the port is still owned by root:root. There is a udev rules file that, when installed to someplace like /etc/udev/rules.d, should change the permissions of the /dev/bus/usb file automatically. I can never keep track of what needs to be unplugged and/or restarted to get that to work, though. The FAQ suggests that unplugging and re-plugging the USB cable after installing the udev file should be sufficient, but older udev daemons might need to be restarted. I'll try the cable unplug. Thats better, dmesg reports: [565202.435364] usb 1-10: new low-speed USB device number 3 using ohci-pci [565202.717927] usb 1-10: New USB device found, idVendor=050d, idProduct=0751 [565202.717931] usb 1-10: New USB device strings: Mfr=4, Product=20, SerialNumber=0 [565202.717934] usb 1-10: Product: Belkin UPS [565202.717936] usb 1-10: Manufacturer: Belkin [565203.459524] hid-generic 0003:050D:0751.0008: hiddev0,hidraw6: USB HID v1.11 Device [Belkin Belkin UPS] on usb-:00:02.0-10/input0 And gene@coyote:/etc/init.d$ /usr/local/ups/sbin/upsdrvctl start Network UPS Tools - UPS driver controller 2.7.2 Network UPS Tools - Generic HID driver 0.38 (2.7.2) USB communication driver 0.32 Using subdriver: Belkin HID 0.16 No errors, although the last time I got this far, it started bonging the speakers at about 10 minute intervals. So I will throttle the volume control for the night, and see how much further I can get in the morning. But no noises or -walls issued, so I ran /usr/local/ups/bin/upsc myups@localhost And got a full status report from it! So at this point, once upsmon is configured, I should be off to the races. Thank you Charles. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] config file locations
On Wednesday 22 October 2014 09:08:38 Charles Lepple did opine And Gene did reply: On Oct 21, 2014, at 11:37 PM, Gene Heskett ghesk...@wdtv.com wrote: Hummm, that got me past that barricade, but then it needed asciidoc, which pulled in everything else it was fussing about. The everything else was close to all of tex and latex, something north of 220 megs worth. Drive space I have, but thats a heck of big hunk of dependency. You mean that LaTeX isn't on everyone's short list of must-have packages? ;-) Apparently not here at the Heskett Ranchette. However, the configure is still bailing out: checking for library containing gdImagePng... -lgd checking whether to build CGI programs... yes checking for asciidoc... /usr/bin/asciidoc checking for asciiDoc version... 8.5.2 found checking for a2x... /usr/bin/a2x checking for a2x version... 8.5.2 found checking for dblatex... /usr/bin/dblatex checking for dblatex version... 0.2.12-4 found checking if asciidoc version can build html-single... no checking if a2x version can build html-chunked... no checking if dblatex version can build pdf... yes configure: error: Unable to build html-single html-chunked documentation which doesn't tell me what else I need. Clues? Agreed, we could do better with the error messages. In configure.ac, it is looking for asciidoc = 8.6.3. Nothing immediately jumps out in my mind as to why, but there were a few early 8.6.x versions that had issues. 8.5.2 is whats in the repo's... Asciidoc is a fairly light-weight install by itself (considering that the other doc dependencies are already installed), so doing a source install to /usr/local, even with the Ubuntu package installed to /usr, should not conflict (no PID files, etc.). I believe I have done that before to work around the aforementioned bugs: http://asciidoc.org/INSTALL.html#X1 Thanks, I'll study on that. Stepping back a bit, are you looking to do anything specific with building the documentation, or are you just looking for doc files that match your current version of NUT? The latter. (I really thought we distributed the generated PDF and HTML documentation alongside the formatted man pages in the nut-*.tar.gz, but I guess that is only in the .deb packages.) Right, my 2.7.2/doc dir is full of .txt files. If you are looking for 2.7.2 documentation, we have the PDFs posted on the main website: http://www.networkupstools.org/documentation.html (There is a patch in the works to automatically add the current version number to the PDF revision log.) For the latest information, we have a similar page that is generated by Buildbot from the Git tree: http://new.networkupstools.org/documentation.html (also working out some issues with the version number at the footer of the HTML pages, but the date is correct.) Of course, there are the Asciidoc text files as well in nut-2.7.2/docs/, which can be handy if you need to search for something specific with grep. I'm not saying don't bother to rebuild the documentation, but it is one of the dependencies that is unintentionally optimized for developers who need to make changes to the documentation, and see how the changes render. I have built and installed it without the docs, and will see if I can sort whats in the tarballs doc directory. With the fresh build, I'll be starting the configuration for my use from scratch. But I have a Dr's appointment about as fast as I can shave shower get there, another shot of some kind of $150/shot stuff in a knee I tore up a year small change ago. Thanks Charles, I'll give it another try from the src install. After I follow the asciidoc link and see if that is fixable. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] config file locations
On Tuesday 21 October 2014 22:06:48 Charles Lepple did opine And Gene did reply: Hi Gene, On Oct 21, 2014, at 9:12 PM, Gene Heskett ghesk...@wdtv.com wrote: configure: error: libgd not found, required for CGI build And gdlib does not appear to be available from the repo's. Sorry, I must have missed that message. This is still with Ubuntu 10.04, right? http://packages.ubuntu.com/source/lucid/nut lists the build dependencies, and it looks like both libgd2-xpm-dev and libgd2-noxpm-dev are still available. (NUT does not explicitly need the XPM support, so either one should work.) I will admit that we haven't done much with the NUT CGI stuff lately. A few years ago, someone pointed me towards collectd, which logs min/max/average values to RRD databases (among others), and I have been using that to get hourly/daily/weekly/monthly summaries via CGI scripts (/usr/share/doc/collectd-core/examples/collection3). NUT monitoring seems to be available in the collectd version that is in 10.04. Something to consider if you are looking for more than just an instantaneous readout: http://packages.ubuntu.com/lucid/collectd Can you snapshot the stuff in collectd.conf that enable nut monitoring? And where then do I read the results? Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] config file locations
On Tuesday 21 October 2014 22:06:48 Charles Lepple did opine And Gene did reply: Hi Gene, On Oct 21, 2014, at 9:12 PM, Gene Heskett ghesk...@wdtv.com wrote: configure: error: libgd not found, required for CGI build And gdlib does not appear to be available from the repo's. Sorry, I must have missed that message. This is still with Ubuntu 10.04, right? Yes. http://packages.ubuntu.com/source/lucid/nut lists the build dependencies, and it looks like both libgd2-xpm-dev and libgd2-noxpm-dev are still available. (NUT does not explicitly need the XPM support, so either one should work.) Hummm, that got me past that barricade, but then it needed asciidoc, which pulled in everything else it was fussing about. The everything else was close to all of tex and latex, something north of 220 megs worth. Drive space I have, but thats a heck of big hunk of dependency. However, the configure is still bailing out: checking for library containing gdImagePng... -lgd checking whether to build CGI programs... yes checking for asciidoc... /usr/bin/asciidoc checking for asciiDoc version... 8.5.2 found checking for a2x... /usr/bin/a2x checking for a2x version... 8.5.2 found checking for dblatex... /usr/bin/dblatex checking for dblatex version... 0.2.12-4 found checking if asciidoc version can build html-single... no checking if a2x version can build html-chunked... no checking if dblatex version can build pdf... yes configure: error: Unable to build html-single html-chunked documentation which doesn't tell me what else I need. Clues? I will admit that we haven't done much with the NUT CGI stuff lately. A few years ago, someone pointed me towards collectd, which logs min/max/average values to RRD databases (among others), and I have been using that to get hourly/daily/weekly/monthly summaries via CGI scripts (/usr/share/doc/collectd-core/examples/collection3). NUT monitoring seems to be available in the collectd version that is in 10.04. Something to consider if you are looking for more than just an instantaneous readout: http://packages.ubuntu.com/lucid/collectd I'll take a look after I make sure its installed. Thanks for the hint. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] config file locations
On Sunday 19 October 2014 22:03:23 Charles Lepple did opine And Gene did reply: Hi Gene, On Oct 18, 2014, at 7:35 PM, Gene Heskett ghesk...@wdtv.com wrote: Greetings; I found pdf user manual which explains a few things that might help. However, for a ubuntu flavor, the various .conf etc files seem to be in /etc/nut. We have an open ticket about that[*]; basically, the official NUT documentation needs to be a bit more explicit that the paths are what you would get with a vanilla source install, and that distributions will most likely be different. [*] https://github.com/networkupstools/nut/issues/152 Trouble is shooting back already: ./configure --with-usb --with-cgi --with-doc bails out: checking for gd version via gdlib-config... none found checking for gd include flags... checking for gd library flags... -L/usr/X11R6/lib -lgd -lpng -lz -ljpeg - lfreetype -lm -lXpm -lX11 checking for gd.h... no checking for gdfontmb.h... no checking for library containing gdImagePng... no configure: error: libgd not found, required for CGI build And gdlib does not appear to be available from the repo's. I'd like to have the CGI scripts working so I can read it with a browser. Ideas? This time of the night I'm not even fresh enough to say I am fresh out. Thanks Charles. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] config file locations
On Sunday 19 October 2014 22:03:23 Charles Lepple did opine And Gene did reply: Hi Gene, On Oct 18, 2014, at 7:35 PM, Gene Heskett ghesk...@wdtv.com wrote: Greetings; I found pdf user manual which explains a few things that might help. However, for a ubuntu flavor, the various .conf etc files seem to be in /etc/nut. We have an open ticket about that[*]; basically, the official NUT documentation needs to be a bit more explicit that the paths are what you would get with a vanilla source install, and that distributions will most likely be different. [*] https://github.com/networkupstools/nut/issues/152 But this pdf says they are in /usr/local/ups/etc, and yes indeed there are some there, with the .sample files being owned by root, and the rest are user 503, whoever he may be. If it's the same coyote machine from 2010, the archives indicate that you installed from source at one point. The Ubuntu packages shouldn't have written to /usr/local. Are these just a sample storage in case one needs to start from square #0 again? Or what? Yes, but the paths in those files are from the source install. I forget what Ubuntu did with the 10.04 packages, but it probably shipped *.sample files in either /etc/nut or /usr/share/doc/nut/examples. Then on down the page it says it should start by using upsdrvctl start, I get sudo upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 Broadcast Message from gene@coyote (somewhere) at 19:16 ... Communications with UPS myups@localhost established Broadcast Message from gene@coyote (somewhere) at 19:16 ... Communications with UPS myups@localhost established Broadcast Message from gene@coyote (somewhere) at 19:16 ... Communications with UPS myups@localhost established But why do I get 3 of them? Good question, but it's going to be hard to tease apart the Ubuntu .deb install and the source install. Note that some versions of /etc/init.d/nut (provided by Ubuntu) will start the driver as well as upsd and upsmon, so the separate upsdrvctl start is not necessary. Do you have anything else installed to /usr/local? If not, it might be easier to move that directory aside. Then again, if you installed from source, it was probably due to something not being in the Ubuntu packages. So I go thru htop, after issueing stops to upsdrvctl and nut, then restart the driver, then nut, and now my log is being spammed by: Oct 18 19:25:51 coyote kernel: [117004.485575] usb 1-10: usbfs: process 29641 (usbhid-ups) did not claim interface 0 before use Oct 18 19:25:54 coyote kernel: [117007.499806] usb 1-10: usbfs: process 29668 (usbhid-ups) did not claim interface 0 before use Oct 18 19:25:54 coyote kernel: [117007.499850] usb 1-10: usbfs: process 29668 (usbhid-ups) did not claim interface 0 before use about 1/second. With usbhid-ups, this tends to only happen when multiple drivers are running. The stop command should kill it, doesn't, I have to go find it with htop and nuke it from there. This is nut-2.7.2, and the kit was unpacked on 6/26/2014, so it is a local build. But then oldtimers has hit, and according to synaptic, 2.4.3 from ubuntu repos was also installed. So I have a flustercluck at best, and have removed the ubuntu version, and will reinstall from my later src. I'll advise how that turns out in due time. Thanks for your patience Charles. Darn, the docs I pulled and printed 2-3 days ago are for 2.6.0. I'll check my src tree. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin unk ups
On Tuesday 14 October 2014 08:19:02 Charles Lepple did opine And Gene did reply: usbhid-ups Added that, but only get this at sudo service nut start gene@coyote:/etc/init.d$ sudo service nut start * Starting Network UPS Tools [ OK ] Broadcast Message from nut@coyote (somewhere) at 8:37 ... Communications with UPS my...@coyote.coyote.den lost Broadcast Message from nut@coyote (somewhere) at 8:37 ... UPS my...@coyote.coyote.den is unavailable service nut stop * Stopping Network UPS Tools I haven't checked cabling, but AFAIK its still plugged in, but not sure if its usb or serial cabling. I'll check that once I get both eyes open simultaneously and report back. Found the cable, a D type usb, unplugged it and replugged it, and it appears now to be /dev/usb/hiddev3. dmesg, ever so helpful, and lsusb equally helpful, do not tell what the /dev/usbdevice is assigned to the newly discovered plugin. dmesg just reports: [136319.530160] usb 1-10: USB disconnect, device number 2 [136322.641716] usb 1-10: new low-speed USB device number 3 using ohci-pci [136322.929480] usb 1-10: New USB device found, idVendor=050d, idProduct=0751 [136322.929486] usb 1-10: New USB device strings: Mfr=4, Product=20, SerialNumber=0 [136322.929489] usb 1-10: Product: Belkin UPS [136322.929491] usb 1-10: Manufacturer: Belkin [136323.695058] hid-generic 0003:050D:0751.0008: hiddev0,hidraw6: USB HID v1.11 Device [Belkin Belkin UPS] on usb-:00:02.0-10/input0 So is this usb-:00:02.0-10/input0 a valid way to give nut a path to it, and if so, what file do I add that too? I also note that in the original bootup discovery it was hiddev0/hidraw6, the same as the latest plug in report, so that also appears stable. But ls -l /dev/usb: crw-rw 1 root root 180, 0 2014-10-12 18:51 hiddev0 crw-rw 1 root root 180, 1 2014-10-12 18:51 hiddev1 crw-rw 1 root root 180, 2 2014-10-12 18:51 hiddev2 crw-rw 1 root root 180, 3 2014-10-14 08:44 hiddev3 crw-rw 1 root lp 180, 4 2014-10-13 05:50 lp4 crw-rw 1 root lp 180, 5 2014-10-13 05:50 lp5 shows that hiddev3 is the one created by my cable unplug/replug. Call me confused at best. Guidance needed yet, obviously. I've had several birthdays since we last conversed, so I am now 80yo, and definitely seeing the effects of poorer short term memory. Darnit... Thanks Charles Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Belkin usp startup
Hi Charles; I think its not working yet even though I seem to be getting only one error, but I cannot seem to get upsmon to output the current ups status. So, since I cannot find any manpages (is that a separate package, if so I did not see it in the repo.) about the only error I can get out of it is that it is not listening on localhost:3493. Yet that is specified in the conf files: ene@coyote:/etc/nut$ sudo grep localhost * hosts.conf:MONITOR myups@localhost Local UPS upsd.conf:# This defaults to the localhost listening address and port 3493. You upsd.users:# MONITOR myups@localhost 1 upsmon pass master (or slave) upsmon.conf:# like ups@localhost, su700@mybox, etc. upsmon.conf:MONITOR myups@localhost 1 gene xxxpass master upsmon.conf:# MONITOR myups@localhost 1 upsmon pass master (or slave) upssched.conf:# If a specific UPS (myups@localhost) comes back online, then stop the upssched.conf:# AT COMMOK myups@localhost CANCEL-TIMER upsgone upsstats-single.html:!-- LINK REL=stylesheet TYPE=text/css HREF=http://localhost/nut/nut.css; / -- Is there, someplace in this deb install, a README that helps one to set it up correctly? Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Belkin unk ups
Greetings; Its unk because whats plugged in seems to be blocking the rear name plate. About all I can recall is that its big, 3 battery unit, rated somewhere north ob 1250 VA. Its an 050D:0751 Belkin. What driver should I use, and what file is that set in? The nut version presently and freshly installed is from the Ubuntu 10.04.4 LTS repo's. Probably old, but IIRC it also worked with the Ubu 8.04 LTS version. Thanks. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] libusb not recognized?
On Tuesday, November 22, 2011 12:54:58 PM Andrew Min Chang did opine: Hi Fr¨¦d¨¦ric,Sure, config.log and make.log, att. By the way, what's the meaning of 21? That is the most commonly used syntax for redirecting the shells stderr path to the stdout path, and you see both errors and normal output in that data stream. If you then append /logfile to that, all output is then saved in the logfile. Or, if you want to append to an existing file, the logfile will append the data to an existing file. Bog Std (standard, all shells apparently do it, unix like tools. ;-) Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene Incumbent, n.: Person of liveliest interest to the outcumbents. -- Ambrose Bierce, The Devil's Dictionary ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] can't connect to an Eaton Powerware 9155 over a usb-serial adapter
On Thursday, July 28, 2011 11:11:26 AM Athanasios Silis did opine: hello everyone, I've been testing the NUT solution as opposed to the undocumented LanSafe application to control my Eaton UPS. I am on a Slackware 13.37 system with a 2.6.37.6 kernel. NUT version is 2.4.3 . I installed the tarball by compiling it directly on my system (as a slackbuild package). The UPS is an Eaton Powerware 9155, but I don't know how to obtain the manufacturing date. The unit was bought sometime in 2006-2007 though. The unit has a serial interface to communicate with a pc, and I am using a usb-serial converter to connect it there. dmesg shows: usb 6-2: new full speed USB device using uhci_hcd and address 3 usb 6-2: New USB device found, idVendor=067b, idProduct=2303 usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 6-2: Product: USB-Serial Controller usb 6-2: Manufacturer: Prolific Technology Inc. pl2303 6-2:1.0: pl2303 converter detected usb 6-2: pl2303 converter now attached to ttyUSB0 Boom, magic words contained above, Prolific etc. Change them to Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC (FTDI) watch the problems become the normal ones. Prolifics like to throw away the first byte of a packet, confuses the heck out of the rest of the system. This converter appears to the system as /dev/ttyUSB0. But I presume for all practical purposes I should assume that this is just another serial port (correct me if that's wrong). My ups.conf looks line: [DSAups] driver = bcmxcp port = /dev/ttyUSB0 desc = Eaton Powerware 9155 I have ALSO attempted to run the drivers: bcmxcp-usb, upscode2, usbhid-ups (just in case the /dev/ttyUSB0 is actually a USB look-alike port rather than serial look-alike one) to no avail. the debug output is the following: root@samothraki:/usr/libexec/nut# ./bcmxcp -D -a DSAups Network UPS Tools - BCMXCP UPS driver 0.23 (2.4.3) RS-232 communication subdriver 0.17 0.00 send_to_all: SETINFO driver.parameter.port /dev/ttyUSB0 0.35 debug level is '5' 0.008369 Attempting to autodect baudrate 1.603672 Receive error (PW_COMMAND_START_BYTE): 0!!! 2.604114 Receive error (PW_COMMAND_START_BYTE): 0!!! 3.604528 Receive error (PW_COMMAND_START_BYTE): 0!!! 3.604547 No response from UPS on /dev/ttyUSB0 with baudrate 1200 5.199170 Receive error (PW_COMMAND_START_BYTE): 0!!! 6.200268 Receive error (PW_COMMAND_START_BYTE): 0!!! 7.201363 Receive error (PW_COMMAND_START_BYTE): 0!!! 7.201386 No response from UPS on /dev/ttyUSB0 with baudrate 2400 8.796693 Receive error (PW_COMMAND_START_BYTE): 0!!! 9.797796 Receive error (PW_COMMAND_START_BYTE): 0!!! 10.798900 Receive error (PW_COMMAND_START_BYTE): 0!!! 10.798924 No response from UPS on /dev/ttyUSB0 with baudrate 4800 12.394722 Receive error (PW_COMMAND_START_BYTE): 0!!! 13.395824 Receive error (PW_COMMAND_START_BYTE): 0!!! 14.396925 Receive error (PW_COMMAND_START_BYTE): 0!!! 14.396949 No response from UPS on /dev/ttyUSB0 with baudrate 9600 15.052002 Communications with UPS lost: checksum error! 15.084000 Communications with UPS lost: Not the right sequence received fe!!! 16.084278 Receive error (PW_COMMAND_START_BYTE): 0!!! 16.084306 No response from UPS on /dev/ttyUSB0 with baudrate 19200 16.084312 Can't connect to the UPS on port /dev/ttyUSB0! root@samothraki:/usr/libexec/nut# This is typical of the errors you get while using the drain bamaged pl2303. Go get an FDTI interface. Looks fairly dead to me as if theere was smth wrong with the cables. So I installed a windows server 2008 virtual machine (on virtualbox) and attached the /dev/ttyUSB0 to the virtual machine. There I installed the LanSafe application provided by Eaton and voila, the system was working. So there is something else going on here, directly on the host, which I can't understand. Any ideas? Thank you in advance for your help Nass Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) We all live under the same sky, but we don't all have the same horizon. -- Dr. Konrad Adenauer ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin Regulator Pro dropping connection and halting
On Thursday, December 02, 2010 10:05:54 am Arjen de Korte did opine: Citeren Arnaud Quette aquette@gmail.com: Thanks for the suggestions, I've added the flush statement as well as some debugging information. As this is a intermittent issue I decided to try overloading the UPS by sending it repeated beeper commands while watching the debug output. What appears to happen is that the UPS returns an unknown ~00R000 response. This means get_belkin_reply() returns -1, causing a datastale state is set when called from do_status(). you should remove the datastale() call since upsd will automatically flag the device as stalled if it has failed to update its data for 15 seconds (default of MAXAGE). Not at all! The upsd server will only declare the *driver* stale if it fails to respond within MAXAGE seconds. However, as long as it keeps answering the PING from the server, it will not be declared stale. This mechanism is something completely different from what happens if the driver calls dstate_datastale(). In that case the driver tells the upsd server that the *UPS* fails to respond. See the chapter on Staleness control in docs/new-drivers.txt. What really needs to be done, is that the driver doesn't treat the ~00R000 reply as an error condition. Apparently the UPS acknowledges the receipt of data, without further response (indicating that 0 bytes follow). The belkin driver doesn't accept this at the moment and requires that a reply follows. This is what needs to be changed. Last but not least, in most drivers, we allow a couple of missed replies before we call dstate_datastale() so that glitches don't lead to automatic reconnects. Best regards, Arjen I've been sitting here following this thread and wondering if the OP has told us everything? He may indeed be using serial at the ups, but if he has a pl2303 ser-usb adapter in the signal path and is using a ttyUSB# connection, then there could be a possibility that the pl2303 adapter is eating his lunch, specifically the first byte of a packet at frequent intervals, and this will confuse virtually all upsd implementations regardless of whose upsd it is, including belkin's own, now Jurassic dated bulldog software. Most of the more modern belkin UPS's do conform to the usb-hid specs, and I have had zero problems with loss of comm with mine over a pure usb circuit. usb 2-9: new low speed USB device using ohci_hcd and address 5 usb 2-9: New USB device found, idVendor=050d, idProduct=0751 usb 2-9: New USB device strings: Mfr=4, Product=20, SerialNumber=0 usb 2-9: Product: Belkin UPS usb 2-9: Manufacturer: Belkin It is a 1500 WA rated device also. I have another 1500WA rated Belkin, several years older and on its 4th set of batteries, that either isn't usb-hid con-formant, or when I last tried to run Nut against it, Nut's usb-hidraw wasn't up to speed. It is now running my milling machines computer. That computer is running Ubuntu-10.04, but emc is fussy about what you plug into a usb port, a usb key for instance is a guaranteed wrecked part because of the huge IRQ lockout times associated with the challenge/response time of the key as the I/O scheduler makes sure all the caches associated with have been flushed. That is from lessons learned while talking to myself. ;-) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Intel CPUs are not defective, they just act that way. -- Henry Spencer ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin Regulator Pro dropping connection and halting
On Thursday, December 02, 2010 04:36:43 pm John Bayly did opine: On 02/12/2010 15:28, Gene Heskett wrote: On Thursday, December 02, 2010 10:05:54 am Arjen de Korte did opine: Citeren Arnaud Quetteaquette@gmail.com: Thanks for the suggestions, I've added the flush statement as well as some debugging information. As this is a intermittent issue I decided to try overloading the UPS by sending it repeated beeper commands while watching the debug output. What appears to happen is that the UPS returns an unknown ~00R000 response. This means get_belkin_reply() returns -1, causing a datastale state is set when called from do_status(). you should remove the datastale() call since upsd will automatically flag the device as stalled if it has failed to update its data for 15 seconds (default of MAXAGE). Not at all! The upsd server will only declare the *driver* stale if it fails to respond within MAXAGE seconds. However, as long as it keeps answering the PING from the server, it will not be declared stale. This mechanism is something completely different from what happens if the driver calls dstate_datastale(). In that case the driver tells the upsd server that the *UPS* fails to respond. See the chapter on Staleness control in docs/new-drivers.txt. What really needs to be done, is that the driver doesn't treat the ~00R000 reply as an error condition. Apparently the UPS acknowledges the receipt of data, without further response (indicating that 0 bytes follow). The belkin driver doesn't accept this at the moment and requires that a reply follows. This is what needs to be changed. Last but not least, in most drivers, we allow a couple of missed replies before we call dstate_datastale() so that glitches don't lead to automatic reconnects. Best regards, Arjen I've been sitting here following this thread and wondering if the OP has told us everything? He may indeed be using serial at the ups, but if he has a pl2303 ser-usb adapter in the signal path and is using a ttyUSB# connection, then there could be a possibility that the pl2303 adapter is eating his lunch, specifically the first byte of a packet at frequent intervals, and this will confuse virtually all upsd implementations regardless of whose upsd it is, including belkin's own, now Jurassic dated bulldog software. Most of the more modern belkin UPS's do conform to the usb-hid specs, and I have had zero problems with loss of comm with mine over a pure usb circuit. usb 2-9: new low speed USB device using ohci_hcd and address 5 usb 2-9: New USB device found, idVendor=050d, idProduct=0751 usb 2-9: New USB device strings: Mfr=4, Product=20, SerialNumber=0 usb 2-9: Product: Belkin UPS usb 2-9: Manufacturer: Belkin It is a 1500 WA rated device also. I have another 1500WA rated Belkin, several years older and on its 4th set of batteries, that either isn't usb-hid con-formant, or when I last tried to run Nut against it, Nut's usb-hidraw wasn't up to speed. It is now running my milling machines computer. That computer is running Ubuntu-10.04, but emc is fussy about what you plug into a usb port, a usb key for instance is a guaranteed wrecked part because of the huge IRQ lockout times associated with the challenge/response time of the key as the I/O scheduler makes sure all the caches associated with have been flushed. That is from lessons learned while talking to myself. ;-) Nope, it's definately serial, UPS is on the D9 port (/dev/cuad0). I'm using the belkin driver, not the belkinunv or usb-hid drivers. Unfortunately Belkin seem to have disavowed all knowledge of the device as it's nowhere to be found on their website. Best description of it on a reseller's site: http://uk.insight.com/p/497211/belkin-regulator-pro-network-ups-ups-1400 -va.html That appears to be the Euro version of my older one, same box and front panel. And my snmp slot was empty, so I did not re-install the card slot for it when I last had it apart last spring to replace the batteries. I had to dismantle it quite far as the old ones had swelled and were bound in the frame. This one does not have a usb port, although it looks as if there might be a 9 pin usb header on its controller board, a dual row of 5 with one of the end pins missing. In fact, I wonder if a std computer breakout, back panel to motherboard usb kit might actually work? I have a spare of those, and the next time I haul it off the shelf (its 6+ feet up in the air, sitting on a brace across the rafters in my shop building, and pretty heavy for the old man to get it down back up), so I might just see what I blow if I hook it up to a usb port. I will probably be needing batteries again by then, and if I let the smoke out or break the mirror, I have had close to 10 years out of it anyway. -- Cheers, Gene There are four boxes to be used in defense
Re: [Nut-upsuser] syslog flooding
On Saturday, November 20, 2010 10:54:55 pm Charles Lepple did opine: On Nov 19, 2010, at 7:13 AM, Gene Heskett wrote: Greetings; Nut pull build from about two weeks ago, 2.4.3 I believe. The 2.4.3 tarball, or from SVN? (If SVN, there should be a number after 2.4.3, such as 2.4.3-r1234). Belkin UPS. I have everything working but a proper shutdown of upsd when I reboot, it hangs there and needs the hdwe reset button to reset it. That may be related to my finding more than 1 K##upsd and more than one K##upsmon, in /etc/rc5.d and which I have now nuked. However, while its working well enough to monitor, it is flooding the syslog every 2 seconds with: Nov 19 07:05:56 coyote upsd[4884]: mainloop: Interrupted system call Nov 19 07:05:56 coyote upsd[4884]: Signal 15: exiting Nov 19 07:05:56 coyote usbhid-ups[4874]: Signal 15: exiting ^^^ Is this part repeating, or was this just the first portion after restarting NUT? (In a normal setup, upsd should be started once, and shouldn't be killed until shutdown time.) Damn, sorry I didn't explain that. Yes, I wanted to show that it stopped with upsd stopping, and started again when it started. Then repeats the status - 121 at 2 second intervals forever. Nov 19 07:06:30 coyote klogd: ohci_hcd :00:02.0: urb e7d21400 path 9 ep1in 9312 cc 9 -- status -121 Looks like -121 is -EREMOTEIO, which apparently means this (from Documentation/usb/error-codes.txt in the kernel tree): The data read from the endpoint did not fill the specified buffer, and URB_SHORT_NOT_OK was set in urb-transfer_flags. But if queried, the status output was normal ANAICT. The fact that it is happening every two seconds might be a clue, but I am not familiar with the main status loop in usbhid-ups (I would have thought it would poll only once every 30 seconds, based on the man page). Perhaps one of the authors of usbhid-ups has a better idea of whether we can fix this (since libusb doesn't expose the URB transfer_flags options), or if it is something we can't work around. I believe the ups actually outputs a complete but simplified status frame every 2 seconds so that a better timeline can be logged. I have seen similar stuff on earlier installs by catting the interface it was plugged into. In any event, it stopped when I decided to build the usbdevfs file system into the kernel, or at least that stoppage corresponded to rebooting to that kernel. I don't even have a SWAG what the connection there might be. But now I am having trouble with /etc/init.d/upsd again. On a shutdown it gets to the turning off swap line, followed by a line from upsd echoing the $nutuser, and hangs forever or till I tap the the reset button. And since that started, it will not start properly and has to be restarted by hand once I've logged in. I suspect I need to nuke the lockfile before doing anything else in the startup as its not being properly nuked at the shutdown. chkconfig upsd now says: [r...@coyote ~]# chkconfig --list upsd upsd0:off 1:off 2:on3:on4:on5:on6:off 7:on And I just discovered chkconfig's resetpriorities option, so maybe that will fix it. In the meantime I'll look the script over see if its leaving stale lock files around. Thanks Charles. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) If you are over 80 years old and accompanied by your parents, we will cash your check. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] still no nut at reboot
On Wednesday, November 17, 2010 10:28:04 pm Charles Lepple did opine: On Nov 16, 2010, at 11:07 AM, Gene Heskett wrote: Before I start on those scripts again, can you clarify this line in the status output for me? ups.load: 31 Percentage of max load, as reported by the UPS itself. That was the conclusion I came to after considering alternatives, none of which made sense once I walked around the suggestion. Thanks for confirming it. Its a 1500 WA rated supply. If that is the percentage of the max load it can support, then there obviously is plenty of margin available to extend a drop cord to a legacy computer in the basement that normally runs headless because I usually work on it from here with a minicom session to a shell started to a serial port on it. That would help protect it from locally induced lightning cause emp's, which have caused degraded usb hubs in the past. However, that load would have to include a brother BW laser printer, and they are hungry, with dim the lights startup draws. Humm. I think I just shot that idea down in flames. I tend to keep printers on the surge-suppressed-only outlets. Inkjets aren't that bad, I've had an epson on this one since forever. But warming up the drum in a laser will raise the load considerably. If that is a percentage, the report should add a % to that line in the next incarnation. ;) ...or you could use a GUI for that ;-) KDE-3.5 had one that was downright purty, but it hasn't been ported to KDE-4.5.x yet, darnit. We've tried to keep the output simple and machine-parseable. All of the units are listed in the new user manual (as well as the text files in older versions of the documentation): http://buildbot.networkupstools.org/~buildbot/docs/latest/website/user-m anual.html#_nut_command_and_variable_naming_scheme Is that link in the INSTALL file? Thanks Charles. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Force has no place where there is need of skill. -- Herodotus ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] still no nut at reboot
On Tuesday, November 16, 2010 10:04:46 am Charles Lepple did opine: On Nov 15, 2010, at 11:37 AM, Gene Heskett wrote: On Monday, November 15, 2010 11:30:32 am Charles Lepple did opine: [...] I have attached it as it exists now. Backing up a bit, what is your overall goal of setting nutuser=gene? So I could control it as the user I normally run as. That's fixable of course. For controlling access to the read/write variables and commands, see man upsd.users. As mentioned, if you want to prevent someone from reading status, you would need to firewall the NUT port. (The upsd.users construct exists because the notion of system userids is very specific to a single system, so there needs to be a way to specify rights for remote connections.) But would that not mean I would have to become root to cause it to do a shutdown? There is a discussion of how things work in man upsmon, but basically, you start it as root, and it keeps a root-privileged process around that listens to a pipe from the unprivileged process. Ahh, that explains why I see two copies running, one as me and one as root. I have killed it all, and changed upsd.users to be this, passwds redacted of course: [r...@coyote etc]# cat upsd.users [root] password = xx actions = set, fsd instcmds = all [gene] password = upsmon master And then restarted all 3 processes by hand from a root cli. No errors reported from the startup. The driver is running as 'ups', upsd is running as ups, and two sessions of upsmon are running, one as root and one as me. Can I assume this is the correct profile now? Now to go see what I can do for the scripts in /etc/init.d once I've had some coffee. Last night is best described as poor sleeping conditions, trying to get my innards acclimated to metformin, a diabetic aid to glucose control. Thanks Charles. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) It's from Casablanca. I've been waiting all my life to use that line. -- Woody Allen, Play It Again, Sam ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] still no nut at reboot
On Tuesday, November 16, 2010 10:57:02 am Charles Lepple did opine: On Nov 15, 2010, at 11:37 AM, Gene Heskett wrote: On Monday, November 15, 2010 11:30:32 am Charles Lepple did opine: [...] I have attached it as it exists now. Backing up a bit, what is your overall goal of setting nutuser=gene? So I could control it as the user I normally run as. That's fixable of course. For controlling access to the read/write variables and commands, see man upsd.users. As mentioned, if you want to prevent someone from reading status, you would need to firewall the NUT port. (The upsd.users construct exists because the notion of system userids is very specific to a single system, so there needs to be a way to specify rights for remote connections.) But would that not mean I would have to become root to cause it to do a shutdown? There is a discussion of how things work in man upsmon, but basically, you start it as root, and it keeps a root-privileged process around that listens to a pipe from the unprivileged process. Before I start on those scripts again, can you clarify this line in the status output for me? ups.load: 31 Its a 1500 WA rated supply. If that is the percentage of the max load it can support, then there obviously is plenty of margin available to extend a drop cord to a legacy computer in the basement that normally runs headless because I usually work on it from here with a minicom session to a shell started to a serial port on it. That would help protect it from locally induced lightning cause emp's, which have caused degraded usb hubs in the past. However, that load would have to include a brother BW laser printer, and they are hungry, with dim the lights startup draws. Humm. I think I just shot that idea down in flames. If that is a percentage, the report should add a % to that line in the next incarnation. ;) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) About the only thing we have left that actually discriminates in favor of the plain people is the stork. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] still no nut at reboot
On Monday, November 15, 2010 11:43:10 am Charles Lepple did opine: [...] I have attached it as it exists now. Backing up a bit, what is your overall goal of setting nutuser=gene? Continuing. Changing uspd.users 'gene' entry to 'ups' I hit a passwd problem, because I didn't setup a passwd when I did the useradd ups thing this time, therefore have no clue how to change the user ups's passwd because there was not an old one set, but passwd seems to think there is. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) zpx it's amazing how not-broken debian is compared to slack and rh ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] still no nut at reboot
On Sunday, November 14, 2010 07:01:48 pm Charles Lepple did opine: On Nov 13, 2010, at 1:58 PM, Gene Heskett wrote: On Saturday, November 13, 2010 01:26:16 pm Charles Lepple did opine: On Nov 13, 2010, at 11:47 AM, Gene Heskett wrote: That file is currently, and I believe pursuant to the install instructions: [r...@coyote init.d]# ls -l /usr/local/ups/etc/ups.conf -rw-r- 1 root nut 95 2010-11-06 12:54 /usr/local/ups/etc/ ups.conf What do I do to the perms etc so that this file is readable, both now, and during the bootup when I enable a link to it from /etc/rc5.d? Does the mandriva script have the same assumptions about the NUT username? Also, is the nut user part of the nut group? $NUTUSER in that script is 'gene' aka me. This is set by the scripts parsing of /usr/local/ups/etc/upsmon.conf. I have fixed a few other problems in it by adding local vars for $DRIVERPATH and such. It is attached. I have made some small progress with some of the other errors until I believe this is the final one. I was going to try and install PCLinuxOS into a VM, but I haven't gotten very far with that. (It takes the VM about a half hour to boot to the login screen.) However, poking around the script, the $NUTUSER variable seems to be referring to the ups user you created as part of the INSTALL file procedure. The upsmon.conf man page refers to another user ID (nut- mon) but that's a bit of extra paranoia that we can shelve for now. I also have not attempted as yet to port the corresponding upsmon script, nor do I have a working /etc/shutdown. That was pointed out when I walked back in the house yesterday morning to discover that the slow beeps were from the ups as everything in here was running on it, so I did a shutdown - h now. It was long enough that a similar ups in the shop also ran out, but no apparent damages otherwise except the proper rebooting of another machine that doesn't have a ups on it. Also, is this the distribution you are using? http://www.pclinuxos.com/ Yes, all uptodate a/o last night except for tar-1.24 which breaks amanda (I think, I will retest tonight. I play the canary for amanda as the snapshots are released, have for years) I printed the INSTALL file, and have now been through it from square one, checking things off as I go, restarting at step 6 at least a dozen times now, getting the no perms thing at step 8, 9 or 10. From /etc/passwd: [r...@coyote Documents]# grep ups /etc/passwd ups:x:479:415:system user for nut:/var/state/ups:/bin/false izzat ^^ ?? I've done that by hand may have it screwed up The numerical UID and GID don't matter much, except that the GID needs to match between /etc/passwd and /etc/group (which it sounds like it does). You can also have strange behavior if you have two usernames which map to the same UID, but I don't think that would cause problems here. from /etc/group: [r...@coyote Documents]# grep nut /etc/group nut:x:415:ups That looks right. I may have missed this answer, but are you testing by running /etc/ init.d/upsd restart, Yes; [r...@coyote ~]# /etc/init.d/upsd restart nutuser=gene nutuser=gene NUT Stopping UPS daemon: Network UPS Tools upsd 2.4.3-2672 fopen /var/state/ups/upsd.pid: No such file or directory [ OK ] NUT Stopping UPS model drivers Network UPS Tools - UPS driver controller 2.4.3-2672 Can't open /var/state/ups/usbhid-ups-auto.pid: No such file or directory [FAILED] nutuser=gene NUT Starting UPS model drivers: Network UPS Tools - UPS driver controller 2.4.3-2672 Network UPS Tools - Generic HID driver 0.35 (2.4.3-2672) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 [ OK ] NUT Starting UPS daemon: Network UPS Tools upsd 2.4.3-2672 listening on localhost port 3493 listening on ::1 port 3493 /var/state/ups is world readable Can't open /usr/local/ups/etc/ups.conf: Can't open /usr/local/ups/etc/ups.conf: Permission denied [FAILED] That was as root; [r...@coyote ~]# su - gene /etc/init.d/upsd restart grep: /usr/local/ups/etc/upsmon.conf: Permission denied grep: /usr/local/ups/etc/upsmon.conf: Permission denied nutuser=ups /etc/init.d/upsd: line 99: /etc/init.d/upsd: Permission denied /etc/init.d/upsd: line 100: /etc/init.d/upsd: Permission denied [r
Re: [Nut-upsuser] still no nut at reboot
On Sunday, November 14, 2010 08:12:43 pm Gene Heskett did opine: ok, back after the reboot to get everything on the same page again, or so I thought. Silly me. now, I have a ups.conf containing this: [r...@coyote etc]# cat ups.conf [coyotes-ups] driver = usbhid-ups port = auto desc = Belkin ups usb interface So, first checking to see if the /etc/init.d/upsd script left anything I needed to kill behind, but it didn't, then check the perms on the /dev/hid* stuffs and find: [r...@coyote etc]# ls -l /dev/hid* crw--- 1 root root 250, 0 2010-11-14 20:00 /dev/hidraw0 crw--- 1 root root 250, 1 2010-11-14 20:00 /dev/hidraw1 So I am at step 8 of the INSTALL printout. -- [r...@coyote ~]# /usr/local/ups/bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3-2672M Network UPS Tools - Generic HID driver 0.35 (2.4.3-2672M) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 Fatal error: unable to create listener socket bind /var/state/ups/usbhid-ups-coyotes-ups failed: Permission denied Exiting. Driver failed to start (exit status=1) ---then [r...@coyote ~]# lsusb |grep elkin Bus 002 Device 008: ID 050d:0751 Belkin Components So lets stop right here and fix this. First: [r...@coyote etc]# grep ups /etc/passwd ups:x:502:504::/home/ups:/bin/bash There is no 'nut' in /etc/passwd now. and: [r...@coyote etc]# grep nut /etc/group nut:x:503:ups The whole thing has been rebuilt and reinstalled, but the .conf and .user files are still there. And I see the hacked mdv script to start it doesn't have a link in /etc/rc5.d, so it did not attempt to run at bootup. Whats next coach? I'm going blind staring at this, and probably missing something obvious, like hacking on the 52-* udev script some more to change some perms? FWIW, changing all the 'ATTR' to 'ATTRS' shut it up completely. This was udev complaining about a deprecated format. Other than the spelling, I didn't change anything else. So I'm waiting on you now. Thanks Charles -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) When does summertime come to Minnesota, you ask? Well, last year, I think it was a Tuesday. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] still no nut at reboot
On Monday, November 15, 2010 12:44:21 am Charles Lepple did opine: On Nov 14, 2010, at 8:36 PM, Gene Heskett wrote: ok, back after the reboot to get everything on the same page again, or so I thought. Silly me. now, I have a ups.conf containing this: [r...@coyote etc]# cat ups.conf [coyotes-ups] driver = usbhid-ups port = auto desc = Belkin ups usb interface Looks good. Ok. We'll finish pouring the cement then. :) So, first checking to see if the /etc/init.d/upsd script left anything I needed to kill behind, but it didn't, then check the perms on the / dev/hid* stuffs and find: [r...@coyote etc]# ls -l /dev/hid* crw--- 1 root root 250, 0 2010-11-14 20:00 /dev/hidraw0 crw--- 1 root root 250, 1 2010-11-14 20:00 /dev/hidraw1 These don't matter for NUT. Oh? So I am at step 8 of the INSTALL printout. -- [r...@coyote ~]# /usr/local/ups/bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3-2672M Network UPS Tools - Generic HID driver 0.35 (2.4.3-2672M) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 Fatal error: unable to create listener socket bind /var/state/ups/usbhid-ups-coyotes-ups failed: Permission denied Aha, ups owned by root:415. Nuts number changed and I didn't fix it. Have now, and it works: [r...@coyote etc]# /usr/local/ups/bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3-2672M Network UPS Tools - Generic HID driver 0.35 (2.4.3-2672M) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 [r...@coyote etc]# So I'm past that (again). On to step 9: [r...@coyote etc]# cat upsd.conf LISTEN ::1 3493 LISTEN localhost 3493 [r...@coyote etc]# cat upsd.users [gene] password = gh10041934 actions = set, fsd instcmds = all upsmon master Looks ok, so step 10 [r...@coyote etc]# /usr/local/ups/sbin/upsd Network UPS Tools upsd 2.4.3-2672M listening on localhost port 3493 listening on ::1 port 3493 /var/state/ups is world readable Connected to UPS [coyotes-ups]: usbhid-ups-coyotes-ups looks ok. 11. [r...@coyote etc]# /usr/local/ups/bin/upsc coyotes-...@localhost battery.charge: 100 battery.charge.low: 30 battery.charge.warning: 30 battery.runtime: 120 battery.type: PbAc battery.voltage: 27.7 battery.voltage.nominal: 24 device.mfr: Belkin device.model: Belkin UPS device.serial: device.type: ups driver.name: usbhid-ups etc etc But how about gene? [g...@coyote linux-2.6.36]$ /usr/local/ups/bin/upsc coyotes-...@localhost battery.charge: 100 battery.charge.low: 30 battery.charge.warning: 30 battery.runtime: 120 battery.type: PbAc battery.voltage: 27.7 battery.voltage.nominal: 24 device.mfr: Belkin device.model: Belkin UPS device.serial: device.type: ups driver.name: usbhid-ups aka yes! Ok, how about the init.d/upsd script? Nope, back to the perms problem [r...@coyote etc]# /etc/init.d/upsd restart nutuser=gene nutuser=gene NUT Stopping UPS daemon: Network UPS Tools upsd 2.4.3-2672M [ OK ] NUT Stopping UPS model drivers Network UPS Tools - UPS driver controller 2.4.3-2672M [ OK ] nutuser=gene NUT Starting UPS model drivers: Network UPS Tools - UPS driver controller 2.4.3-2672M Network UPS Tools - Generic HID driver 0.35 (2.4.3-2672M) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 [ OK ] NUT Starting UPS daemon: Network UPS Tools upsd 2.4.3-2672M listening on localhost port 3493 listening on ::1 port 3493 /var/state/ups is world readable Can't open /usr/local/ups/etc/ups.conf: Can't open /usr/local/ups/etc/ups.conf: Permission denied So, how does the nutuser=gene get access to ups.conf? (appending ',gene' to the group of ups nut didn't help. gene can run it from a cli, but that script can't. I have attached it as it exists now. The upsdrvctl program will drop privileges to the user name that you specified when running ./configure. You can temporarily bypass this by adding -u root to the command line, but afterwards, you will want to check step 5 (a chmod on the state path, a.k.a. listener socket directory). That was as stated in the INSTALL file. Exiting. Driver failed to start (exit status=1) ---then [r...@coyote ~]# lsusb |grep elkin Bus 002 Device 008: ID 050d:0751 Belkin Components This corresponds to either /proc/bus/usb/002/008 or /dev/usb/002/008
[Nut-upsuser] still no nut at reboot
Greetings; I have attempted to add the nut startup strings into my /etc/rc.local file, but with the new nono-serialized boot used by many distros today, I cannot see the startup and its error messages if any because the xserver is already started and that hide the messages. All I know is that it will not even show the driver in an htop report once booted. So, taking another tack, I have pulled the /etc/init.d/upsd script in from an older mandriva install that self-destructed, modified the paths in it to suit the installation in the /usr/local/ups tree. Parts of this appear to work. [r...@coyote init.d]# ./upsd restart NUT Stopping UPS daemon: /bin/bash: upsd: command not found [FAILED] NUT Stopping UPS model drivers /etc/rc.d/init.d/functions: line 621: /upsdrvctl: No such file or directory [FAILED] NUT Starting UPS model drivers: Network UPS Tools - UPS driver controller 2.4.3-2672 Network UPS Tools - Generic HID driver 0.35 (2.4.3-2672) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 [ OK ] NUT Starting UPS daemon: Network UPS Tools upsd 2.4.3-2672 ACL in upsd.conf is no longer supported - switch to LISTEN ACL in upsd.conf is no longer supported - switch to LISTEN ACL in upsd.conf is no longer supported - switch to LISTEN ACCEPT in upsd.conf is no longer supported - switch to LISTEN ACCEPT in upsd.conf is no longer supported - switch to LISTEN REJECT in upsd.conf is no longer supported - switch to LISTEN listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /var/state/ups is world readable Can't open /usr/local/ups/etc/ups.conf: Can't open /usr/local/ups/etc/ups.conf: Permission denied [FAILED] [r...@coyote init.d]# That was root attempting to do that. That file is currently, and I believe pursuant to the install instructions: [r...@coyote init.d]# ls -l /usr/local/ups/etc/ups.conf -rw-r- 1 root nut 95 2010-11-06 12:54 /usr/local/ups/etc/ups.conf What do I do to the perms etc so that this file is readable, both now, and during the bootup when I enable a link to it from /etc/rc5.d? Thanks. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Q: Why did the WASP cross the road? A: To get to the middle. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] still no nut at reboot
On Saturday, November 13, 2010 01:26:16 pm Charles Lepple did opine: On Nov 13, 2010, at 11:47 AM, Gene Heskett wrote: That file is currently, and I believe pursuant to the install instructions: [r...@coyote init.d]# ls -l /usr/local/ups/etc/ups.conf -rw-r- 1 root nut 95 2010-11-06 12:54 /usr/local/ups/etc/ups.conf What do I do to the perms etc so that this file is readable, both now, and during the bootup when I enable a link to it from /etc/rc5.d? Does the mandriva script have the same assumptions about the NUT username? Also, is the nut user part of the nut group? $NUTUSER in that script is 'gene' aka me. This is set by the scripts parsing of /usr/local/ups/etc/upsmon.conf. I have fixed a few other problems in it by adding local vars for $DRIVERPATH and such. It is attached. I have made some small progress with some of the other errors until I believe this is the final one. I also have not attempted as yet to port the corresponding upsmon script, nor do I have a working /etc/shutdown. That was pointed out when I walked back in the house yesterday morning to discover that the slow beeps were from the ups as everything in here was running on it, so I did a shutdown - h now. It was long enough that a similar ups in the shop also ran out, but no apparent damages otherwise except the proper rebooting of another machine that doesn't have a ups on it. Also, is this the distribution you are using? http://www.pclinuxos.com/ Yes, all uptodate a/o last night except for tar-1.24 which breaks amanda (I think, I will retest tonight. I play the canary for amanda as the snapshots are released, have for years) I printed the INSTALL file, and have now been through it from square one, checking things off as I go, restarting at step 6 at least a dozen times now, getting the no perms thing at step 8, 9 or 10. From /etc/passwd: [r...@coyote Documents]# grep ups /etc/passwd ups:x:479:415:system user for nut:/var/state/ups:/bin/false izzat ^^ ?? I've done that by hand may have it screwed up from /etc/group: [r...@coyote Documents]# grep nut /etc/group nut:x:415:ups Thanks Charles. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) National security is in your hands - guard it well. upsd Description: application/shellscript ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] nut on pclos-2010.7
On Sunday, November 07, 2010 11:00:17 am Gene Heskett did opine: On Saturday, November 06, 2010 06:39:36 pm Charles Lepple did opine: On Nov 6, 2010, at 1:47 PM, Gene Heskett wrote: So, whats next, reload the web page in a few hours? Or just ignore the warnings? ;-) Which web page does the Web Page Doctor need to visit? :-) In your case, it sounds like upsd is listening on localhost, which should work unless the web server is separate from the NUT server. It turned out that I wasn't fully grokking the web page, and once I had that figured out, it looks like its working. I was following the recipe at http://www.networkupstools.org/doc/2.2.0/INSTALL.html and got confused a bit when editing the upsmon.conf file. Looking at the example got me squared away after reading it the 3rd or so time. The error message didn't point to the error, claiming the username was wrong, when what I had actually done was to leave the master off the end of the string. Dumb. :( The continuing saga of making nut work. It seems no matter what I do, I cannot seem to get a passwordless execution of the daemon in my rc.local file which execs before anyone is logged in. I tried syntax that I use to start fetchmail, but no permission is the order of the day. I ran into that rebooting because kde was updated to 4.5.3 this morning. Does anyone have a linux nut starter/stopper that can be put in /etc/init.d, and linked to the various runlevels rcx.d's? Thanks all; -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) San Francisco isn't what it used to be, and it never was. -- Herb Caen -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) If you are too busy to read, then you are too busy. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] nut on pclos-2010.7
On Saturday, November 06, 2010 11:57:11 am Charles Lepple did opine: On Nov 5, 2010, at 2:42 PM, Gene Heskett wrote: libusb-devel I just installed. Unforch, that didn't get me the usb stuff. libusb is actually libusb1.0 here. If you do need USB support, check to see if your distribution has libusb-compat or something similar. The 1.0 version of libusb has a compatibility layer that lets programs like NUT use the 0.1 API with the 1.0 library installed. Not all distributions package that up the same way, though. It turns out the dynamic version of the -devel stuff wasn't enough, I just installed the static versions, then chowned the whole trunk tree to me, and it built as me. Synaptic has now removed the 2.4.1 rpms, so now a root make install... And that seemed successful. Now, I did have it working on mandriva back in the spring, and that drive hasn't been re-assigned, so if I can find all the stuff on that drive and move it, maybe it will work. But first use synaptic to install the K interface. Humm, that was a kde3 piece, and seems not to have made the trip to kde4.5.x yet, darn. Anyway its installed, now to find the old configs. Thanks Charles. One thing that keeps biting me, this list has no List-Header:, so when I click on reply to mail-list, I get no To: line and have to copy paste the recipients, you and the list. Is this intentional? -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Your goose is cooked. (Your current chick is burned up too!) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] nut on pclos-2010.7
On Saturday, November 06, 2010 01:04:39 pm Gene Heskett did opine: On Saturday, November 06, 2010 11:57:11 am Charles Lepple did opine: On Nov 5, 2010, at 2:42 PM, Gene Heskett wrote: libusb-devel I just installed. Unforch, that didn't get me the usb stuff. libusb is actually libusb1.0 here. If you do need USB support, check to see if your distribution has libusb-compat or something similar. The 1.0 version of libusb has a compatibility layer that lets programs like NUT use the 0.1 API with the 1.0 library installed. Not all distributions package that up the same way, though. It turns out the dynamic version of the -devel stuff wasn't enough, I just installed the static versions, then chowned the whole trunk tree to me, and it built as me. Synaptic has now removed the 2.4.1 rpms, so now a root make install... And that seemed successful. Now, I did have it working on mandriva back in the spring, and that drive hasn't been re-assigned, so if I can find all the stuff on that drive and move it, maybe it will work. But first use synaptic to install the K interface. Humm, that was a kde3 piece, and seems not to have made the trip to kde4.5.x yet, darn. Anyway its installed, now to find the old configs. Thanks Charles. One thing that keeps biting me, this list has no List-Header:, so when I click on reply to mail-list, I get no To: line and have to copy paste the recipients, you and the list. Is this intentional? PS, progress of sorts: I have followed along on the web page's install configure, editing to fix changes in the syntax according to the warnings returned, untill I get to the upsd start(which has to be done as root), and its returning this: [r...@coyote etc]# /usr/local/ups/sbin/upsd Network UPS Tools upsd 2.4.3-2672 /usr/local/ups/etc/upsd.conf is world readable upsd.conf: invalid directive LISTEN: all listening on localhost port 3493 getaddrinfo: Servname not supported for ai_socktype Now I'd assume the chmod 0640 applies to everything, and that the whole REJECT line is a no-op now. That now gets me this: [r...@coyote etc]# /usr/local/ups/sbin/upsd Network UPS Tools upsd 2.4.3-2672 listening on localhost port 3493 getaddrinfo: Servname not supported for ai_socktype [r...@coyote etc]# /usr/local/ups/sbin/upsd -c stop Network UPS Tools upsd 2.4.3-2672 fopen /var/state/ups/upsd.pid: No such file or directory So obviously it is not running, however, when I used the web page sample 'ACL' etc, it warned but ran ok (I think): [r...@coyote etc]# /usr/local/ups/sbin/upsd Network UPS Tools upsd 2.4.3-2672 ACL in upsd.conf is no longer supported - switch to LISTEN ACL in upsd.conf is no longer supported - switch to LISTEN ACCEPT in upsd.conf is no longer supported - switch to LISTEN REJECT in upsd.conf is no longer supported - switch to LISTEN listening on 127.0.0.1 port 3493 listening on ::1 port 3493 Connected to UPS [coyotes-ups]: usbhid-ups-coyotes-ups And: [r...@coyote etc]# /usr/local/ups/bin/upsc coyotes-...@localhost ups.status OL CHRG Then the whole list: [r...@coyote etc]# /usr/local/ups/bin/upsc coyotes-...@localhost battery.charge: 100 battery.charge.low: 30 battery.charge.warning: 30 battery.runtime: 120 battery.type: PbAc battery.voltage: 27.8 battery.voltage.nominal: 24 device.mfr: Belkin device.model: Belkin UPS device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: /dev/hidraw2 driver.version: 2.4.3-2672 driver.version.data: Belkin HID 0.12 driver.version.internal: 0.35 input.frequency: 60.0 input.frequency.nominal: 60 input.transfer.high: 140 input.transfer.high.max: 144 input.transfer.high.min: 140 input.transfer.low: 88 input.transfer.low.max: 88 input.transfer.low.min: 84 input.voltage: 125.9 input.voltage.nominal: 120 output.frequency: 60.0 output.voltage: 126.5 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.firmware: 1 ups.load: 30 ups.mfr: Belkin ups.model: Belkin UPS ups.power.nominal: 1500 ups.productid: 0751 ups.serial: ups.status: OL CHRG ups.test.result: Done and passed ups.timer.shutdown: 0 ups.timer.start: 0 ups.type: offline ups.vendorid: 050d So, whats next, reload the web page in a few hours? Or just ignore the warnings? ;-) Well, I thought I was fixing upsmon.conf correctly, but: [r...@coyote etc]# /usr/local/ups/sbin/upsmon Network UPS Tools upsmon 2.4.3-2672 Unable to use old-style MONITOR line without a username Convert it and add a username to upsd.users - see the documentation Fatal error: unusable configuration Sigh... Thanks Charles (no CC this time, just the list) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Some of the things that live the longest in peoples' memories never really happened. -- Cheers, Gene There are four boxes to be used in defense
Re: [Nut-upsuser] list-post header (was Re: nut on pclos-2010.7)
On Saturday, November 06, 2010 06:34:23 pm Charles Lepple did opine: On Nov 6, 2010, at 12:11 PM, Gene Heskett wrote: One thing that keeps biting me, this list has no List-Header:, so when I click on reply to mail-list, I get no To: line and have to copy paste the recipients, you and the list. Is this intentional? There is a List-Post: header with the address of the list. However, it won't help if someone like me hits reply-all and CC's the list. I guess I like seeing whether someone is directly replying to me, or if it's a general question for the list (some my mail clients make that distinction). Beyond that, though, we can't do much on the list software side - that is all handled by the Alioth staff. That pretty well explains it as from you, the list is a CC: Not a problem to me other than a reminder that I'm a geriatric idiot who can't send a proper message, because I usually get a bounce message from qmail, which relays the bounce back to me and I go Duh as I resend it using the correct gmail ident. If I have any problems that generate more traffic, I'll see if I can fix that first by unsubbing and resubbing from the tv stations server. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The cost of living hasn't affected its popularity. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] nut on pclos-2010.7
On Saturday, November 06, 2010 06:39:36 pm Charles Lepple did opine: On Nov 6, 2010, at 1:47 PM, Gene Heskett wrote: So, whats next, reload the web page in a few hours? Or just ignore the warnings? ;-) Which web page does the Web Page Doctor need to visit? :-) In your case, it sounds like upsd is listening on localhost, which should work unless the web server is separate from the NUT server. It turned out that I wasn't fully grokking the web page, and once I had that figured out, it looks like its working. I was following the recipe at http://www.networkupstools.org/doc/2.2.0/INSTALL.html and got confused a bit when editing the upsmon.conf file. Looking at the example got me squared away after reading it the 3rd or so time. The error message didn't point to the error, claiming the username was wrong, when what I had actually done was to leave the master off the end of the string. Dumb. :( -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Space is to place as eternity is to time. -- Joseph Joubert ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] nut on pclos-2010.7
On Friday, November 05, 2010 10:15:07 am Arjen de Korte did opine: Citeren Gene Heskett gene.hesk...@gmail.com: I have NDI if m4 stuff is needed or even installed, so whats next? Most likely, you don't have libtool. What does the output of libtool --version show? Best regards, Arjen command not found... Doh! Thanks. So I installed it, then: [r...@coyote trunk]# autoreconf --install libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite [r...@coyote trunk]# rm config.guess config.sub rm: remove regular file `config.guess'? y rm: remove regular file `config.sub'? y [r...@coyote trunk]# autoreconf --install libtoolize: `ltmain.sh' exists: use `--force' to overwrite [r...@coyote trunk]# rm ltmain.sh rm: remove regular file `ltmain.sh'? y [r...@coyote trunk]# autoreconf --install libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite [r...@coyote trunk]# rm ltmain.sh rm: remove regular file `ltmain.sh'? y [r...@coyote trunk]# rm config.guess config.sub rm: remove regular file `config.guess'? y rm: remove regular file `config.sub'? y [r...@coyote trunk]# autoreconf --install [r...@coyote trunk]# looks like I'm good to go for the build. However, giving ./configure the --with-all option fails, no libgd exists on pclos. I have a libgd2, and just installed some libgda3 libgda4 devel stuffs for them, plus all the pluigins for libdga4. But that also fails: checking for tcpd.h... no checking for library containing yp_get_default_domain... -lnsl checking for library containing request_init... no checking whether to enable libwrap (tcp-wrappers) support... no checking for gd version via gdlib-config... none found checking for gd include flags... checking for gd library flags... -L/usr/X11R6/lib -lgd -lpng -lz -ljpeg - lfreetype -lm -lXpm -lX11 checking for gd.h... no checking for gdfontmb.h... no checking for library containing gdImagePng... no configure: error: libgd not found, required for CGI build So where do I go from here? Many Thanks Arjen. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) * knghtbrd does the ET thing knghtbrd anybody got a speak-n-spell? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] nut on pclos-2010.7
On Friday, November 05, 2010 10:15:07 am Arjen de Korte did opine: Citeren Gene Heskett gene.hesk...@gmail.com: I have NDI if m4 stuff is needed or even installed, so whats next? Most likely, you don't have libtool. What does the output of libtool --version show? Best regards, Arjen command not found... Doh! Thanks. So I installed it, then: [r...@coyote trunk]# autoreconf --install libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite [r...@coyote trunk]# rm config.guess config.sub rm: remove regular file `config.guess'? y rm: remove regular file `config.sub'? y [r...@coyote trunk]# autoreconf --install libtoolize: `ltmain.sh' exists: use `--force' to overwrite [r...@coyote trunk]# rm ltmain.sh rm: remove regular file `ltmain.sh'? y [r...@coyote trunk]# autoreconf --install libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite [r...@coyote trunk]# rm ltmain.sh rm: remove regular file `ltmain.sh'? y [r...@coyote trunk]# rm config.guess config.sub rm: remove regular file `config.guess'? y rm: remove regular file `config.sub'? y [r...@coyote trunk]# autoreconf --install [r...@coyote trunk]# looks like I'm good to go for the build. However, giving ./configure the --with-all option fails, no libgd exists on pclos. I have a libgd2, and just installed some libgda3 libgda4 devel stuffs for them, plus all the pluigins for libdga4. But that also fails: checking for tcpd.h... no checking for library containing yp_get_default_domain... -lnsl checking for library containing request_init... no checking whether to enable libwrap (tcp-wrappers) support... no checking for gd version via gdlib-config... none found checking for gd include flags... checking for gd library flags... -L/usr/X11R6/lib -lgd -lpng -lz -ljpeg - lfreetype -lm -lXpm -lX11 checking for gd.h... no checking for gdfontmb.h... no checking for library containing gdImagePng... no configure: error: libgd not found, required for CGI build So where do I go from here? Many Thanks Arjen. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) * knghtbrd does the ET thing knghtbrd anybody got a speak-n-spell? -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Accordion, n.: A bagpipe with pleats. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of trace output)
On Saturday 02 January 2010, Jesper Klit Jensen wrote: Hi, Here are what I have done (I may be special): I created a directory in my /srv/www/nut/ where I moved all the web nut stuff into I created the nut.conf in /etc/apache2/conf.d Here that is /etc/httpd/conf.d Content of the nut.conf BEGIN ScriptAlias /nut/cgi-bin /srv/www/nut/cgi-bin Directory /srv/www/nut/cgi-bin SSLRequireSSL Options ExecCGI AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.1 allow from 10.240.120.0/24 allow from 10.240.140.0/24 allow from 10.240.150.0/24 allow from 10.240.160.0/24 /Directory Alias /nut /srv/www/nut/htdocs Directory /srv/www/nut/htdocs SSLRequireSSL Options ExecCGI AllowOverride None Options None order deny,allow deny from all allow from 127.0.0.1 allow from 10.240.120.0/24 allow from 10.240.140.0/24 allow from 10.240.150.0/24 allow from 10.240.160.0/24 /Directory END And httpd didn't like the BEGIN,END labels tossing error exits at me till they were commented out. And obviously I changed the addresses to my local network, all behind an x86 based dd-wrt firewall. Files in /srv/www/nut/ ./cgi-bin/upsset.cgi ./cgi-bin/upsimage.cgi ./cgi-bin/upsstats.cgi ./cgi-bin/.htaccess ./htdocs/header.html ./htdocs/bottom.html ./htdocs/index.html ./htdocs/nut-banner.png Hope that this helps. You can just remove the SSL part. I is just me.. A little paranoia is a good thing. ;-) Good luck Jesper On 1/1/2010 23:22, Gene Heskett wrote: On Friday 01 January 2010, Jesper Klit Jensen wrote: Hi Regarding the web part the challenge is on your web server. You need to enable the exec-cgi for the location of the cgi scripts. And where the heck is that? FF-3.5.8 IIRC. I just rescanned both the [...] I have set up a /var/www/nut tree as described above, still with the SSL, but if I include the BEGIN, END constructions in /etc/httpd/conf.d/nut.conf, restarting httpd (apache) barfs. Complains they are unterminated. Is this a fedora-ism?, it (httpd) is happy if those two lines are commented out. In FF, open a file at file:///var/www/nut/cgi-bin/upsstats-single.html and I get the dataless display I showed before, but the SSL locked icon isn't there either. Am I opening the wrong file? And a new problem stuck up its hand, palm forward when I rebooted. Now one of the hald-addon daemons has an air tight lock on /dev/hiddev0 and the driver can't start, no permissions. And because the system only reports the 1st 15 chars of the process's name, and lsof barfs if you ask for more, I have no idea which of the /usr/sbin/hald-addon* pieces to nuke. And if I kill its process number, usbhid-ups still can't start. Getting a long trace ending in: Device matches failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted Can't claim USB device [050d:0751]: could not detach kernel driver from interface 0: Operation not permitted [r...@coyote conf.d]# ls -l /dev/hiddev0 crw-rw-r-- 1 root nut 180, 0 2010-01-03 22:01 /dev/hiddev0 Ideas? Or something you've not encountered? Thank you very much for your assistance, Jesper. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) You love peace. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New problem, new thread (I think)
On Monday 04 January 2010, Arjen de Korte wrote:
Citeren Gene Heskett gene.hesk...@gmail.com:
Well, /etc/hal/fdi is now empty, and because I'd killed hald, I had to
reboot with the reset button, no keyboard or mouse, but the above
condition remains, and the nut driver is dead again for the same reason,
it cannot take possession of /dev/hiddev0 because according to htop,
hald-addon-hid-ups is listening to /dev/hiddev0 and running as root.
Ideas about this? Anybody?
Add --without-hal on the configure command line. Apparently, you used
--with-all=auto. See 'docs/nut-hal.txt' for more info on the HAL
enabled drivers.
Best regards, Arjen
I couldn't find the ./configure line in the history, and I may have. I have
now rebuilt it installed without that, and have gone through the system
nuking any *libexec/hald-* files with a date matching when I last installed
nut.
Several reboots later, I find it is working again, but I had to nuke any
hald-addon-usbhid-ups regardless of the date on the file, and I've had to
modify the /etc/init.d/ups script to start the driver directly by its name
path. So that file now looks like this (word-wrapped, dammit):
--
#! /bin/bash
#
# ups: Starts the Network UPS Tools
#
# chkconfig: - 26 74
# description: Network UPS Tools is a collection of programs which provide a
common \
# interface for monitoring and administering UPS hardware.
# processname: upsd
# config: /etc/ups/
# config: /etc/sysconfig/ups
#
### BEGIN INIT INFO
# Provides: ups
# Required-Start: $syslog $network $named
# Default-Stop: 0 1 6
# Short-Description: Starts the Network UPS tools
# Description: Network UPS Tools is a collection of programs which provide a
common \
# interface for monitoring and administering UPS hardware.
### END INIT INFO
# Source function library.
if [ -f /etc/init.d/functions ]; then
. /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ]; then
. /etc/rc.d/init.d/functions
else
exit 0
fi
# Get config.
if [ -f /etc/sysconfig/ups ]; then
. /etc/sysconfig/ups
else
SERVER=no
fi
start() {
if [ $SERVER = yes ]; then
echo -n $Starting UPS driver controller:
daemon /usr/local/bin/usbhid-ups -u ups -a myups start
/dev/null 21
success || failure
# /usr/local/bin/usbhid-ups -u ups -a myups start
RETVAL=$?
echo
prog=upsd
echo -n $Starting $prog:
daemon /usr/local/sbin/upsd $UPSD_OPTIONS /dev/null 21
success ||
failure
if [ $RETVAL = 0 ]; then
RETVAL=$?
fi
echo
echo -n $Starting UPS monitor (master):
daemon /usr/local/sbin/upsmon /dev/null 21 success ||
failure
if [ $RETVAL = 0 ]; then
RETVAL=$?
fi
echo
else
echo -n $Starting UPS monitor (slave):
daemon /usr/local/sbin/upsmon /dev/null 21 success ||
failure
echo
fi
[ $RETVAL = 0 ] touch /var/lock/subsys/ups
}
stop() {
echo -n $Stopping UPS monitor:
killproc upsmon
echo
if [ $SERVER = yes ]; then
prog=upsd
echo -n $Stopping $prog:
killproc upsd /dev/null 21 success || failure
RETVAL=$?
echo
echo -n $Shutting down upsdrvctl:
/usr/local/bin/usbhid-ups stop /dev/null 21 success ||
failure
if [ $RETVAL = 0 ]; then
RETVAL=$?
fi
echo
fi
[ $RETVAL = 0 ] rm -f /var/lock/subsys/ups
}
restart() {
stop
start
}
reload() {
# FIXME: upsd and upsmon always return 0
# = can't tell if reload was successful
if [ $SERVER = yes ]; then
action Reloading upsd: /usr/sbin/upsd -c reload
RETVAL=$?
fi
action Reloading upsmon: /usr/sbin/upsmon -c reload
if [ $RETVAL = 0 ]; then
RETVAL=$?
fi
}
# See how we are called.
case $1 in
start)
start ;;
stop)
stop ;;
restart)
restart ;;
try-restart)
[ -f /var/lock/subsys/ups ] restart || :
;;
reload)
reload ;;
force-reload)
restart ;;
status)
if [ $SERVER = yes ]; then
status upsd
fi
status upsmon
;;
*)
echo $Usage: $0
{start|stop|restart|try-restart|reload|force-reload|
status}
RETVAL=3
esac
exit $RETVAL
-
It still
Re: [Nut-upsuser] New problem, new thread (I think)
On Monday 04 January 2010, Charles Lepple wrote: On Mon, Jan 4, 2010 at 4:12 AM, Arjen de Korte nut+us...@de-korte.org wrote: Citeren Gene Heskett gene.hesk...@gmail.com: Well, /etc/hal/fdi is now empty, and because I'd killed hald, I had to reboot with the reset button, no keyboard or mouse, but the above condition remains, and the nut driver is dead again for the same reason, it cannot take possession of /dev/hiddev0 because according to htop, hald-addon-hid-ups is listening to /dev/hiddev0 and running as root. Ideas about this? Anybody? Add --without-hal on the configure command line. Apparently, you used --with-all=auto. See 'docs/nut-hal.txt' for more info on the HAL enabled drivers. Actually, if it is hald-addon-hid-ups and not hald-addon-usbhid-ups, then that probably came from the upstream HAL project, not from NUT. (I don't really know what the recommended procedure is there, since most of my Linux boxes are command-line only.) Gene: do I understand correctly that this is Mandriva 2010? It could be Charles, but this install is on (hd0), aka a fedora 10 install. And I'm at the point where I'm trying to find all the gotcha's. I have it working again, but had to nuke every hald-addon-usbhid-ups file on the system to do it, and I have to start that driver directly by its name, upsdrvctl is failing in the startup scripts. Once I get it here, moving to mandriva x64 should be a matter of copying the src tree, doing a make clean and a reconfigure/build/install. (says he, ever the optimist) Arnaud, any recommendations as to the right way to disable this? -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) If God is perfect, why did He create discontinuous functions? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] New problem, new thread (I think)
Greets all; I was just booted to mdv-2010-x64 where I found my lack of sound problems. Whoopy ding... But when I rebooted to fedora, now the driver cannot disconnect and gain access to the ups. I installed the 52-nut udev file in /etc/udev.d, and it reads that it should setup /dev/hiddev0 like this and with 0664 perms when it finds that ups: crw-rw-r-- 1 root nut 180, 0 2010-01-03 20:51 /dev/hiddev0 where hiddev0 is the ups port. But now the usbdrvctl, using usbhid-ups as the driver, reports: [r...@coyote etc]# upsdrvctl start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - Generic HID driver 0.34 (2.4.1) USB communication driver 0.31 Can't claim USB device [050d:0751]: could not detach kernel driver from interface 0: Operation not permitted Driver failed to start (exit status=1) From the /etc/group file: nut:x:57:ups From the /etc/passwd file: nut:x:57:57:Network UPS Tools:/var/lib/ups:/bin/false ups:x:506:506::/home/ups:/bin/bash The passwd for ups is in both the passwd file, and AFAIK in the nut config files, and they match. And this was working pretty good before I rebooted. Ideas anybody? Maybe I found it, an lsof|grep hiddev0 spits out: hald-addo 3157 root4r CHR 180,0 0t0 1416 /dev/hiddev0 Killed, as was the 52 script in /etc/hal/fdi. Reboot time. Thanks all. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Emerson's Law of Contrariness: Our chief want in life is somebody who shall make us do what we can. Having found them, we shall then hate them for it. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New problem, new thread (I think)
On Sunday 03 January 2010, Gene Heskett wrote: Greets all; [...] Maybe I found it, an lsof|grep hiddev0 spits out: hald-addo 3157 root4r CHR 180,0 0t0 1416 /dev/hiddev0 Killed, as was the 52 script in /etc/hal/fdi. Reboot time. Well, /etc/hal/fdi is now empty, and because I'd killed hald, I had to reboot with the reset button, no keyboard or mouse, but the above condition remains, and the nut driver is dead again for the same reason, it cannot take possession of /dev/hiddev0 because according to htop, hald-addon-hid-ups is listening to /dev/hiddev0 and running as root. Ideas about this? Anybody? Thanks all. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) At work, the authority of a person is inversely proportional to the number of pens that person is carrying. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Saturday 02 January 2010, Charles Lepple wrote: On Fri, Jan 1, 2010 at 10:28 PM, Gene Heskett gene.hesk...@gmail.com wrote: Now, how do I get it to display the status, in a terminal screen, gui from a menu, or in firefox, the statistics it is outputting? I ask because on the nut web pages, both links under this section of the docs: - Web-based monitoring * Comes stock with CGI-based web interface tools for UPS monitoring and management, including graphical status displays. * Custom status web pages may be generated with the CGI programs, since they use templates to create the pages. This allows you to have status pages which fit the look and feel of the rest of your site. -- Are 404's. Which links are you referring to? I'm looking here, and I don't see any links: http://new.networkupstools.org/user-manual.html#_web_based_monitoring I bookmarked that page, but the bookmark didn't save the sublink, so I cannot find it again. I am amazed at the amount of nut docs out there, often for much older and no longer applicable versions. All I can do is open the .conf file, set an option, see if it survives a restart of either nut, or httpd as the case may be. 75% or more of the time it errors and dies cuz that option, there and commented out in the scripts, is no longer supported by one or the other. If I feed upsstats.cgi (or either of the other 2 .cgi scripts) all firefox wants to do is download them rather than displaying them. Then if I feed the file upsstats.html to FF, it displays the file with color backgrounds on a per column basis, but no data. As Jesper mentioned, the CGI scripts are designed to be executed by the web server. And this install, for some reason, does not have a 'cgi.conf' file in /etc/httpd/* It does have a scgi.conf and a speedycgi.conf, both of which I have enabled, and got a bunch of errors for the options in them so those options had to be commented back out else httpd dies. This page has a bunch of default locations for components of Apache, which was the default web server in Fedora the last time I checked: http://wiki.apache.org/httpd/DistrosDefaultLayout#Fedora_Core.2C_CentOS.2C_ RHEL: Very very old, not generally applicable as its for nut-1.4.1. Assuming this is correct, you would want to put upsstats.cgi in /var/www/cgi-bin (with the execute bits turned on), and search for that path in /etc/httpd to see if it was just commented out of the configuration file. I am in the middle of that right now, and I believe I have done everything that link recommends except those which cause errors when httpd is restarted, set the exec (chmod +x) bits on everything. But firefox either can't find it, or wants to download an amiga compressed archive when I open upsstats.cgi. Humm, re searching the path, where pwd=/etc/httpd: [r...@coyote httpd]# grep -R cgi-bin * conf/httpd.conf:ScriptAlias /cgi-bin/ /var/www/cgi-bin/ conf/httpd.conf:# /var/www/cgi-bin should be changed to whatever your ScriptAliased conf/httpd.conf:Directory /var/www/cgi-bin conf/httpd.conf:#ErrorDocument 404 /cgi-bin/missing_handler.pl conf.d/squid.conf:ScriptAlias /Squid/cgi-bin/cachemgr.cgi /usr/lib/squid/cachemgr.cgi conf.d/squid.conf:Location /Squid/cgi-bin/cachemgr.cgi conf.d/awstats.conf:ScriptAlias /awstats/ /usr/share/awstats/wwwroot/cgi- bin/ conf.d/ssl.conf:Directory /var/www/cgi-bin logs/access_log:127.0.0.1 - - [02/Jan/2010:12:30:53 -0500] GET /gene/cgi-bin HTTP/1.1 404 285 - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 logs/error_log:[Sat Jan 02 12:30:53 2010] [error] [client 127.0.0.1] File does not exist: /var/www/html/gene/cgi-bin That last error I made by trying to access it from the FF url box, so its to be ignored. I also was not aware that the -R opt to grep made it follow simlinks, interesting as that also hangs and must be ctl+c'd to get my prompt back.. Now, if I change my grep search to 'speedy', I get this: [r...@coyote httpd]# grep -R speedy * conf.d/speedycgi.conf:LoadModule speedycgi_module modules/mod_speedycgi.so conf.d/speedycgi.conf:# This will allow execution of mod_speedycgi to make your webbased conf.d/speedycgi.conf:Alias /speedy /var/www/speedy conf.d/speedycgi.conf:Directory /var/www/speedy conf.d/speedycgi.conf:SetHandler speedycgi-script conf.d/speedycgi.conf:# If non-zero, limits the number of speedy backends running for Anyway, the contents of the designated cgi-bin directory are: [r...@coyote cgi-bin]# ls -l total 104 -rwxr-xr-x 1 root nut 25620 2009-12-30 21:51 upsimage.cgi -rwxr-xr-x 1 root nut 30082 2009-12-30 21:51 upsset.cgi -rwxr-xr-x 1 root nut 30455 2009-12-30 21:51 upsstats.cgi -rwxr-xr-x 1 root nut 3883 2010-01-02 04:43 upsstats.html -rwxr-xr-x 1 root nut 5592 2009-06-02 11:54 upsstats-single.html And the contents of that designated /var/www/speedy: [r...@coyote speedy]# ls -l total 104 -rwxr-xr-x 1 root nut
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Saturday 02 January 2010, Charles Lepple wrote: On Jan 2, 2010, at 1:26 PM, Gene Heskett wrote: This page has a bunch of default locations for components of Apache, which was the default web server in Fedora the last time I checked: http://wiki.apache.org/httpd/DistrosDefaultLayout#Fedora_Core.2C_CentOS. 2C_ RHEL: Very very old, not generally applicable as its for nut-1.4.1. Hmm? That link is describing the layout for Apache httpd, nothing specifically for NUT. [...] Locating mod_cgi: [r...@coyote httpd]# locate mod_cgi /usr/lib/httpd/modules/mod_cgi.so /usr/lib/httpd/modules/mod_cgid.so /usr/lib64/httpd/modules/mod_cgi.so /usr/lib64/httpd/modules/mod_cgid.so /usr/libexec/webmin/apache/mod_cgi.pl /var/www/manual/mod/mod_cgi.html /var/www/manual/mod/mod_cgid.html And [r...@coyote httpd]# grep -R mod_cgi * conf/httpd.conf:LoadModule cgi_module modules/mod_cgi.so I am pretty sure that mod_cgi is the CGI module you want. Yes, it is present and being loaded by /etc/httpd/httpd.conf, and I have the .cgi scripts installed in every possible location. Doesn't make any diff. upsc myups output: [r...@coyote httpd]# upsc myups battery.charge: 100 battery.charge.low: 30 battery.charge.warning: 30 battery.runtime: 120 battery.type: PbAc battery.voltage: 27.7 battery.voltage.nominal: 24 driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.4.1 driver.version.data: Belkin HID 0.12 driver.version.internal: 0.34 input.frequency: 60.0 input.frequency.nominal: 60 input.transfer.high: 140 input.transfer.high.max: 144 input.transfer.high.min: 140 input.transfer.low: 88 input.transfer.low.max: 88 input.transfer.low.min: 84 input.voltage: 126.7 input.voltage.nominal: 120 output.frequency: 60.0 output.voltage: 126.3 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.firmware: 1 ups.load: 32 ups.mfr: Belkin ups.model: Belkin UPS ups.power.nominal: 1500 ups.productid: 0751 ups.serial: ups.status: OL CHRG ups.test.result: Done and passed ups.timer.shutdown: 0 ups.timer.start: 0 ups.type: offline ups.vendorid: 050d So that is all working. So I guess my next question is: Is the firefox mimetypes file busted? If so, where do I edit it? This is FF-3.5.6 I believe. An hour later while this message reply simmers on desktop 8: Aha! Voila! I found a display gui that works, more or less. KNutClient-0.9.5.tar.gz, installed with the fedora script, then copied the knutclient.desktop for it to my Desktop folder a wee bit of configuration, and its displaying about half the stuff I moved to the right hand column. That is enough to at least let me know its healthy, with meters and blinkenlites. ;) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The data on your hard drive is out of balance. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Thursday 31 December 2009, Gene Heskett wrote: Update after another day recuperating, including watching The Mountaineers hand Bobby Bowden a final win to end his career with, in the Sugar Bowl. 1. By moving the ups's data cable from an external hub to a direct to the motherboard socket, the lockouts and reports of another process, un-named, interfering with usbhid-ups have disappeared. Totally. 2. The init.d/ups script starts the correct usbhid-ups driver with upsdrvctl but outputs a FAIL even though htop can see it running with the -a myups argument. I finally figured out how to configure the fedora's /etc/sysconfig/ups file so that all that works as expected (I think it is anyway) 3. A final tweak in the upsd.conf enabling the 'master' setting, and upsmon also seems happy and it is no longer spamming the messages log. Now, how do I get it to display the status, in a terminal screen, gui from a menu, or in firefox, the statistics it is outputting? I ask because on the nut web pages, both links under this section of the docs: - Web-based monitoring * Comes stock with CGI-based web interface tools for UPS monitoring and management, including graphical status displays. * Custom status web pages may be generated with the CGI programs, since they use templates to create the pages. This allows you to have status pages which fit the look and feel of the rest of your site. -- Are 404's. If I feed upsstats.cgi (or either of the other 2 .cgi scripts) all firefox wants to do is download them rather than displaying them. Then if I feed the file upsstats.html to FF, it displays the file with color backgrounds on a per column basis, but no data. I put a screen snapshot of that at http://gene.homelinux.net:85/gene/pix/upsstats-firefox.jpg for your perusal. Any more ideas that can be thrown my way would be encouraging. And 4th, should I bugzilla the usb stacks inability to share a cable to a hub without making a mess of it? And finally, many thanks for your patience so far. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) It is not enough to have great qualities, we should also have the management of them. -- La Rochefoucauld ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Thursday 31 December 2009, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: There is also a missing /etc/sysconfig/ups file, which I have NDI what to put into, so that bit of code in the init.d/ups is commented out, and SERVER=master is set in it. NUT doesn't use a /etc/sysconfig/ups file (this is probably added by Fedora). And I don't know that the file ever existed on my system, ever. So that part of the init script has been disabled. Do yourself a favor and ask for help on a Fedora mailing list and preferably find some pre-compiled RPM's to install on your system. I don't have the time, nor the energy to talk you trough all stages of building NUT for Fedora (or any other distro, for that matter). Building from sources is clearly not something for you (no pun intended). Building from srcs is not a problem, but one does have an expectation of reasonable defaults. Only an amanda build, which I may do several times a week, requires a longer ./configure line than I used to build the last version of 2.4.1. That, long since, 10 years ago for the 1st version, has been carved into a build script, so my fumble fingers don't have to get it right every time. This I think, should also be made into a script so that if I can get it working, the next release should too. FWIW Arjen, I routinely build my own kernels, and just as routinely build each development snapshot of amanda, the backup program. And I have been carving code, often in assembly, or in my first 2 projects in the late 1970's in hexidecimal, entering it into memory with a hex monitor. Currently running kernel 2.6.32, and have tried 2.6.32.2 but found its usb support broken, and have tried 2.6.33-rc2, which was a disaster, dying in less than an hour with lots of stuff not working from the gitgo. You requested logs, which I sent, and which were not commented on in any reply I received. Those logs show the usbhid-ups/belkin driver combination losing comm with the ups and having to redo its search for the ups several times a minute, but you apparently sent them to /dev/null. Were I the coder for that piece of code, that would have raised all sorts of red flags. This loss of comm is the reason I cannot run upsmon as its setup now, but usbhid-ups is showing in an htop display, running as the user ups. So is upsd, also running as the user ups. Not by the init script, I still need to fine tune that. but if I start upsmon, then the kde write daemon floods my screens with comm lost, can't comm, and comm restored messages, which also spam the logs. The instructions in the example files are even occasionally miss-leading, and I just found from an error message, that the allowfrom has been deprecated but not removed from one of the .conf files. I believe, if the comm problems can be sorted, that I may have a working setup all I have to do is fine tune the /etc/init.d script to re-establish what is running right now. So the end is in sight, and its a poor time to bail out now.. I'm sorry, but the best advice I can give you here is to find an RPM where this is already done for you. Which I have explained is not available for F10. I'm thinking of moving to a mandriva 2010x64 install, but I don't recall seeing nut available in rpmdrake. Best regards, Arjen Thanks Arjen. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Griffin's Thought: When you starve with a tiger, the tiger starves last. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] missing /etc/sysconfig/ups (former My previous post (lengthy, lots of trace output))
On Thursday 31 December 2009, Manuel Wolfshant wrote: On 12/31/2009 01:04 PM, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: There is also a missing /etc/sysconfig/ups file, which I have NDI what to put into, so that bit of code in the init.d/ups is commented out, and SERVER=master is set in it. NUT doesn't use a /etc/sysconfig/ups file (this is probably added by Fedora). rhel / fedora and derivatives use /etc/sysconfig/servicename for configuration files which are sourced by the initscripts (placed in /etc/init.d/servicename). That would seem to be the case, used mostly for setting $SERVER and $UPS_OPTIONS which are then passed to the various daemons that need them. When I found that I couldn't pass the' -D -D -D -D -D -u user' stuff in it, and I had to hard code it instead, that section was a wart to be excised with a series of #. As a side note, a correctly written initscript will not care if there is no sysconfig file , using sane defaults instead. This was, if that file was empty of missing, then $UPS_OPTIONS was null, as it should be. Thank you Manuel. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Bang on the LEFT side of your computer to restart Windows. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Thursday 31 December 2009, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: You requested logs, which I sent, and which were not commented on in any reply I received. Those logs show the usbhid-ups/belkin driver combination losing comm with the ups and having to redo its search for the ups several times a minute, but you apparently sent them to /dev/null. Were I the coder for that piece of code, that would have raised all sorts of red flags. OK, here you go. The following occurs several times in this log: Got disconnected by another driver: Device or resource busy This means you've been running multiple instances of usbhid-ups in parallel, which I explicitly told you not to do. You can expect this kind of a mess then, which makes the remainder of the log useless. I saw that, killed all of them and restarted just one instance, which was what was running when I made that log. My logs are being spammed right now by only one instance of usbhid-ups running. - Dec 31 08:45:47 coyote upsd[888]: Data for UPS [myups] is stale - check driver Dec 31 08:45:58 coyote upsd[888]: UPS [myups] data is no longer stale Dec 31 08:46:21 coyote upsd[888]: Data for UPS [myups] is stale - check driver Dec 31 08:46:50 coyote upsd[888]: UPS [myups] data is no longer stale Dec 31 08:46:55 coyote upsd[888]: Data for UPS [myups] is stale - check driver Dec 31 08:47:28 coyote upsd[888]: UPS [myups] data is no longer stale Dec 31 08:47:47 coyote upsd[888]: Data for UPS [myups] is stale - check driver Dec 31 08:48:02 coyote upsd[888]: UPS [myups] data is no longer stale Dec 31 08:48:09 coyote upsd[888]: Data for UPS [myups] is stale - check driver Dec 31 08:48:30 coyote upsd[888]: UPS [myups] data is no longer stale Dec 31 08:48:47 coyote upsd[888]: Data for UPS [myups] is stale - check driver Dec 31 08:49:40 coyote upsd[888]: UPS [myups] data is no longer stale Dec 31 08:49:53 coyote upsd[888]: Data for UPS [myups] is stale - check driver - [r...@coyote grub]# ps -ae|grep ups 766 ?00:00:12 usbhid-ups 888 ?00:00:00 upsd 3136 ?00:00:00 cupsd Humm, I was just reminded by something I wrote on another ML, I have an 8Gb usbkey plugged in, and quite a few other usb devices that connect as storage devices. Storage devices, and the latencies caused by scanning them, can and have totally wrecked parts being cut by my cnc milling machine. I wonder if that same mechanism is at work here. So I'll unplug everything 'storage' except the printer, an All-In-one which has a (*% card reader in it. It may have changed, but didn't fix. Here is a little more of the log, while I had upsmon running for a short time: -- Dec 31 10:19:37 coyote upsd[888]: User u...@127.0.0.1 logged into UPS [myups] Dec 31 10:19:37 coyote upsmon[12804]: Master privileges unavailable on UPS [my...@localhost] Dec 31 10:19:37 coyote upsmon[12804]: Response: [ERR ACCESS-DENIED] - Huh? It is _not_ reporting that one-screen. A clue! - Dec 31 10:19:42 coyote upsmon[12804]: Poll UPS [my...@localhost] failed - Data stale Dec 31 10:19:42 coyote upsmon[12804]: Communications with UPS my...@localhost lost Dec 31 10:19:42 coyote wall[12807]: wall: user ups broadcasted 1 lines (46 chars) Dec 31 10:19:47 coyote upsmon[12804]: Poll UPS [my...@localhost] failed - Data stale Dec 31 10:19:47 coyote upsmon[12804]: UPS my...@localhost is unavailable Dec 31 10:19:47 coyote wall[12816]: wall: user ups broadcasted 1 lines (36 chars) Dec 31 10:19:52 coyote upsmon[12804]: Poll UPS [my...@localhost] failed - Data stale [...] Dec 31 10:21:22 coyote upsmon[12804]: Poll UPS [my...@localhost] failed - Data stale Dec 31 10:21:23 coyote upsmon[12804]: Signal 15: exiting Dec 31 10:21:23 coyote upsd[888]: User u...@127.0.0.1 logged out from UPS [myups] Should I be using slave in the MONITOR line? Or should I just gzip the .conf dir and send it? [...] The instructions in the example files are even occasionally miss-leading, and I just found from an error message, that the allowfrom has been deprecated but not removed from one of the .conf files. True, and this is already fixed in the development version and will only log an informational message, nothing more, nothing less. It's this kinds of comments that bothers me the most in your replies and which makes it harder and harder for me to start reading yet another reply from you. Sorry Arjen, but to me, not knowing where your bugzilla might be, I look at that as a bug report, and its certainly not intended to be a personal attack. [...] I'm sorry, but the best advice I can give you here is to find an RPM where this is already done for you. Which I have explained is not available
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Thursday 31 December 2009, Christopher X. Candreva wrote: On Thu, 31 Dec 2009, Arjen de Korte wrote: Do yourself a favor and ask for help on a Fedora mailing list and preferably find some pre-compiled RPM's to install on your system. I don't have the time, That would have been easier a week or 2 ago. :-) From the thread I think he's running Fedora 10, which is now End of Lifed. He may be able to get the nut packages from the distro CD,but no updates. Gene, if you are running Fedora 10, an update to 12 would be well worth it, and the nut rpm's are in the standard repo Maybe, but the upgrade reports have been a bit 'disconcerting' with their horror details, and I expect the upgrade would upchuck all over itself cuz anaconda is hard coded for a far different disk partitioning scheme than is running here. This is my main box of 4, and it has a place of I can't die, it's not my time yet even if I could, at 75 diabetic, my warranty expired 75+ years ago. ;-) Thanks Chris. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Goes (Went) over like a lead balloon. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Wednesday 30 December 2009, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: 2.4.1 now installed, using default ./configure I had to make a bunch of directories move all the .conf files cuz the config path seems scrambled, its /usr/local/ups/etc, s/b /usr/local/etc/ups IMO. Bug? No, you didn't read the INSTALL file. These are the build in defaults if you don't tell configure where it should install things. Ya mean its not the usual boilerplate? ;) IMO the defaults should at least be sane. The above line still fails, but a different failure, a snip from the end of its output when the above line is executed from the drivers src dir: - Checking device (050D/0751) (001/005) - VendorID: 050d - ProductID: 0751 - Manufacturer: unknown - Product: unknown - Serial Number: unknown - Bus: 001 Trying to match device Device matches failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted Can't claim USB device [050d:0751]: could not detach kernel driver from interface 0: Operation not permitted [r...@coyote drivers]# --- Most likely, the same problem as above. Either the files required for hotplugging are not installed or they have other user and group settings. And indeed, ttyUSB0 is owned by heyu on this box. ;-) The usbhid-ups driver doesn't use ttyUSB0, so I fail to see why you bring this up. Because nothing that might be germane should be left out, you are the expert on 'germane' ;) This error is identical regardless of the user launching it, root included. The driver should *always* be launched by root, regardless of the configure settings. You could try to work around the permissions problems temporarily by adding the '-u root' flag to the startup command line, so that the driver doesn't drop privileges to whatever user it is configured to use. And if I don't, its no permissions on /var/state/ups, with, the rebuilt, reinstalled version works about 10% of the time, the rest of the time the device doesn't match. /var/state/ups is 0770 and owned by root:nut as the INSTALL says. All user:group settings are now according to that file. I do believe however, that you'd better search for a pre-compiled RPM version from Fedora instead. This would save you all the hassle of finding out which configure options you need (this can be dozens). The fedora is too old, the 2.2.2 I nuked was the newest available. Best regards, Arjen Thanks Arjen. I've reconfigured reinstalled. A 1 minute log capture is attached again. Oddity was I had to use the file 21 syntax, and I had to launch it as -a root. But the install is still placing stuff in odd places. This is getting old, so I'll rebuild again, specifying --PREFIX=/usr this time. Finding the binaries installed in a directory that it appears I can only get in the exec $PATH by rebooting is a PIMA. This _isn't_ windows! Thanks Arjen. Back after I do that, promise. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Revolution, n.: A form of government abroad. usbhid-ups.log.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Wednesday 30 December 2009, Gene Heskett wrote: On Wednesday 30 December 2009, Arjen de Korte wrote: [...] Thanks Arjen. Back after I do that, promise. Ok, back. I have it running, sort of. But it keep losing comm with the ups. I started it with the usbhid-ups _d _d _d -a myups, and htop shows its running as the user 'ups', so that's one small victory. Now, I have done a single 'service ups start' which reports success for the monitor I believe. But, I have moved the cgi-bin/ups tree to nearly every directory on my drive, but when I open the 'index.html' file in firefox, the lower two buttons always report: Firefox can't find the file at /cgi-bin/nut/upsstats.cgi. This install was built with --prefix=/usr. Surely it doesn't want /cgi-bin off the root of the drive? But if I make a /cgi-bin, and move /var/www/cgi- bin/nut to /cgi-bin/nut, now its asking me what to do with an amiga compressed archive named upsstats.cgi when I click on stats, ditto for the config when I click on it. Something is confused here, and I don't think its all me. Where do I put those miss-placed files so it stands a snowballs chance in that famous place of working? Better yet, edit this ./configure line so that it Just Works(TM), with the cgi-bin stuff actually installed in /var/www/cgi-bin like it should be. [r...@coyote nut-2.4.1]# ./configure --with-user=ups --with-group=nut --with- usb --with-cgi --with-hal --with-lib --prefix=/usr And restarting it with the /etc/init.d/ups script fails yet. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Mal: When you can't run anymore, you crawl, and when you can't do that, you find someone to carry you. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Wednesday 30 December 2009, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: No, you didn't read the INSTALL file. These are the build in defaults if you don't tell configure where it should install things. Ya mean its not the usual boilerplate? ;) IMO the defaults should at least be sane. The defaults are sane. It's actually good practice to install stuff to /usr/local, I have no argument with that, what I argue with is the making of a ups subdir in all these paths, with an etc subdir in each of those. to prevent people from accidentally overwriting the version provided by a distribution. If you do want to install it in the location that are used by *your* distro, you'll have to explicitly tell configure where this is (since this varies with distribution and architecture). Not all *NIX systems are alike. [...] And if I don't, its no permissions on /var/state/ups, with, the rebuilt, reinstalled version works about 10% of the time, the rest of the time the device doesn't match. Make sure there are no 'usbhid-ups' drivers running in the background. There weren't. although making that run seems easy enough. I'm burnt out on this today, I've installed it to at least 4 locations, none of which is compatible with itself, or with what I read in the manpages. I can, by hand. make the daemon usbhid-ups run by hand with the triplet of - D's a -a myups, and I can make upsd run, but I simply do not understand how uspmon runs. I did have it running on a one shot basis from the cli at one point, but when I tried to hard code the locations in the /etc/init.d/ups start/stop file, its a total failure for upsmon. On the one hand you say it doesn't need passwd's, and recommend not to put them in the upsd.users and upsmon.users file, but at the moment it appears I must, however the user 'ups' has no passwd set. So despite the manpage showing 'MONITOR my...@localhost master', that fails. There is also a missing /etc/sysconfig/ups file, which I have NDI what to put into, so that bit of code in the init.d/ups is commented out, and SERVER=master is set in it. And whatever I've done now, upsdrvctl also fails. I'm back to: [r...@coyote nut-2.4.1]# upsdrvctl start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - Generic HID driver 0.34 (2.4.1) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 Can't initialize data from HID UPS Driver failed to start (exit status=1) Again with no clue why. I'm burned out on this. For today anyway. Best regards, Arjen -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) It's not reality that's important, but how you perceive things. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Wednesday 30 December 2009, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: Something is confused here, and I don't think its all me. Where do I put those miss-placed files so it stands a snowballs chance in that famous place of working? I honestly don't know. I don't use Fedora, so I don't have the slightest clue where to install them. If you can't figure this out yourself, find some Fedora people who do. Better yet, edit this ./configure line so that it Just Works(TM), with the cgi-bin stuff actually installed in /var/www/cgi-bin like it should be. On Fedora maybe. Not on my system and most likely not on many others too. Again, the options you pass to ./configure depend on the distro/architecture you're using. [r...@coyote nut-2.4.1]# ./configure --with-user=ups --with-group=nut --with- usb --with-cgi --with-hal --with-lib --prefix=/usr This isn't nearly enough. If you want to enable CGI support, you'll probably need --with-cgipath too. See the following from INSTALL: See docs/configure.txt or ./configure --help for the available options. You'll have to specify most options that are listed in the first reference (and maybe even more). Best regards, Arjen Ok, rebuilt, reinstalled yet again. From the command line: -- [r...@coyote nut-2.4.1]# upsdrvctl -D -D -D -D -D start Network UPS Tools - UPS driver controller 2.4.1 Starting UPS: myups exec: /usr/local/bin/usbhid-ups -a myups Network UPS Tools - Generic HID driver 0.34 (2.4.1) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 note total lack of verbosity -- [r...@coyote nut-2.4.1]# upsd [1] 21301 [r...@coyote nut-2.4.1]# Network UPS Tools upsd 2.4.1 ACL in upsd.conf is no longer supported - switch to LISTEN ACL in upsd.conf is no longer supported - switch to LISTEN ACCEPT in upsd.conf is no longer supported - switch to LISTEN REJECT in upsd.conf is no longer supported - switch to LISTEN listening on 127.0.0.1 port 3493 listening on ::1 port 3493 Connected to UPS [myups]: usbhid-ups-myups [1]+ Doneupsd cool but [r...@coyote nut-2.4.1]# upsmon Network UPS Tools upsmon 2.4.1 Unable to use old-style MONITOR line without a username Convert it and add a username to upsd.users - see the documentation Fatal error: unusable configuration [r...@coyote nut-2.4.1]# Thanks for your patience. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The trouble with superheros is what to do between phone booths. -- Ken Kesey ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] My previous post (lengthy, lots of tarace output)
Ping? -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) What does it mean in the sentence What time is it?? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Tuesday 29 December 2009, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: Ping? I didn't comment to that message (for exactly the reasons in the subject field) and you seemed to be in the process of figuring stuff out yourself (which we prefer, since then people actually learn, instead of us developers telling them how to do things). Which I would rather do too, as its remembered better even at my age. But apparently you've hit a brick wall in the process. Please post the present status of the 1) usbhid-ups (driver) [r...@coyote pix]# usbhid-ups -a myups Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) Using subdriver: Belkin HID 0.11 Can't initialize data from HID UPS 2) if 1) is running, the upsd (server) not running 3) if 2) is running, the upsmon (client) if started, will flood the screen with comm lost advisories about every 10 seconds till killed. They all need to be up and running in this order. It's a waste of effort to try to run the upsd server, if the driver isn't running properly. So the first you need to do is make sure you have a running driver. The line /path/to/usbhid-ups -DDD -a yourups should result in a continuous flow of information. Dump the output of the first 60 seconds in a logfile, gzip it and attach the result to a message. Done. It might also help to upgrade to a more recent version of NUT (2.4.1), since the version you're running now (2.2.2) seems to be quite outdated. Just pulled the 2.4.1 tarball, fedora 10 is EOL'd 2.2.2 is it in rpms, and even rpmfind was helpless. I'll put it in before I screw with this again. Best regards, Arjen PS Don't post strace output, since unless you know exactly what you're looking for, it will just wastes bandwidth. The right amount of -D options is easier on our eyes. I have to agree, one can go plumb cross-eyed looking for the original error line in a 10,000 line output. I'm not sure if at that time I had managed to find a manpage describing the -D option, which, at least for the fedora version, does not descend into the exec line of a subdriver, thereby losing the data you really wanted. There really does need to be a man or info page for nut, even if its just a listing of the pieces. That would be a lot of help for the 'first timers'. :) Thanks Arjen. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) A list is only as strong as its weakest link. -- Don Knuth ups.log.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Tuesday 29 December 2009, Arjen de Korte wrote: 2.4.1 now installed, using default ./configure I had to make a bunch of directories move all the .conf files cuz the config path seems scrambled, its /usr/local/ups/etc, s/b /usr/local/etc/ups IMO. Bug? The line /path/to/usbhid-ups -DDD -a yourups should result in a continuous flow of information. Dump the output of the first 60 seconds in a logfile, gzip it and attach the result to a message. It might also help to upgrade to a more recent version of NUT (2.4.1), since the version you're running now (2.2.2) seems to be quite outdated. Best regards, Arjen PS Don't post strace output, since unless you know exactly what you're looking for, it will just wastes bandwidth. The right amount of -D options is easier on our eyes. The above line still fails, but a different failure, a snip from the end of its output when the above line is executed from the drivers src dir: - Checking device (050D/0751) (001/005) - VendorID: 050d - ProductID: 0751 - Manufacturer: unknown - Product: unknown - Serial Number: unknown - Bus: 001 Trying to match device Device matches failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted Can't claim USB device [050d:0751]: could not detach kernel driver from interface 0: Operation not permitted [r...@coyote drivers]# --- And indeed, ttyUSB0 is owned by heyu on this box. ;-) Or is it referring to the hiddev0 and hidraw0, which only exists after the data cable is freshly plugged in. A more verbose description of 'USB device' would help to define what the error really is. ;) This error is identical regardless of the user launching it, root included. Thanks Arjen. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Experience varies directly with equipment ruined. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Old thread on belkin
On Monday 28 December 2009, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: Just starting it with the fedora service command gets this: [r...@coyote rules.d]# service ups start /etc/sysconfig/ups: line 4: UPSD_OPTIONS: command not found Starting UPS driver controller:[FAILED] Starting upsd: [FAILED] Starting UPS monitor (master): [FAILED] UPSD_OPTIONS is empty in /etc/sysconfig/ups We've have issues with the Fedora (and RedHat) scripts before. NUT doesn't use /etc/sysconfig/ups, this is something that your distro added. Nuked. Chances are that this was written for an earlier version of NUT and since never changed. It's not needed either, since all information needed to startup the drivers, server and clients is in the NUT configuration files already. Could you try if running /path/to/upsdrvctl start As root, permission for /var/run/nut denied. chowned it gene:gene, get this: [r...@coyote ups]# su gene -c upsdrvctl start Network UPS Tools - UPS driver controller 2.2.2 Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) No matching HID UPS found Driver failed to start (exit status=1) No idea if that's an earlier or later message. No mesg in log for either. /path/to/upsd /path/to/upsmon improves the situation? For debugging purposes you shouldn't use the startup scripts from *any* distribution, because they will invariably direct the startup messages to /dev/null (it might already tell you what's wrong now). I took the /dev/null junk out of the /etc/init.d/ups (start) section for the next attempts. This is the STATEPATH directory (which is compiled in) and should be writeable by the user 'upsd' is running as. It almost certainly isn't. How does one determine what user its trying to run at? A service ups start (as root) got me this on screen [r...@coyote ups]# service ups start Starting UPS monitor (slave): [ OK ] And a bunch of error popups because it couldn't talk to my...@localhost And this in the log: Dec 28 09:48:03 coyote upsmon[25030]: UPS [my...@localhost]: connect failed: Connection failure: Connection refused Repeated till I stop upsmon, same if I address it as my...@fqdn. So I chmod-ed /var/run/nut to 0777 which should let anybody write the SOB. [r...@coyote ups]# su gene -c upsdrvctl start Network UPS Tools - UPS driver controller 2.2.2 Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) No matching HID UPS found Driver failed to start (exit status=1) [r...@coyote ups]# upsdrvctl start Network UPS Tools - UPS driver controller 2.2.2 Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) Using subdriver: Belkin HID 0.11 Can't initialize data from HID UPS Driver failed to start (exit status=1) [r...@coyote ups]# This headache is approaching the excedrin numbering system. Best regards, Arjen Thanks Arjen. I'll do an strace on it once the morning coffee has kicked in. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) New Hampshire law forbids you to tap your feet, nod your head, or in any way keep time to the music in a tavern, restaurant, or cafe. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Old thread on belkin
On Monday 28 December 2009, Arjen de Korte wrote:
Citeren Gene Heskett gene.hesk...@gmail.com:
Just starting it with the fedora service command gets this:
[r...@coyote rules.d]# service ups start
/etc/sysconfig/ups: line 4: UPSD_OPTIONS: command not found
Starting UPS driver controller:[FAILED]
Starting upsd: [FAILED]
Starting UPS monitor (master): [FAILED]
UPSD_OPTIONS is empty in /etc/sysconfig/ups
We've have issues with the Fedora (and RedHat) scripts before. NUT
doesn't use /etc/sysconfig/ups, this is something that your distro
added. Chances are that this was written for an earlier version of NUT
and since never changed. It's not needed either, since all information
needed to startup the drivers, server and clients is in the NUT
configuration files already. Could you try if running
/path/to/upsdrvctl start
/path/to/upsd
/path/to/upsmon
improves the situation?
For debugging purposes you shouldn't use the startup scripts from
*any* distribution, because they will invariably direct the startup
messages to /dev/null (it might already tell you what's wrong now).
And the log shows:
Dec 27 18:16:56 coyote upsd[21863]: listening on 127.0.0.1 port 3493
Dec 27 18:16:56 coyote upsd[21863]: Can't chdir to /var/run/nut:
Permission denied
This is the STATEPATH directory (which is compiled in) and should be
writeable by the user 'upsd' is running as. It almost certainly isn't.
Best regards, Arjen
Ok, the strace output: wordwrap off
[r...@coyote ups]# strace upsdrvctl start
execve(/sbin/upsdrvctl, [upsdrvctl, start], [/* 56 vars */]) = 0
brk(0) = 0x8073000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=177483, ...}) = 0
mmap2(NULL, 177483, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb78cf000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177elf\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\...@\310#e4\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1809672, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb78ce000
mmap2(0x45226000, 1521232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x45226000
mmap2(0x45394000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16e) = 0x45394000
mmap2(0x45397000, 9808, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x45397000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb78cd000
set_thread_area({entry_number:-1 - 6, base_addr:0xb78cd6c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1})
= 0
mprotect(0x45394000, 8192, PROT_READ) = 0
mprotect(0x45222000, 4096, PROT_READ) = 0
munmap(0xb78cf000, 177483) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb78fa000
write(1, Network UPS Tools - UPS driver c..., 48Network UPS Tools - UPS
driver controller 2.2.2
) = 48
brk(0) = 0x8073000
brk(0x8094000) = 0x8094000
open(/etc/ups/ups.conf, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0640, st_size=3659, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb78f9000
read(3, # Network UPS Tools: example ups..., 4096) = 3659
read(3, , 4096) = 0
close(3)= 0
munmap(0xb78f9000, 4096)= 0
stat64(/sbin/usbhid-ups, {st_mode=S_IFREG|0755, st_size=114220, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb78cd708) = 25669
rt_sigaction(SIGALRM, {0x8049100, [], 0}, NULL, 8) = 0
alarm(45) = 0
waitpid(25669, Network UPS Tools: 0.29 USB communication driver - core 0.33
(2.2.2)
Using subdriver: Belkin HID 0.11
Can't initialize data from HID UPS
[{WIFEXITED(s) WEXITSTATUS(s) == 1}], 0) = 25669
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigaction(SIGALRM, {SIG_IGN, [ALRM], SA_RESTART}, {0x8049100, [], 0}, 8) = 0
alarm(0)= 44
write(2, Driver failed to start (exit sta..., 39Driver failed to start (exit
status=1)
) = 39
exit_group(1) = ?
[r...@coyote ups]#
Looks like we lose the strace function for the subdriver, Belkin. The data
is flowing though, or is it, ttyUSB0 and ttyUSB1 are in use here, and the
hiddev0 and hidraw0 devices have been nuked till the next time I unplug
and replug the cable.
Is this a situation where I'll have to crawl under the desk and do a
momentary
Re: [Nut-upsuser] Old thread on belkin
On Monday 28 December 2009, Gene Heskett wrote:
On Monday 28 December 2009, Arjen de Korte wrote:
Citeren Gene Heskett gene.hesk...@gmail.com:
Just starting it with the fedora service command gets this:
[r...@coyote rules.d]# service ups start
/etc/sysconfig/ups: line 4: UPSD_OPTIONS: command not found
Starting UPS driver controller:[FAILED]
Starting upsd: [FAILED]
Starting UPS monitor (master): [FAILED]
UPSD_OPTIONS is empty in /etc/sysconfig/ups
We've have issues with the Fedora (and RedHat) scripts before. NUT
doesn't use /etc/sysconfig/ups, this is something that your distro
added. Chances are that this was written for an earlier version of NUT
and since never changed. It's not needed either, since all information
needed to startup the drivers, server and clients is in the NUT
configuration files already. Could you try if running
/path/to/upsdrvctl start
/path/to/upsd
/path/to/upsmon
improves the situation?
For debugging purposes you shouldn't use the startup scripts from
*any* distribution, because they will invariably direct the startup
messages to /dev/null (it might already tell you what's wrong now).
And the log shows:
Dec 27 18:16:56 coyote upsd[21863]: listening on 127.0.0.1 port 3493
Dec 27 18:16:56 coyote upsd[21863]: Can't chdir to /var/run/nut:
Permission denied
This is the STATEPATH directory (which is compiled in) and should be
writeable by the user 'upsd' is running as. It almost certainly isn't.
Best regards, Arjen
Ok, the strace output: wordwrap off
[r...@coyote ups]# strace upsdrvctl start
execve(/sbin/upsdrvctl, [upsdrvctl, start], [/* 56 vars */]) = 0
brk(0) = 0x8073000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory) open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=177483, ...}) = 0
mmap2(NULL, 177483, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb78cf000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177elf\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\...@\310#e4\0\0\0...,
512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1809672, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb78ce000 mmap2(0x45226000, 1521232, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x45226000 mmap2(0x45394000, 12288,
PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16e) =
0x45394000 mmap2(0x45397000, 9808, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x45397000 close(3)
= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb78cd000 set_thread_area({entry_number:-1 - 6, base_addr:0xb78cd6c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x45394000, 8192, PROT_READ) = 0
mprotect(0x45222000, 4096, PROT_READ) = 0
munmap(0xb78cf000, 177483) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb78fa000 write(1, Network UPS Tools - UPS driver c..., 48Network UPS
Tools - UPS driver controller 2.2.2 ) = 48
brk(0) = 0x8073000
brk(0x8094000) = 0x8094000
open(/etc/ups/ups.conf, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0640, st_size=3659, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb78f9000 read(3, # Network UPS Tools: example ups..., 4096) = 3659
read(3, , 4096) = 0
close(3)= 0
munmap(0xb78f9000, 4096)= 0
stat64(/sbin/usbhid-ups, {st_mode=S_IFREG|0755, st_size=114220, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb78cd708) = 25669 rt_sigaction(SIGALRM, {0x8049100, [], 0},
NULL, 8) = 0
alarm(45) = 0
waitpid(25669, Network UPS Tools: 0.29 USB communication driver - core 0.33
(2.2.2)
Using subdriver: Belkin HID 0.11
Can't initialize data from HID UPS
[{WIFEXITED(s) WEXITSTATUS(s) == 1}], 0) = 25669
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigaction(SIGALRM, {SIG_IGN, [ALRM], SA_RESTART}, {0x8049100, [], 0}, 8)
= 0 alarm(0)= 44
write(2, Driver failed to start (exit sta..., 39Driver failed to start
(exit status=1) ) = 39
exit_group(1) = ?
[r...@coyote ups]#
Looks like we lose the strace function for the subdriver, Belkin. The data
is flowing though, or is it, ttyUSB0 and ttyUSB1 are in use here, and the
hiddev0 and hidraw0 devices have been nuked till the next time I unplug
and replug the cable.
Is this a situation where I'll have to crawl under the desk and do a
momentary disconnect for every
[Nut-upsuser] Old thread on belkin
Greetings all; Back to a thread I started back in May of 2008 I think. I never did get this belkin and nut to talking, so I thought I'd make another run at it. Trying to run the driver as the user gene, I'm getting this: --- [r...@coyote ups]# su gene -c /sbin/belkin -D -a myups Network UPS Tools - Belkin Smart protocol driver 0.21 (2.2.2) debug level is '1' Unable to open /dev/hidraw0: Permission denied Current user id: gene (501) Serial port owner: root (0) Serial port group: root (0) Mode of port: 0660 Things to try: - Use another port (with the right permissions) - Fix the port owner/group or permissions on this port - Run this driver as another user (upsdrvctl -u or 'user=...' in ups.conf). See upsdrvctl(8) and ups.conf(5). Fatal error: unusable configuration And, /dev/hidraw0 (and all associated) is owned by root:root despite 62_*.rules for udev stating it should be uucp. [r...@coyote ups]# ls -l /dev/hid* crw-rw 1 root root 180, 0 2009-12-27 08:52 /dev/hiddev0 crw-rw 1 root root 180, 1 2009-12-26 11:17 /dev/hiddev1 crw-rw 1 root root 253, 0 2009-12-27 08:52 /dev/hidraw0 crw-rw 1 root root 253, 1 2009-12-26 11:17 /dev/hidraw1 crw-rw 1 root root 253, 2 2009-12-26 11:17 /dev/hidraw2 crw-rw 1 root root 253, 3 2009-12-26 11:17 /dev/hidraw3 crw-rw 1 root root 253, 4 2009-12-26 11:17 /dev/hidraw4 - /dev/hidraw0 was _not_ created during boot time discovery, and was only created when I momentarily unplugged the data cable, which when I plugged it back in, which returned this in the messages log: - Dec 27 08:52:39 coyote kernel: [77690.153405] usb 1-10.1: new low speed USB device using ehci_hcd and address 16 Dec 27 08:52:39 coyote kernel: [77690.368022] usb 1-10.1: New USB device found, idVendor=050d, idProduct=0751 Dec 27 08:52:39 coyote kernel: [77690.368027] usb 1-10.1: New USB device strings: Mfr=4, Product=20, SerialNumber=0 Dec 27 08:52:39 coyote kernel: [77690.368030] usb 1-10.1: Product: Belkin UPS Dec 27 08:52:39 coyote kernel: [77690.368031] usb 1-10.1: Manufacturer: Belkin Dec 27 08:52:39 coyote kernel: [77690.368117] usb 1-10.1: configuration #1 chosen from 1 choice Dec 27 08:52:40 coyote kernel: [77691.098585] generic-usb 0003:050D:0751.0006: hiddev0,hidraw0: USB HID v1.11 Device [Belkin Belkin UPS] on usb-:00:02.1-10.1/input0 -- The user passwd in the .conf files is me, not root. Where do I go next folks? It won't even get that far when launched as root. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) I'm DESPONDENT ... I hope there's something DEEP-FRIED under this miniature DOMED STADIUM ... ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Old thread on belkin
On Sunday 27 December 2009, Charles Lepple wrote: [cc'ing the list] On Dec 27, 2009, at 12:14 PM, Gene Heskett wrote: On Sunday 27 December 2009, Charles Lepple wrote: On Dec 27, 2009, at 9:49 AM, Gene Heskett wrote: Greetings all; Back to a thread I started back in May of 2008 I think. I never did get this belkin and nut to talking, so I thought I'd make another run at it. Trying to run the driver as the user gene, I'm getting this: --- [r...@coyote ups]# su gene -c /sbin/belkin -D -a myups Network UPS Tools - Belkin Smart protocol driver 0.21 (2.2.2) debug level is '1' Unable to open /dev/hidraw0: Permission denied Hey Gene, At the moment (this applies to both 2.2.2 and 2.4.1), none of our drivers will use /dev/hidraw* devices. Serial port drivers use /dev/ ttyS* and /dev/ttyUSB*, and the USB drivers use a matching scheme based on vendor and product IDs. /dev/hidraw0 was _not_ created during boot time discovery, and was only created when I momentarily unplugged the data cable, which when I plugged it back in, which returned this in the messages log: Not sure why it didn't appear at boot time, but since our drivers don't use that interface, it is soon to become a moot point. One of the side effects of the usbhid-ups driver is that it will tell the kernel HID driver to release the /dev/hid* device when it connects, so that /dev entry will disappear. - Dec 27 08:52:39 coyote kernel: [77690.153405] usb 1-10.1: new low speed USB device using ehci_hcd and address 16 Dec 27 08:52:39 coyote kernel: [77690.368022] usb 1-10.1: New USB device found, idVendor=050d, idProduct=0751 Looking in the Hardware Compatibility List under Belkin, we can see that a number of devices mention Vendor ID 050d: http://new.networkupstools.org/stable-hcl.html They are all listed next to the usbhid-ups driver. You should be able to run with the following entry in ups.conf: [myups] driver = usbhid-ups port = auto vendorid = 050d If not, please send us the error you get when starting the driver, and remind us which distribution of Linux you are running. Fedora F10, kernel 2.6.32 I made it so in /etc/ups/ups.conf: [r...@coyote ups]# /sbin/belkin -D -a myups Network UPS Tools - Belkin Smart protocol driver 0.21 (2.2.2) Fatal error: 'vendorid' is not a valid variable name for this driver. /sbin/belkin is only for RS-232 serial connections to Belkin hardware. (Most of the NUT drivers were named well before USB UPSes were commonplace.) You probably want /sbin/usbhid-ups. Which seems to upchuck on the vendorid= een if its correct according to messages. We're starting to make a bigger distinction in the documentation, What docs? No man nut or pinfo nut pages seem to exist. Newbies need a starting point. Each driver has its own man page (e.g. man belkin), and they refer to the nutupsdrv generic man page for all NUT drivers. Again, the belkin driver predates the USB-enabled Belkin units, so when the USB drivers were introduced, the older serial driver documentation was not updated to reflect the new USB-enabled hardware. The documentation is also available online: http://www.networkupstools.org/documentation.html Bookmarked for further study. Thanks. We are still in the middle of deploying it, so please let us know if you run across any broken links, or other inconsistencies there. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) No sooner said than done -- so acts your man of worth. -- Quintus Ennius ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Old thread on belkin
On Sunday 27 December 2009, Charles Lepple wrote: On Dec 27, 2009, at 5:05 PM, Gene Heskett wrote: You probably want /sbin/usbhid-ups. Which seems to upchuck on the vendorid= een if its correct according to messages. Which message, specifically? Just starting it with the fedora service command gets this: [r...@coyote rules.d]# service ups start /etc/sysconfig/ups: line 4: UPSD_OPTIONS: command not found Starting UPS driver controller:[FAILED] Starting upsd: [FAILED] Starting UPS monitor (master): [FAILED] UPSD_OPTIONS is empty in /etc/sysconfig/ups And the log shows: Dec 27 18:16:56 coyote upsd[21863]: listening on 127.0.0.1 port 3493 Dec 27 18:16:56 coyote upsd[21863]: Can't chdir to /var/run/nut: Permission denied which is probably a separate problem. I am looking back through an strace of that, hoping to see something, but its many kb of output. and no place in it do I see a reference to /var/run. Thanks. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) I didn't order any WOO-WOO ... Maybe a YUBBA ... But no WOO-WOO! ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] diff question, Belkin F6C100-4 this time
Greetings all; I pulled a Belkin F6C100-4 into the shop this afternoon, deader than a door nail. Out of service for about a year because (I'm assuming here) that the cooling fan stopped and cooked what little remaining life there may have been out of the batteries, which had swelled so badly I had to split its frame to get them out. They are also in the under 1 volt per 12 volt pack charge state, which considering they are about 5 years old it hasn't been plugged in for 18 months because it had failed would not restart. Looking over the circuitry, and playing Sherlock with the clues since I am a C.E.T., it appears that there is a relay in series with the line voltage input, which is driven by that section of the PCB that is connected only to the battery, and that without the batteries to supply 'starter' power, it will not enable the relay to power itself up. Am I correct? I took a chance and ordered some fresh batteries, but they probably will not arrive before 2010 now. I'll also need to locate a new fan, as that one can be turned by hand or air, but is certainly much too stiff to run under its assumed 12 volt dc supply. No damaged parts can be seen on any of the PCB's. I am also disappointed to find the fan doesn't have a tach wire in its hookup that Belkin _could_ have used to trigger a power down when it failed, but obviously did not. For a $375 (new in 2001 or 2) ) ups, I really expected more. OTOH, those batteries I took out are the 3rd replacements (from Belkin at $225 a kit) I have put in it. What I ordered were $87 with shipping. I buy a lottery ticket about once a year too. ;-) Can nut be trained to listen to this old boat (it weighs in at about 45 pounds) anchor? Serial only of course. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Two can Live as Cheaply as One for Half as Long. -- Howard Kandel ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] diff question, Belkin F6C100-4 this time
On Sunday 27 December 2009, Charles Lepple wrote: On Dec 27, 2009, at 7:02 PM, Gene Heskett wrote: Greetings all; I pulled a Belkin F6C100-4 into the shop this afternoon Referring to http://www.networkupstools.org/stable-hcl.html , there is a chance that one of these two drivers will talk to it: * http://new.networkupstools.org/man/belkin.html * http://new.networkupstools.org/man/belkinunv.html I don't know enough about the model numbers to say whether yours might be an old -UNV series or not. (Some messages that I found with Google seem to indicate that -UNV models have a USB port as well as serial, so it might be completely different.) Looking over the circuitry, and playing Sherlock with the clues since I am a C.E.T., it appears that there is a relay in series with the line voltage input, which is driven by that section of the PCB that is connected only to the battery, and that without the batteries to supply 'starter' power, it will not enable the relay to power itself up. The belkinunv man page talks about a related issue: http://new.networkupstools.org/man/belkinunv.html#_soft_shutdown_workaround (first paragraph) It sounds like that model won't come back on if you tell it to shut down before the batteries are completely drained. I'd guess that depends on the definition of drained. At 1 volt for each of the 3 9ah packs, I'd assume these are indeed drained. They are also about 1/4 wider in the XY direction, which does not bode well for any energy storage capabilities within. I guess it depends whether your intended use case includes reliably starting back up after a power outage, or if you are more concerned with shutting down cleanly. I don't care if it doesn't restart w/o manual intervention. When I actually had it in service the last time, it was backup up a complete desktop cnc milling machine setup, with the idea that it would survive a 1 or 2 second outage without wrecking the part it may have been cutting at the time. After 20 seconds at that load, all bets are off, but a 2 second coverage will cover 99% of the power bumps we get because of poorly maintained regulator switches at the substation. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Being against torture ought to be sort of a bipartisan thing. -- Karl Lehenbauer ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Smart-UPS RT 3000 Baud Rate
On Wednesday 15 July 2009, Richard Scobie wrote: Arnaud Quette wrote: so your only solution seems to be an additional card... And no more purchases from APC. Prospective APC buyers should check carefully beforehand. Or use apcupsd instead? They even have a linux mailing list. Regards, Richard ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp You can do more with a kind word and a gun than with just a kind word. - Al Capone ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin support?
On Monday 01 June 2009, Manuel Wolfshant wrote: Charles Lepple wrote: On May 31, 2009, at 10:17 PM, Gene Heskett wrote: On Sunday 31 May 2009, Charles Lepple wrote: On May 31, 2009, at 2:26 PM, Gene Heskett wrote: I have the newest nut (nut-2.2.2-4.fc10.i386) from fedora 10 repos) installed and this ups (from lsusb -vv): Bus 001 Device 006: ID 050d:0751 Belkin Components Hi Gene, This device should be supported by the usbhid-ups driver. That seems not to be part of the 2.6.30-rcX kernels. The current .config has: CONFIG_USB_HID=y CONFIG_USB_HIDDEV=y CONFIG_HID_BELKIN=y I should have been more specific - usbhid-ups is a user-mode driver in NUT. It uses libusb to kick the kernel's USB HID driver off of the device, and it uses /dev/bus/usb (I forget the kernel driver name) to speak the HID protocol. I can probably dig out anything else that might be helpful. Usually you would look this up in the data/drivers.list file, but it doesn't look like the lsusb output is terribly helpful for that (Belkin seems to change the underlying hardware while keeping the model name the same). Which model do you have? The NUT README file, while not specific to Fedora, should have the rest of the info needed to set this up. (Perhaps someone with Fedora 10 experience can suggest whether the classic driver or the HAL driver would be better.) If I had to guess, I'd say the README is in / usr/share/doc/nut. - Charles It might help, if it was there: [r...@coyote ~]# locate 'nut/README' [r...@coyote ~]# [r...@coyote ~]# cd `locate 'nut/'` [r...@coyote cur]# ls 1243795177.4479.gANVC:2,RS 1243799859.4479.0TdwL 1243813905.4479.2izhm the docs are in /usr/share/doc/nut-2.2.2/ . Generally speaking, in fedora docs are usually placed in /usr/share/doc/packagename-version and the config files are in /etc/ups not in /etc/nut [r...@coyote cur]# pwd /root/Mail/nut/cur [r...@coyote cur]# I don't believe it exists in the rpms. Next? use rpm -ql for a comprehensive list of the content of the rpm. BTW, I am using FC10 myself (but with a different UPS): [wo...@wolfy ~]$ rpm -ql nut|grep README /usr/share/doc/nut-2.2.2/README /usr/share/doc/nut-2.2.2/docs/README Thanks, they are indeed there. That should get me going once I've injected sufficient caffeine. Which is still on the missing list... -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp You could live a better life, if you had a better mind and a better body. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin support?
On Monday 01 June 2009, Noel David Torres Taño wrote: On Monday 01 June 2009 05:08:05 Gene Heskett wrote: On Sunday 31 May 2009, Charles Lepple wrote: On May 31, 2009, at 10:36 PM, Gene Heskett wrote: [myups] driver = mydriver port = /dev/ttyS1 cable = 1234 desc = A POS Belkin # # To find out if your driver supports any extra settings, start it with # the -h option and/or read the driver's documentation. - I now see the port is wrong, and should probably be /dev/ttyUSB1, as zero is busy here, with heyu. However, fixing that makes zero difference. Actually, for the usbhid-ups driver (with only one UPS on a machine), / etc/nut/boils down to: ### [myups] driver = usbhid-ups port = auto desc = Whatever floats your boat ### Made no diff when I pasted that in erased the other, sorry. This is the way I discover the base configuration problems: Try running the driver by hand, tweaking it in its own command line. Forget about NUT until you can run the driver itself. The driver is a program, and it can be launched alone. That way you can read the complete driver text output. Noel er Envite That seems to work, as in doesn't exit even if I run a second invocation of usbhid-ups -a myups, both show up at the bottom of htop's listing, and both responded to a kill from htop. The output was: [r...@coyote /]# usbhid-ups -a myups Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) Using subdriver: Belkin HID 0.11 But no other output was seen. They ran for about 2 or 3 minutes. Since this ups outputs a continuous string of status info, there must be something doofy in the connection. I'll check when I am awake, ERR_NOTSUFFICIENT_CAFFEINE right now. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp Traffic signals in New York are just rough guidelines. -- David Letterman ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin support?
On Monday 01 June 2009, Arjen de Korte wrote: Citeren Gene Heskett gene.hesk...@gmail.com: That seems to work, as in doesn't exit even if I run a second invocation of usbhid-ups -a myups, both show up at the bottom of htop's listing, and both responded to a kill from htop. The output was: [r...@coyote /]# usbhid-ups -a myups Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) Using subdriver: Belkin HID 0.11 But no other output was seen. They ran for about 2 or 3 minutes. Since this ups outputs a continuous string of status info, there must be something doofy in the connection. I'll check when I am awake, ERR_NOTSUFFICIENT_CAFFEINE right now. This is right what we expect. You clearly first need to read up on the README and INSTALL files, since these will explain how to set this up. Looking at the above, it is quite clear that your UPS is indeed supported, but you didn't set NUT up properly yet. We have been thinking about setting up a configuration wizard, but so far we're lacking the resources to do this. Sorry about that. It sure would be a nice addition, hint hint. :) Best regards, Arjen Thanks Arjen -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp I am a bookaholic. If you are a decent person, you will not sell me another book. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Belkin support?
Greetings; I have the newest nut (nut-2.2.2-4.fc10.i386) from fedora 10 repos) installed and this ups (from lsusb -vv): Bus 001 Device 006: ID 050d:0751 Belkin Components Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x050d Belkin Components idProduct 0x0751 bcdDevice0.01 iManufacturer 4 iProduct 20 Belkin UPS -- As nut comes totally non-configured, is there an instructional web page?, or can someone please tell me how to make this combo work with linux? Thank you -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp Of course power tools and alcohol don't mix. Everyone knows power tools aren't soluble in alcohol... -- Crazy Nigel ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin support?
On Sunday 31 May 2009, Rob MacGregor wrote: On Sun, May 31, 2009 at 19:26, Gene Heskett gene.hesk...@gmail.com wrote: Greetings; I have the newest nut (nut-2.2.2-4.fc10.i386) from fedora 10 repos) installed and this ups (from lsusb -vv): Note that 2.2.2 is over a year old. 2.4.1 is the latest version. If you run into any problems expect to be advised to upgrade. I'll take that up with Rahul. If that's the case, I am not allergic to building from the tarball, some of the stuff I run here straight from the tarball, like the kernel is 2.6.30-rc7, and amanda is from yesterdays snapshot of what will become amanda-2.6.2 in a few months. However, I have no clue if I have a problem because I can't get it to run at all. [r...@coyote amanda]# service ups start Starting UPS driver controller:[FAILED] Starting upsd: [ OK ] Starting UPS monitor (master): [FAILED] So I need help from square one. Would a tarball build be preferable in this case? As nut comes totally non-configured, is there an instructional web page?, or can someone please tell me how to make this combo work with linux? http://www.networkupstools.org/, and the man pages ;) Those I have been looking at, intermittently. Too many trees, can't see the forest. :) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp I got this powdered water -- now I don't know what to add. -- Steven Wright ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
