Good morning all. I am on a different system with a different UPS, and I am fighting a similar problem to the one I posted about yesterday, and again making little headway. This system is running Debian Wheezy and connected to an APC BackUPS ES550. Starting things manually seems to go well, but my startup script fails, and nothing is logged anywhere. This may not be a NUT question per se, but I don't know where else to turn. What works: amdbox:/etc/nut# /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: APC HID 0.95 amdbox:/etc/nut# /sbin/upsd Network UPS Tools upsd 2.6.4 fopen /var/run/nut/upsd.pid: No such file or directory listening on ::1 port 3493 listening on 127.0.0.1 port 3493 Connected to UPS [apc_es550]: usbhid-ups-apc_es550 amdbox:/etc/nut# upsc apc_es550 at localhost ups.status OL amdbox:/etc/nut# /sbin/upsmon Network UPS Tools upsmon 2.6.4 fopen /var/run/nut/upsmon.pid: No such file or directory UPS: apc_es550 at localhost (master) (power value 1) Using power down flag file /tmp/killpower amdbox:/etc/nut# /sbin/upsmon -c fsd <system shuts down> Restart the system and check the logs: amdbox:/etc/nut# grep -i ups /var/log/syslog That only shows entries related to the above activity, with nothing related to the Debian installed start up scripts. ps shows nothing running: amdbox:/etc/nut# ps -eF | grep '[u]ps' root 2245 1 0 18968 3400 0 07:51 ? 00:00:00 /usr/sbin/cupsd -C /etc/cups/cupsd.conf Manually trying to start the service results in a "failed" message: amdbox:/etc/nut# service nut-server start [ ok ] Starting NUT - power devices information server and drivers:. amdbox:/etc/nut# service ups-monitor start [FAIL] Starting NUT - power device monitor and shutdown controller: nut-client failed! amdbox:/etc/nut# ps -eF | grep '[u]ps' root 2245 1 0 18968 3400 0 07:51 ? 00:00:00 /usr/sbin/cupsd -C /etc/cups/cupsd.conf The device seems to be seen and assigned the proper permissions: amdbox:/etc/nut# ls -l /dev/bus/usb/003 total 0 crw-rw-r-T 1 root root 189, 256 Jan 31 07:51 001 crw-rw-r-T 1 root nut 189, 257 Jan 31 07:51 002 There is no other information provided, and there is nothing in the log to help either. Can anyone tell me what I need to do to make this output some useful information that I can use to further trouble-shoot the problem? Thanks, Melvin
On Jan 31, 2015, at 9:17 AM, Melvin Call <melvincall979 at gmail.com> wrote:> There is no other information provided, and there is nothing in the log to help > either. Can anyone tell me what I need to do to make this output some useful > information that I can use to further trouble-shoot the problem?In general, if a startup script isn't doing what I think it should, I run it with "sh -x <name-of-script> start". That will print a trace log of all of the commands as they are executed. In this particular case, do you have the mode in /etc/nut/nut.conf set up? -- Charles Lepple clepple at gmail
On 1/31/15, Charles Lepple <clepple at gmail.com> wrote:> On Jan 31, 2015, at 9:17 AM, Melvin Call <melvincall979 at gmail.com> wrote: > >> There is no other information provided, and there is nothing in the log to >> help >> either. Can anyone tell me what I need to do to make this output some >> useful >> information that I can use to further trouble-shoot the problem? > > In general, if a startup script isn't doing what I think it should, I run it > with "sh -x <name-of-script> start". That will print a trace log of all of > the commands as they are executed. > > In this particular case, do you have the mode in /etc/nut/nut.conf set up? > > -- > Charles Lepple > clepple at gmailThank you Charles! I can't believe I had completely forgotten about the -x option. I haven't done any serious scripting in a long time, but I seem to recall that you could not only invoke scripts as you mentioned, but you can also add that option to the script, at the end of the #! line (I forget what you call that line). Anyhow, that helped, and you nailed it with your other question. The trace showed everything working fine, but that the problem was there was no match for the MODE in the switch statement of the start_stop_client function. I "knew" that I had set that correctly (to standalone), so I modified things a bit to show just what it was trying to match rather than look at nut.conf. It was indeed incorrect in the conf file: amdbox:/etc/nut# grep MODE /etc/nut/nut.conf # The MODE determines which part of the NUT is to be started, and which # The values of MODE can be: # Since this MODE is opened to the network, a special care should be applied MODE=standalone: Not sure why I felt the need to end the line with a colon, but that was the problem. At least this time I know why this one started working, even if it was my fault. If I was a bit more familiar with things I may have caught the fact that service nut-server start did not end with "upsd driver(s)", but I didn't notice that until after I had this figured out. I'm not sure that even knowing that would have helped, but it is a clue for anyone else that comes across this thread. I am up and talking to the UPS, so it should just be a matter of getting my shutdown stuff working at this point. One last question if you don't mind. I noticed the "default" POWERDOWNFLAG is set to /etc/killpower, but I changed that to /tmp and modified my umountroot script to mount it read only too, because I know it gets wiped on reboot. Is there anything that removes /etc/killpower on reboot, or a more compelling reason to put killpower in /etc, other than it is usually not on a separate partition? Thanks again for your help. Melvin