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 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