On 1/31/15, Charles Lepple <[email protected]> wrote: > On Jan 31, 2015, at 9:17 AM, Melvin Call <[email protected]> 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@gmail
Thank 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 _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
