Re: [Nut-upsuser] Trying to update the official docs for nut on FreeNAS - help needed to ensure it's written correctly

[Roger Price]

On Fri, 30 Mar 2018, Stilez Stilezy wrote:

My own UPS setup is an APC SUA 1500i + AP9630 card, and the default user on 
the UPS has been changed, so that's what I'll test anything with, to check my 
understanding and appropriate inputs.


Perhaps this question is even more off-topic, but given that the APC SUA1500i 
already offers a USB interface and a serial interface, what does the AP9630 
offer FreeNAS in addition, other than complexity and expense?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] CentOS 7, systemd, nut-monitor, and failing to shut down the UPS

[Roger Price]

On Thu, 1 Feb 2018, Lee Damon wrote:


I've "fixed" this problem by modifying the nutshutdown script:
#!/bin/sh
# stop nut driver to free up access to the device
/sbin/systemctl stop nut-driver
# make sure it has time to die
sleep 2
# check to see if we need to actually shutdown the UPS then do it
/usr/sbin/upsmon -K >/dev/null 2>&1 && /usr/sbin/upsdrvctl shutdown


I don't have NUT + systemd + CentOS/RHEL, but I'm confused by your script. 
"upsdrvctl" is a front end to your driver.  You are sending a command via 
upsdrvctl and via your driver _after_ you have stopped the driver?  And it 
works?



How did/do you solve this problem?


I don't use the nutshutdown script, but rather a systemd service unit which is 
called much earlier in the shutdown process.  This allows logging of the action.
It's described in Appendix B.2 at 
http://rogerprice.org/NUT/ConfigExamples.A5.pdf#subsection.B.2


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Default value for ondelay

[Roger Price]

On Fri, 2 Feb 2018, nut.user.u...@neverbox.com wrote:


  I have an older box set up this way for continuous integration, and it needs 
to see more than a few seconds of power loss for the "always turn
  on" BIOS setting to work. I forget how many different intervals I tried, 
but 30 seconds of off time is reliable for that particular box.

Thanks. This matches my limited experience from yesterday with 2 computers 
including the one that's actually attached to the UPS I'm trying to get to
work. 

If power is cut and restored when the computer is already off (and with the 
always-on BIOS setting), then: short off time, it doesn't notice and it
remains off; long off time, it does come back on. I did one minute for "long" 
but didn't do binary partitioning of the interval to assess the exact
threshold.


The default values in ups.conf are currently offdelay = 20 and ondelay = 30.
In view of your findings, shouldn't the default ondelay be offdelay+30 or even
higher?

Roger
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] testing shutdown: pc not restarting; and "ups unavailable" messages

[Roger Price]

On Thu, 1 Feb 2018, nut.user.u...@neverbox.com wrote:

I am installing a UPS with NUT on Ubuntu for the first time. I could 
follow the instructions up to "testing shutdowns" but on executing the 
recommended command the computer shuts down and never comes back on,


Have you checked the BIOS option "Power on when AC Returns"?

Does the UPS unit perform a delayed power off some time after the box shuts 
down?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Debian 9.3 nut-client.service reports itself as nut-monitor.service

[Roger Price]

On Thu, 28 Dec 2017, Charles Lepple wrote:


On Dec 28, 2017, at 6:35 AM, Roger Price <ro...@rogerprice.org> wrote:

It would be clearer to users if the service unit file was also called
/lib/systemd/service/nut-monitor.service

From what I can tell, the "nut-client.service" name comes from this 
Debian-specific symlink:
https://sources.debian.org/src/nut/2.7.4-5.1/debian/rules/#L104


The comment for the link is

  # Add a symlink to mask the LSB initscript
  ln -s nut-monitor.service 
$(CURDIR)/debian/nut-client/lib/systemd/system/nut-client.service

However Debian has now dropped the LSB (See https://lwn.net/Articles/658809/), 
so is the symlink still needed?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Debian 9.3 nut-client.service reports itself as nut-monitor.service

[Roger Price]

I reported a minor bug in nut 2.7.4 on Debian stretch and got the number 885592 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885592


The systemd service unit /lib/systemd/system/nut-client.service reports itself 
as nut-monitor.service on command systemctl status nut-client.service.


It would be clearer to users if the service unit file was also called

/lib/systemd/service/nut-monitor.service

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC SmartUPS 1000 via usb

[Roger Price]

On Sun, 17 Dec 2017, Hervé Bastet wrote:


Bonjour,

Je fais suite au message que vous avez posté en 2015 :
http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-February/009568.html

J'ai le même problème et ne trouve pas la solution. Comment vous en êtes-vous 
sorti ?

D'avance, merci pour votre aide.

--
Cordialement
Hervé BASTET
Nouveau numéro non surtaxé
01 69 42 87 94


Ce message est protégé par les règles relatives au secret des 
correspondances ; il peut en outre contenir des informations à caractère 
confidentiel ou protégé par différentes règles et notamment le secret 
des affaires ; il est établi à destination exclusive de son 
destinataire. Toute divulgation, utilisation, diffusion ou reproduction 
(totale ou partielle) de ce message, ou des informations qu'il contient, 
doit être préalablement autorisée. ...


En conformité avec les conditions de votre message je demande votre 
autorisation d'y repondre sur la liste de diffusion nut-upsuser et à tous 
les abonnés qui me sont inconnus.


As requested by the conditions attached to your message I request your 
authorisation to reply to the nut-upsuser mailing list and to all the 
subscribers who are unknown to me.


Cordialement, Sincerely, Roger Price___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Debian 9 : Can't open /etc/nut/upsd.users: Permission denied

[Roger Price]

On Sun, 10 Dec 2017, Jim Klimov wrote:

I am not sure the rights offered in that bug are fully ok: generally you 
wouldn't want the configs to be writable by the service daemon if you 
can avoid it (so if it's hacked - it can be abused to a lesser extent). 
I think the only writable bit is the killpower file, which might better 
belong in /var/run/nut or state-dir or something like that. Maybe 
something for nut-cgi needs writes? Otherwise root:nut 640 should be 
good, IMHO. Maybe even different users for server/driver/clients, for 
paranoid setups...


Perhaps a more general review of ownership and permissions would be 
useful.  For example, on my Debian 9 box, command « ls -alF /sbin/ups* » 
reports


  -rwxr-xr-x 1 root root   425 Jan 25  2017 /sbin/upsd*
  -rwxr-xr-x 1 root root 30816 Jan 25  2017 /sbin/upsdrvctl*
  -rwxr-xr-x 1 root root   429 Jan 25  2017 /sbin/upsmon*
  -rwxr-xr-x 1 root root 30808 Jan 25  2017 /sbin/upssched*

Wouldn't owner root:nut and permissions 750 be better?

Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Debian 9 : Can't open /etc/nut/upsd.users: Permission denied

[Roger Price]

On Sun, 10 Dec 2017, Charles Lepple wrote:

Either way, the default permissions are under the packager's control, so 
I would recommend that you file a bug with Debian: 
https://www.debian.org/Bugs/Reporting (feel free to mention the bug 
number here)


Debian Bug Tracker told me that the URL is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884021.

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Debian 9 : Can't open /etc/nut/upsd.users: Permission denied

[Roger Price]

I installed nut 2.7.4-5 on a fresh Debian 9.2.1 system.  I updated the 
configuration files, started nut in standalone mode, and got the error 
message


   Can't open /etc/nut/upsd.users: Permission denied

This is because the file has ownership and permissions

   -rw---   1 root nut 91 Aug  3 11:44 upsd.users

I changed the ownership and permissions in /etc/nut/ to

   drwxr-xr-x   2 root nut   4096 Dec  7 18:32 ./
   drwxr-xr-x 140 root root 12288 Dec  9 12:39 ../
   -rw-r-   1 root nut   1411 Dec  7 18:32 nut.conf
   -rw-r-   1 nut  nut290 Jul 14 20:16 ups.conf
   -rw---   1 nut  nut290 Jun 20 14:39 upsd.conf
   -rw---   1 nut  nut 91 Aug  3 11:44 upsd.users
   -rw---   1 nut  nut   1623 Jul  1 15:41 upsmon.conf
   -rw-r-   1 nut  nut   1348 Jul  1 09:39 upssched.conf

and the error message disappeared. The nut:nut ownership seems to me to be 
more natural, and the root:nut ownership looks like a bug in the Debian 
package.


Roger

___
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 Restart Issue

[Roger Price]

On Fri, 8 Dec 2017, Common Granger wrote:

I am using Ubuntu 16.04 LTS using NUT 2.7.4 with an APC Back-UPS 
RS1000G.  The problem is I do test shutdown using  sudo upsmon -c fsd 
and my computer shuts down ok but no matter how long I wait it never 
turns back on.  Is there a way to fix this.  I am using the usbhid-ups 
driver.  


Your computer would turn on again if

 1. The AC power from the UPS unit was stopped and then started again.

 2. Your BIOS option to restart on AC return was set correctly.

If you want this to happen automatically, then your shutdown sequence 
should include a "delayed shutdown" order to the UPS unit.  The delay is 
by default 20 sec.  The "delayed shutdown" has the effect of turning off 
the power outlets of the UPS unit after the delay.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help, please! Driver for APC Back-UPS 390 Watts / 700 VA, 230V, AVR, IEC Sockets

[Roger Price]

On Mon, 4 Dec 2017, Mikael Imperatori Festa wrote:


I had a look on the website, but I can¹t see a detailed list of supported
units.


Try installing and using apcupsd.  Does it work correctly with the 
BX700UI?  Which protocol is it using?


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help, please! Driver for APC Back-UPS 390 Watts / 700 VA, 230V, AVR, IEC Sockets

[Roger Price]

On Mon, 4 Dec 2017, Mikael Imperatori Festa wrote:


driver = apcupsd
port = auto


I meant the « APC UPS Daemon » at http://www.apcupsd.org/

Does this support your UPS unit?  If so, what protocol is it using?

What is the model number of your unit? BX650CI ?
Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help, please! Driver for APC Back-UPS 390 Watts / 700 VA, 230V, AVR, IEC Sockets

[Roger Price]

On Fri, 1 Dec 2017, Mikael Imperatori Festa wrote:


Hi there,
I tried all the driver on the list for this UPS, but they don’t work. Could you 
help me please?


Have you tried with apcupsd?  Which protocol does apcupsd use for the 
Back-UPS 390 ?


Roger

This e-mail message may contain confidential and/or privileged 
information and is for the sole use of the intended recipient(s). Any 
unauthorised review, use, disclosure of distribution is prohibited. If 
you are not the intended recipient, please contact the sender by reply 
e-mail and destroy all copies of the original message, as well as any 
other attachments. Thank you.


Does this make sense in a mail sent to a public mailing list? Am I 
authorised to review and re-distribute your e-mail?  Is the prohibition 
enforcable in my home country?___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] debian 8 "jessie" nut 2.7.2 slaves not shutting down

[Roger Price]

On Thu, 19 Oct 2017, Drew Plaster wrote:


The topology is:
UPS TOPAPC, Data link to master, Power supply to master, slave1 and 
slave2
UPS MIDAPC, Data link to master, Power supply to master, slave1 and 
slave2
UPS BOTAPC, Data link to master, Power supply to master, slave1 and 
slave2

Shutdown plan: When wall power fails for any of the three UPS units, 
they continue powering the master and the two slaves.  When two of the 
UPS battery have been depleted and the last (MINSUPPLIES 1) UPS unit 
reaches the status [OB LB]. the two slaves are shut down, and then the 
master is shutdown and sends shutdown signal to UPS (#POWERDOWNFLAG 
/etc/killpower) has been temporarily remarked out in the masters 
upsmon.conf to test if the slaves would shutdown vai hotsync or 
deadtime. Anyway, that is how I was envisioning it functioning with the 
current config files; I may be mis-understanding something but that is 
the desired shutdown plan.


Drew, it seems to me that your Shutdown plan means living dangerously! 
You have triplicated power backup for maximum system security, yet you let 
it run down until just one UPS is operational, and then only for a short 
time since it is in status [OB LB].


Are the three UPS units fed by the same utility, or by different sources?

Case 1: They share the same utility and they are behaving as one huge UPS 
delivered in three separate boxes.  Assuming they are of the same capacity 
and have the same load, they will run down at the same rate. In this case, 
perhaps it would be better to specify MINSUPPLIES 3 so that the first to 
go [OB LB] drives the shutdown.  Perhaps the slaves will respond correctly 
to this.


Case 2: They have different power sources.  The logic in this case may be 
beyond what is possible with the NUT configuration files.  You may need to 
use additional hardware such as an automatic power transfer switch, and/or 
implement your shutdown logic in a program (sometimes called upssched-cmd) 
called by the upssched.conf CMDSCRIPT directive.  This would mean that the 
upsmon.conf NOTIFYCMD directive would point to upssched, and that 
upssched-cmd would be responsible for sysadmin notifications.


I do not have any direct experience of a logic such as your Shutdown plan 
- perhaps other readers of this list have a deeper insight.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] debian 8 "jessie" nut 2.7.2 slaves not shutting down

[Roger Price]

On Wed, 18 Oct 2017, Drew Plaster wrote:


MASTER SYSTEM

nut.conf
MODE=netserver

ups.conf
[TOPAPC]
driver = usbhid-ups
  port = auto
 pollonly
 serial = "IS1309002707"
 desc = "TOPAPC"
[MIDAPC]
  driver = usbhid-ups
port = auto
   pollonly
   serial = "IS1309001233"
   desc = "MIDAPC"
[BOTAPC]
  driver = usbhid-ups
port = auto
   pollonly
   serial = "IS1309001213"
   desc = "BOTAPC"


Just to be sure that I understand your topology:

UPS TOPAPC, Data link to master, Power supply to master 
UPS MIDAPC, Data link to master, Power supply to slave1 
UPS BOTAPC, Data link to master, Power supply to slave2


Shutdown plan:  When wall power fails for any one of the three UPS units, 
they continue powering the master and the two slaves.  When any one of the 
three UPS units reaches the status [OB LB]. the two slaves are shut down, 
and then the master is shutdown.


Is this correct? 
Roger


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] debian 8 "jessie" nut 2.7.2 slaves not shutting down

[Roger Price]

On Wed, 18 Oct 2017, Drew Plaster wrote:

    there are three APC smart ups connected via usb cables 
to the master system, the master system shuts down as expected but the 
slave systems never shutdown eventhough I believe that all the configs 
are properly set the slaves should either shutdown when there is only 
one ups and it is running low on battery power offline or worst case 
shutdown after they cannot communicate with the master for longer than 
the HOSTSYNC 15 or UPS for longer than the DEADTIME 15


Hi, Could you show us your NUT configuration files?  Please omit the 
comments, and double spacing will not be needed.


Roger

Disclaimer: The information transmitted in this e-mail message and 
attachments, if any, may contain confidential material, and is intended 
only for the use of the individual or entity named above


It's probably best not to send such a disclaimer to a public mailing list 
with hundreds of subscribers.___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] On getting notify-send to work

[Roger Price]

The program ``wall´´ used by NUT to put notifications in front of the 
users is now well past it's best-before date.  It has not been 
internationalized, does not support accented letters or non-latin 
characters, and is ignored by popular desktop environments such as Gnome 
and KDE.  It's apparent replacement, notify-send, gives the impression 
that it has never been tested in any other than the simplest cases, and 
that it is not ready for industrial strength use.  Getting notify-send to 
work with NUT is not evident: this note discusses the problem.


Roger
__


Introduction


The program notify-send is part of a set of programs which implement the 
Gnome ``Desktop Notifications Specification´´ [3].


The introduction says:

<< This is a draft standard for a desktop notifications service, through
  which applications can generate passive popups to notify the user in an
  asynchronous manner of events. ...  Example use cases include:

 * Scheduled alarm
 * Low disk space/battery warnings ... >>

From this introduction it would seem that desktop notifications are 
exactly what is needed to present [OL]->[OB] and [OB]->[OB LB] warnings to 
the users, but unfortunately, things are not that simple.


Program notify-send is a utility which feeds message objects to a message 
server, such as notifyd.  As an example, the Xfce desktop environment 
provides it's message server called xfce4-notifyd.  None of these programs 
has a man page and I have not been able to find a mailing list specific to 
desktop notifications.


Experience shows that just calling notify-send in the script upssched-cmd 
does not work.  The message simply disappears.  Closer examination with 
command ps -elf | grep ups shows that if daemon upsmon running as user 
``upsd´´ calls notify-send to present a message, the notify daemon is 
launched with the same userid ``upsd´´ as the caller.


If the caller is the upsmon daemon which has no access to the desktop 
environment, then neither will the corresponding notification daemon. 
This is surprising.  One would expect a design closer to that of the 
printer daemon cupsd which runs permanently in the background receiving 
files to be printed.  There is only one daemon cupsd and that daemon 
isolates the user from needing to know how to drive printers.


To get the message to show on the user's screen appears to require three 
actions:


 1. Give user ``upsd´´ access to the local X-server,
 2. Make user ``upsd´´ a regular user,
 3. Define environment variable DISPLAY in upssched-cmd.

Give user ``upsd´´ access to the X-server
-

In NUT, ``upsd´´ is not a regular user and does not have the access to the 
X-server needed to display data.  This is a problem for the notification 
service, which we now fix.


Add the script

   # localuser.sh
   # Give user upsd access to X-server for notify-send display
   xhost +si:localuser:upsd

to directory /etc/X11/xinit/xinitrc.d.  This address works with openSUSE 
and probably with Fedora and RedHat.  It will probably be different in 
Debian and Ubuntu.


When X starts next time, this new script will be sourced from the script 
/etc/X11/xinit/xinitrc-common. It adds the user ``upsd´´ to the list of 
users authorised to access the local X-server.  See man xhost.  Verify 
that ``upsd´´ has been added with the command xhost (no options 
specified).


Make user ``upsd´´ a regular user
-

Whilst it is necessary to give user ``upsd´´ access to the X-server, my 
experience is that more is needed to get the notification in front of the 
users.


User ``upsd´´ needs to be turned into a regular user.  Without changing 
the user id or the group id:


 1. Make the password usable and unlocked.
 2. Make the default shell usable, for example /bin/bash.
 3. Define a home directory for ``upsd´´ and set the directory in
/etc/passwd.

Define environment variable DISPLAY
---

The upsmon daemon which calls the script upssched-cmd is itself called as 
a background task without console or desktop environment access.  The 
environment variable DISPLAY is not defined when the script upssched-cmd 
is executed.  However notify-send and it's notification daemon need the 
address of the X-server, so we prefix the calls to notify-send


   DISPLAY=":0.0" notify-send -a nut -t 0 -u critical "NUT" "$MSG"

Testing the notify-send setup
-

A simple way of testing the use of notify-send if you are using a 
configuration which includes the script upssched-cmd is to simply 
disconnect the wall power for 10 seconds.  This is sufficient to provoke 
upsmon into calling upssched-cmd which in turn calls notify-send.


While wall power is disconnected, use a command such as
   ps -elf | grep -E "ups[dms]|nut"
to find the programs running as user ``upsd´´:

   upsd  2635 1  ... 

Re: [Nut-upsuser] How do I configure NUT?

[Roger Price]

On Thu, 3 Aug 2017, Roger Price wrote:


On Thu, 3 Aug 2017, Tomas Larsson wrote:

Hi there. I need some advise on how to configure NUT, if it is possible to 
do it. My UPS, a Compaq R3000


I thought the Compaq R3000 Line was a Series of laptops designed and built by 
Hewlett-Packard Corporation, not a UPS?


My mistake, "R3000" can also refer to the HP UPS R3000, a 2U rackmount 
design offering up to 2700 watts.  See
http://h18000.www1.hp.com/products/quickspecs/archives_Canada/10671_ca_v20/10671_ca.PDF 
http://www.hp-r3000.etrk.info/HP-R3000-XR-NA-MANUAL.pdf


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] How do I configure NUT?

[Roger Price]

On Thu, 3 Aug 2017, Tomas Larsson wrote:

Hi there. I need some advise on how to configure NUT, if it is possible 
to do it. My UPS, a Compaq R3000


I thought the Compaq R3000 Line was a Series of laptops designed and built 
by Hewlett-Packard Corporation, not a UPS?



has three individual power segments.

I want NUT to:
When mains is interrupted.
Shut down all serves immediately.


I'm not sure of your topology, but it looks as if it would be easier to 
separate the problem into pieces.


1. The servers.  Make one of the servers the master, and all the others 
slaves.  This then becomes a well known NUT setup for master + slaves, in 
which the master begins the shutdown operation as soon as status [OB] is 
seen.  All the servers need to have upsd and upsmon running.  The server 
master does not shut down the UPS.


When all servers are completely down, in sequence with time delay shut 
down two of the power segments.


2. Later, based on a upssched timer, some other system "S" running upsd 
and upsmon shuts down the power segments.


When batteries is about to be depleted shut down itself and the last 
power segment.


3. When system "S" detects the [OB LB] status it shuts down itself and 
calls for a delayed shutdown of the UPS.



When power returns, start up the power segments in sequence.


This supposes that the power outlets of the UPS have been disconnected, 
and are reconnected when wall power returns.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Power Down ESXi before SAN

[Roger Price]

On Sun, 16 Jul 2017, Mike Schaffner wrote:

I have 2 APC UPS systems, one is connected to my ESXi host and the other 
to my FreeNAS.   The battery for the FreeNAS will run out before the 
battery for the ESXi, so I need ESXi to shutdown first.   If I wait 
until BatteryLow on ESXI, it will be too late as FreeNAS will have 
already shutdown.   How can I change the configuration on ESXI to 
shutdown after a small delay so that it is done before the FreeNAS 
Shutdown starts.


See chapter 7 in http://rogerprice.org/NUT/ConfigExamples.A5.pdf which 
covers timed shutdowns.


You could also use the [OB LB] status on the FreeNAS to shutdown the ESXi 
as a slave before the master FreeNAS.  Do you have NUT running on the 
FreeNAS?


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Trying to understand sdorder

[Roger Price]

My understanding is that NUT provides a mechanism to shut down multiple 
systems protected by multiple UPS's in a given order.  For example to 
shutdown the users before their NFS server.


1. man ups.conf says

  sdorder Optional. When you have multiple UPSes on your system, you 
usually need to turn them off in a certain order. upsdrvctl shuts down all 
the 0s, then the 1s, 2s, and so on. To exclude a UPS from the shutdown 
sequence, set this to -1.


2. config-notes.txt gives an example

To set the order in which your UPSes receive the shutdown commands, define 
the 'sdorder' value in your ups.conf.


[bigone]
driver = usbhid-ups
port = auto
sdorder = 2

[littleguy]
driver = mge-shut
port = /dev/ttyS0
sdorder = 1

[misc]
driver = blazer_ser
port = /dev/ttyS1
sdorder = 0

The order runs from 0 to the highest number available.  So, for this 
configuration, the order of shutdowns would be 'misc', 'littleguy', and 
then 'bigone'.


3. But in upsdrvctl.c I see

/* walk UPS table and send command to all UPSes according to sdorder */
static void send_all_drivers(void (*command)(const ups_t *))
{
ups_t   *ups;
int i;

...
for (i = 0; i <= maxsdorder; i++) {
ups = upstable;
while (ups) {
if (ups->sdorder == i)
command(ups);
ups = ups->next;
}
}
}

These nested loops will execute in a few milleseconds, effectively 
shutting down all the UPS units at the same time rather than in a paced 
sequence.


I see nothing that ensures that all the "0"s are effectively shut down 
before starting the shutdown of the "1"s.


Is there something in the sdorder logic that I am missing?

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Three wishes for upsmon

[Roger Price]

Here are three wishes for the future of upsmon:

1. The NOTIFYMSG texts should allow UTF-8 encoded messages.

2. The flags used in NOTIFYFLAG should be extended to include USER.  This 
flag says that the message is to be sent to the notify daemon, perhaps 
with the command


   notify-send -a NUT -t 60480 -u critical 

This will allow the users of a workstation to see the message.  The 
program wall is ignored by display environments such as Gnome and KDE. The 
current solution requires upssched and upssched-cmd just to put up a 
simple message.


3. The NOTIFYMSG and NOTIFYFLAG directives in upsmon.conf should be 
extended to specify the UPS name, as is already done for the AF directives 
in upssched.conf.  This will make it possible to have actions and messages 
which are different for different UPSes. The current solution requires 
turning off upsmon logging and notification for all UPSes in the presence 
of a busy UPS such as a heartbeart.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Ubuntu specific configurations

[Roger Price]

On Tue, 4 Jul 2017, Charles Lepple wrote:

Since you are using Ubuntu, upsmon.conf should contain "NOTIFYCMD 
/sbin/upssched". Similarly, upssched.conf should contain "CMDSCRIPT 
/usr/local/bin/upssched-script".


Thanks. I have updated the Configuration Examples to include these Ubuntu 
specific values.  I would very much like to include specifics for other 
distributions.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Roger Price]

On Mon, 3 Jul 2017, Andrea de Lutti wrote:


MONITOR dummy@artu 1 user pass master
SHUTDOWNCMD "/sbin/shutdown -h +0"
NOTIFYCMD /usr/local/bin/upssched-script


Hi, As far as I can see, what you are getting in syslog corresponds 
correctly to what you have specified.  You have specified that upsmon is 
to call upssched-script _directly_.  This means that the argument to the 
script call will be the NOTIFYMSG value.  But in upssched-script you are 
testing for the notifytype, e.g. ONBATT.


Did you want that, or did you want NOTIFYCMD to point to upssched?

If I may throw away modesty, see chapter 4 in 
http://rogerprice.org/NUT/ConfigExamples.A5.pdf which has a diagram and a 
fully worked example.


Roger


NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC

...


# Network UPS Tools - upssched.conf sample file
#
# 
CMDSCRIPT /usr/local/bin/upssched-script
PIPEFN /var/run/nut/upssched/upssched.pipe
LOCKFN /var/run/nut/upssched/upssched.lock

AT ONBATT * EXECUTE onbattwarn
AT ONLINE * EXECUTE ups-back-on-power

The upssched-script is

#! /bin/sh
case "$1" in
    "ONBATT")
        echo "On batt" | mailx -v -r "adelu...@gmail.com" -s "TEST NUT object" -S 
smtp="smtp.gmail.com:587" -S smtp-use-starttls -S smtp-auth=login -S
smtp-auth-user="adelu...@gmail.com" -S smtp-auth-password="gtmtnqyelhlumyds" -S 
ssl-verify=ignore adelutti+ser...@gmail.com
        ;;

...

    *)
        logger -t upssched-cmd "Unrecognized command: $1"
        ;;
    esac

while upssched.conf is

Running upson in debug mode I can see the change of the status (I have a cycle 
of 30 secs for online/batterry/low battery) but the syslog reports

Jul  3 16:17:15 artu upsmon[4685]: UPS dummy@artu on battery
Jul  3 16:17:15 artu upssched-cmd: Unrecognized command: UPS dummy@artu on 
battery
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Configuration Examples

[Roger Price]

I have written up a collection of NUT configurations.  The chapters are

 1. Introduction
 2. Simple server with no local users
 3. Server with multiple power supplies
 4. Workstation with local users
 5. Workstations share a UPS
 6. Workstation with heartbeat
 7. Workstation with timed shutdown
 8. Workstation with additional equipment

65 pages A5 format. A PDF reader could place two pages side by side on a 
17" or bigger monitor.  The text is intended for newcomers to NUT, and is 
available at http://rogerprice.org/NUT/ConfigExamples.A5.pdf The chapter 
names and references, line numbers, man page references and external site 
references are all clickable.


My thanks to those who commented on an earlier version.

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] CentOS rpm package installation

[Roger Price]

On Thu, 22 Jun 2017, Ambrogio Coletti wrote:


Hello

I am not a linux expert.
The output of uname -r on my system returns:
2.6.32-696.3.1.el6.x86_64


Hi, Linux 2.6.32 was released 3 December, 2009.  That's nearly 8 years 
ago. Linux has now reeched version 4.11.



hence I am trying to install this rpm:
sudo yum install nut-2.7.4-9.fc27.x86_64.rpm

but I got failed dependencies.

Is there a repository I am supposed to set up to get those dependencies from?


Perhaps the CentOS people could advise you on whether old rpms for CentOS 
still exist, but the general advice would be to install a more recent 
Linux.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Roger Price]

On Fri, 9 Jun 2017, Robbie van der Walle wrote:


... and also still open is the notification on the Mac.


If notify-send is available on the Mac, then perhaps this will work:

In upsmon.conf on the Mac you need

NOTIFYCMD /usr/sbin/upssched(or wherever this goes on a Mac)
NOTIFYFLAG ONBATT SYSLOG+EXEC

In upssched.conf you need

CMDSCRIPT /usr/sbin/upssched-cmd(or wherever this goes on a Mac)
AT ONBATT UPS@NAS EXECUTE on-battery

In upssched-cmd you need

case $1 in
   (on-battery) MSG="Power failure. Save your work!"
notify-send -a nut -u critical -t 60 $MSG ;;
   (*) logger -i -t upssched-cmd "Unrecognized command: \"$1\"." ;;
esac

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Roger Price]

On Fri, 9 Jun 2017, Robbie van der Walle wrote:


# NOTIFYMSG - change messages sent by upsmon when certain events occur
#
# You can change the default messages to something else if you like.
#
# NOTIFYMSG  "message"
#
# NOTIFYMSG ONLINE "UPS %s on line power"
# NOTIFYMSG ONBATT "UPS %s on battery"
# NOTIFYMSG LOWBATT "UPS %s battery is low"
# NOTIFYMSG FSD "UPS %s: forced shutdown in progress"
# NOTIFYMSG COMMOK "Communications with UPS %s established"
# NOTIFYMSG COMMBAD "Communications with UPS %s lost"
# NOTIFYMSG SHUTDOWN "Auto logout and shutdown proceeding"
# NOTIFYMSG REPLBATT "UPS %s battery needs to be replaced"
# NOTIFYMSG NOCOMM "UPS %s is unavailable"
# NOTIFYMSG NOPARENT "upsmon parent process died - shutdown impossible"
#


Lots more lines of comments.
Please remove comments and blank lines before posting in mailing lists. 
I gave up reading.

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Roger Price]

On Thu, 8 Jun 2017, Robbie van der Walle wrote:

After the first test and the NAS is restarted I had to change the 
setting battery.charge.low again to 80 


Does the NAS DSM reset battery.charge.low to 10 or is it internal to the 
UPS?  You will have to experiment by disconnecting the UPS control lead 
from the NAS and connecting it (if possible) to the Mac.  After setting to 
80 and a power off-on cycle is the value 80 or 10?


3. Users from the NAS are warned, not yet the Mac user.  Only when 
executing automatic power-fail shutdown. 


In upsmon.conf on the Mac, what are the values of NOTIFYMSG ONBATT and 
NOTIFYFLAG ONBATT?  Does program wall work on the Mac? It fails on a lot 
of Linux boxes with graphical interfaces - to get a message to the user, 
you have to use notify-send, which means setting up upssched.


7. No they didn’t restart. I know there is a setting on the NAS to 
activate this. I will check and try again. 


Does the NAS have a BIOS option "Power on when AC resumes"?

Roger
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Roger Price]

On Thu, 8 Jun 2017, Robbie van der Walle wrote:


  The "upsrw" command contacts upsd, so it sounds like you should be able 
to add a user to upsd.users on the NAS, and then run something like
  this on the Mac:

    upsrw -s battery.charge.low=80 -u upsmaster -s sekret UPS@synology

  Per http://networkupstools.org/docs/man/upsd.users.html , the "upsmaster" user 
would need at least "actions = SET". You will need to reload
  upsd after changing upsd.users.

I managed to do this, upsc reports: 

battery.charge.low: 80 instead of 10 
What is the purpose of changing this value?


When you carry out tests to ensure that the setup is working well, you 
will pull the power cord from the wall and wait until the UPS reaches LB. 
This means waiting and wasting time.  You can speed up the testing by 
setting LB very high so that the UPS reaches it quickly.  Later you can 
set a more reasonable value.



  If the UPS is not turning itself off after the NAS goes into safe mode, 
it might be possible to do this from the Mac. You probably have
  something like this in the Mac's upsmon.conf:

    SHUTDOWNCMD "/sbin/shutdown -h +0"

  You could add an UPS shutdown command before the Mac shutdown command:

    upscmd -u upsmaster -s sekret UPS@synology shutdown.stayoff

  but you would need to be sure that the UPS shutdown delay is long enough 
to allow the NAS to go into safe mode. (This is why it is
  recommended that the master (the NAS in your case) initiate the UPS 
shutdown.) Also, you would need to configure that NUT user to allow
  instant commands in upsd.users as well as upsrw access.

I have SHUTDOWNCMD "/sbin/shutdown -h +0” now on the Mac is was SHUTDOWNCMD “” 
before.



How do I check if the UPS is turning itself off after the NAS goes into safe 
mode? 


On most UPS units, there is a light which goes out.  Some produce an 
audible clunk as the relays disconnect the UPS power outlets. You could 
also connect a light bulb to a protected outlet.  It should go out when 
the UPS shuts down.


Example test:

1. Pull power cord from wall

2. UPS beeps, NAS and Mac continue operation

3. Users are warned that power has failed

4. When the battery drops to battery.charge.low the slave (Mac) and then 
the master (NAS) shutdown.


5. After 20 seconds the UPS shuts down.

6. Reconnect the wall power

7. NAS and Mac should restart

You will also need a test in which you wait a long time before step 6, 
and a test in which you reconnect power between steps 4 and 5.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Roger Price]

On Thu, 8 Jun 2017, Robbie van der Walle wrote:


I suppose I have to use -u for user? Which user? and -p  for password? 


Sorry, my typo, it should be

   upsrw -s battery.charge.low=80 -u upsmaster -p sekret UPS@NAS

upsmaster is the "user" declared in the NAS file upsd.users in square 
brackets.  It has nothing to do with /etc/passwd.  sekret is the password 
also declared in NAS file upsd.users.  See man upsd.users and man upsrw.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Roger Price]

On Wed, 7 Jun 2017, Robbie van der Walle wrote:


  Out of curiosity, when you shut down the NAS, do you run the
  command "upsdrvctl shutdown" ?  Do you see or hear anything to
  suggest that the delayed UPS shutdown has happened?

I don’t know where to search to answer this. The delayed UPS shutdown 
means that Synology NAS will turn off the UPS after the delay? 


Yes, See the User Manual http://networkupstools.org/docs/user-manual.pdf 
chapter 6.3 "Configuring automatic shutdowns for low battery events".


ups.delay.shutdown Interval to wait after shutdown with delay command 
(seconds). 

Shutdown of what?  I don’t know what is means. 


The NUT documentation is not always clear, and it looks as if the Synology 
is even less clear.  You must distinguish carefully between "system 
shutdown" and "(delayed) UPS shutdown".  The UPS is turned off _after_ the 
system.  There is a delay between the moment the upsdrvctl shutdown 
command is given and the moment the UPS shuts down.  The default is 20 
seconds, but you may have to increase this.



The commando upsrw cannot be found on the Synology NAS? 


I understand from 
https://tellini.info/2014/09/connecting-a-synology-diskstation-to-a-nut-server/ 
that the NUT configuration is hard coded into the NAS, and I suspect that 
the configuration is more or less broken.


You will need the utility programs upsrw and upscom which are part of NUT, 
but they should be available in the Mac.


Roger
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Roger Price]

On Wed, 7 Jun 2017, Robbie van der Walle wrote:


I am running NUT on a Synology NAS with attached a USB APC UPS.
  Do you have upsd and upsmon running as daemons on the Synology DSM?
Yes I have them both running on the Synology DSM: 
root      7236     1  0 Jun01 ?        00:00:16 /usr/sbin/upsd
root      7741     1  0 Jun01 ?        00:00:00 /usr/sbin/upsmon
root      7744  7741  0 Jun01 ?        00:00:12 /usr/sbin/upsmon


I see upsd and the first upsmon are running as "root".  They are often run 
as user "nut" or "upsd".



  Does the NAS shut down (and restart) correctly when wall power fails?
Yes it does and also the other Synology Nas which is attached via the 
network. It brings the Synology NAS in a safe-mode. 


I don't know the Synology NAS, but I guess that unless it is shutdown 
completely, it will still draw power.  Will the safe-mode drain the UPS 
completely, leading to a crash?


Out of curiosity, when you shut down the NAS, do you run the command
"upsdrvctl shutdown" ?  Do you see or hear anything to suggest that the 
delayed UPS shutdown has happened?


  Is the Mac protected by the same APC UPS as the Synology NAS? Yes 
it is. The power cable of the Mac is connected to the APC UPS. The 
dataport of the APC UPS is connected via USB with the Synology NAS. 


Apart from these points, it looks as if NUT is running correctly on the 
Synology NAS.


Now for the Mac: You will need to have upsmon running on the Mac
with a MONITOR declaration of the form

   MONITOR UPS@NAS 1   slave

Setting "slave" says that upsmon on the Mac is to shutdown the Mac as soon 
as LB is detected in the NAS.


I suggest

 1. Shutting down on LB rather than on a timer since it's easier to set 
up.


 2. On the NAS, use command

   upsrw -s battery.charge.low=80 -u upsmaster -s sekret UPS

to set the low limit very high during testing.  This will speed up your 
testing.  You can reset it to something else later.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Roger Price]

On Tue, 6 Jun 2017, Robbie van der Walle wrote:


I am running NUT on a Synology NAS with attached a USB APC UPS.


Do you have upsd and upsmon running as daemons on the Synology DSM?
Does the NAS shut down (and restart) correctly when wall power fails?


I am trying to connect and shutdown a Mac OS X system.


Is the Mac protected by the same APC UPS as the Synology NAS?

I have installed the NUT software and it looks like there is connection 
with the master but when battery gets low the Mac is not shutdown.


Do you have upsd and possibly upsmon running on the Mac?  What does 
command


   ps -elf | grep -E "ups[dms]|nut"

report on the Mac?


From the NAS, can you execute commands such as


   upsc UPS@Mac ups.status

Does upsmon.conf on the NAS contain a MONITOR statement for the Mac? Do 
you propose shutting down on LB or after a time interval: in other words, 
do you need upssched?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] POWERCOM-UPS-USB : UPS Shutdown

[Roger Price]

On Wed, 17 May 2017, Dinow Hsieh wrote:



CC. Does a Ubuntu user with no xterm window open see the message as part of
the

==> The root and remote user(ssh-putty) get the broadcasting message all
from terminal-window


Since all the users have xterm access, there's no problem.

To get back to your original problem that the delayed shutdown of the UPS 
did not happen, and that the power outlets were not disconnected.



NUT 2.7.4 includes file .../scripts/systemd/nutshutdown . Does Ubunti
install this?



==> Yes. Ubuntu haved installed this as below contents



dinow-All-Series:/lib/systemd/system-shutdown$ cat nutshutdown
#!/bin/sh
/sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown


It would be interesting to know if this script is really executed on a 
system shutdown.  Try adding line


   logger -t upsdrvctl "Calling for delated UPS shutdown"

The difficulty is that the NUT script is called very late when logging is 
probably no longer possible.  For this reason, I don't use the NUT 
nutshutdown script.  I prefer a systemd service unit


  # nut-delayed-ups-shutdown.service

  [Unit]
  Description=Initiate delayed UPS shutdown
  Before=umount.target
  DefaultDependencies=no

  [Service]
  Type=oneshot
  ExecStart=/usr/bin/logger -t upsdrvctl "nut-delayed-ups-shutdown.service
  calling upsdrvctl to shut down
  UPS unit"
  ExecStart=/usr/lib/ups/driver/upsdrvctl shutdown

  [Install]
  WantedBy=final.target

This service unit needs to be enabled with a command such as

  systemctl --system reenable
/etc/systemd/system/nut-delayed-ups-shutdown.service

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Fw: [Nut-upsdev] POWERCOM-UPS-USB : UPS Shutdown

[Roger Price]

On Tue, 16 May 2017, Dinow Hsieh wrote:


BB. Could you show us the output of command "upsc pcmups"?

==> Yes. Below 2 mode were the outputs of command "upsc pcmups"

battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 30
battery.date: 2010/12/20

...

ups.date: 2010/12/20
ups.load: 4

...

ups.status: OB DISCHRG


Is this battery really 6.5 years old?  Is this part of the problem?  One 
would not expect such a battery to support any load.  I notice that during 
the test, you have little or no load, since despite being in state OB 
DISCHRG the battery.charge is still 100.  It's best to perform such tests 
with a dummy load such as a table lamp and an old fashioned incandescent 
100 watt bulb.



ups.delay.shutdown: 20
ups.delay.start: 60


I wonder where the ups.delay.start: 60 comes from.  The NUT default value 
is 30 secs, and you do not change the value in ups.conf.



DD. Does wall successfully notify the users on an Ubuntu system?   If you
type

    echo "Hello from wall" | wall

do the users of Gnome, KDE, LXDE, LightDM etc see the message?

==> Yes. I used the putty and got below 3 messages
(Battery Power / Power Resotre / and type commands directly)


D3. Broadcast Message from dinow-Al
    (/dev/pts/0) at 11:02 ...

Hello from wall


I'm guessing that this output is in an xterm window or something similar. 
It shows that wall is working but does not show that the wall->Gnome, 
wall->KDE, wall->LXDE, wall->LightDM interfaces are working.  Does a 
Ubuntu user with no xterm window open see the message as part of the 
system notifications?


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Fw: [Nut-upsdev] POWERCOM-UPS-USB : UPS Shutdown

[Roger Price]

On Mon, 15 May 2017, Dinow Hsieh wrote:


==> I have tried this command "upsdrvctl shutdown" as below results (However 
the UPS still sustain the power)

    Network UPS Tools - UPS driver controller 2.7.1
    Network UPS Tools - Generic HID driver 0.38 (2.7.1)
    USB communication driver 0.32
    Using subdriver : PowerCOM HID 0.4
    Initiating UPS shutdown


Hi, Normally one would expect the UPS to disconnect it's power outlets 
after the default ups.delay.shutdown = 20 seconds.  Could you show us the 
output of command "upsc pcmups"?



CC. Do you have a script in a systemd system-shutdown directory which calls
"upsdrvctl shutdown" ?

==> No


Once the command "upsdrvctl shutdown" works, you will need to incorporate 
it in your shutdown process.  NUT 2.7.4 includes file 
.../scripts/systemd/nutshutdown . Does Ubunti install this?


 >   5. File = notifycmd
 >   #!/bin/bash
 >   #
 >   # NUT NOTIFYCMD script
 >   PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
 >   trap "exit 0" SIGTERM
 >   if [ "$NOTIFYTYPE" = "ONLINE" ]
 >   then
 >   echo $0: power restored | wall

Does wall successfully notify the users on an Ubuntu system?   If you type

   echo "Hello from wall" | wall

do the users of Gnome, KDE, LXDE, LightDM etc see the message?


    fi    6. File =upssched.conf
    CMDSCRIPT  /bin/upssched-cmd
    PIPEFN  /var/run/nut/upssched/upssched.pipe
    LOCKFN  /var/run/nut/upssched/upssched.lock


It doesn't look as if upssched will be called, since your NOTIFYCMD is 
pointing to your script and not upssched.  So upssched.conf will not be 
used.



BB. What does command "ps aux | grep ups"  report?

==> Yes. Below is the concise result
...
    nut  /lib/nut/usbhid-ups  -a  pcmups
    nut  upsd
    root  upsmon
    nut  upsmon


Perhaps the BSD syntax doesn't work on Debian, ps -elf | grep -E 
"nut|upsd|upsmon" would have been better.  I will make a note for next 
time.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Good Day NUT

[Roger Price]

On Thu, 11 May 2017, Dinow Hsieh wrote:

==> AA. I confront an issue that can't shutdown the ups    With the nut, 
I can get the ups status(upsc) and shutdown the linux-ubuntu when power 
failure occurs(upsmon)  But don't know which configuration I ignore to 
setup for ups shutdown


Hi, Could you show us your current configuration files?  Remove the 
comments and the blank lines.  What does command "ps aux | grep ups" 
report?


Do you have a script in a systemd system-shutdown directory which calls 
"upsdrvctl shutdown" ?


Roger___
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

[Roger Price]

On Tue, 4 Apr 2017, Arnaud Quette wrote:


Hi Jon, Stuart and the list

2017-04-04 1:09 GMT+02:00 Stuart Gathman :
  Which NOTIFYCMD is run when there is an ALARM?
  Have you specified that in your upsmon.conf?

  And that is the question of the hour.  How do you specify that?  Note
  that this is not the REPLBATT status we are talking about.

It's true that upsmon doesn't deal with ALARM, and that's definitely something 
missing.

What about adding a  "ALARM" to upsmon (and its .conf), and have 
it processing like other notifications?
That would mean to you can have WALL / SYSLOG notifications, along with EXEC 
reaction if NOTIFYCMD is set.


Hi Arnaud, It seems to me that, looking out into the future, there are 
three things upsmon needs:


1. A fall-through  of "UNKNOWN" so that all status changes, 
no matter how wierd, can be caught.  Such a catch-all  would 
also have caught the "ALARM" from the old battery.


2. A UPS specific option in the NOTIFYFLAG and NOTIFYMSG declarations as 
already provided by the AT declaration in upssched.conf.  This would make 
it possible to have messages and action specific to a UPS, in a multi-UPS 
configuration.


I would like to be able to specify

   NOTIFYMSG myups@localhost  ONBATT "%s: local UPS on battery"
   NOTIFYMSG bigups@serverONBATT "%s: Server room alert: UPS on battery"

   NOTIFYFLAG myups@localhost ONBATT SYSLOG+EXEC+WALL
   NOTIFYFLAG heartbeat@localhost ONBATT SYSLOG+EXEC

3. A  "ALARM" as you propose.

Best Regards, Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] how do you test (nagios) that upsmon is connected?

[Roger Price]

On Mon, 3 Apr 2017, Spike wrote:


I'll see if I can implement it some time soon.


Hi Spike, I tested the heartbeat proposal on openSUSE 13.1 and 42.2, and 
made some changes so that it would work.  I wrote out some documentation 
which includes the required changes, which you will find at 
http://rogerprice.org/NUT.html#HEARTBEAT


Roger

___
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

[Roger Price]

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


___
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

[Roger Price]

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

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Heartbeat validation of NUT integrity

[Roger Price]

This note describes a heartbeat technique for validating the integrity of 
a NUT installation.


Introduction


A NUT configuration may run for months with little or no output to a 
system administrator to assure that the combined processes are running 
correctly.  The technique described in this note verifies that the ups 
driver, upsd, upsmon, upssched and upssched-cmd components are operational 
and that the flow of data between them is effective.  The system 
administrator is warned if the overall combined process breaks.


Overview of the technique
-

An 11 minute upssched timer runs permanently, and when it completes, 
upssched-cmd sends a warning message to the sysadmin.  During normal 
operation the timer is prevented from completing by a timed process with a 
shorter 10 minute period running in a dummy UPS known as "heartbeat". The 
dummy UPS "heartbeat" cycles through an OL and an OB every 10 minutes, and 
the status changes are communicated to upsd and then to upsmon and 
upssched.  Thus every 10 minutes upssched stops and restarts the 11 minute 
timer.  During normal operation the 11 minute timer will never complete, 
but if the driver -> upsd -> upsmon -> upssched chain is broken, it will 
complete and the sysadmin advised.


The technique requires a working NUT installation and an understanding of 
upssched timers and the upssched-cmd script.


Changes to configuration files
--

1. In ups.conf, add

[heartbeat]
driver = dummy-ups
port = heartbeat.dev
desc = "Heart beat validation of NUT"

2. Create heartbeat.dev in the same directory as ups.conf with the 
contents


ups.status: OL
TIMER 300
ups.status: OB
TIMER 300

Remember that the are no comments in NUT .dev files.

3. In upsmon.conf, add

MONITOR heartbeat@localhost 1 upsmaster s3cr3t master

and make sure that you have specified

NOTIFYCMD /usr/sbin/upssched
NOTIFYFLAG ONBATT   SYSLOG+WALL+EXEC
NOTIFYFLAG ONLINE   SYSLOG+WALL+EXEC

Your upssched executable may be elsewhere. You may want to remove the 
WALL.


4. In upssched.conf, add

# Heart beat validation that NUT is operational.
# Restart timer which completes only if the dummy-ups heart beat has stopped.
# See timer values in heartbeat.dev 
AT ONBATT heartbeat@localhost CANCEL-TIMER heartbeat-failure-timer

AT ONBATT heartbeat@localhost START-TIMER  heartbeat-failure-timer 660

and make sure that there are no entries such as

AT ONLINE * ...
AT ONBATT * ...

Replace the "*" with the full address of the ups unit, e.g. 
myups@localhost


Make sure that you have specified

CMDSCRIPT /usr/sbin/upssched-cmd

Your upssched-cmd may be elsewhere.

5. In upssched-cmd, test for completion of the heartbeat-failure-timer and 
when it completes send a warning to the sysadmin, e-mail, SMS, pigeon, ...


Testing the heartbeat setup
---

1. Test that you can send a warning to the sysadmin with the command

   upssched-cmd heartbeat-failure-timer

2. When you start NUT, check that "heartbeat" is running. Command ps aux | 
grep ups should show something like


upsd 14785  0.0  0.0  13228   652 ?Ss   22:48   0:00 
/usr/lib/ups/driver/usbhid-ups -a myups
upsd 14787  0.0  0.0  19624   704 ?Ss   22:48   0:00 
/usr/lib/ups/driver/dummy-ups -a heartbeat
upsd 14791  0.0  0.0  17560   744 ?Ss   22:48   0:00 /usr/sbin/upsd 
-u upsd
root 14794  0.0  0.0  19432   664 ?Ss   22:48   0:00 
/usr/sbin/upsmon
upsd 14795  0.0  0.0  19856  1616 ?S22:48   0:00 
/usr/sbin/upsmon
upsd 14845  0.0  0.0   6408   448 ?S22:53   0:00 
/usr/sbin/upssched UPS heartbeat@localhost: On battery

3. Shorten the heartbeat-failure-timer in upssched.conf to 540 seconds, 
and you should receive a warning every 10 minutes.


4. If you leave the WALL in the NOTIFYFLAG ONBATT and NOTIFYFLAG ONLINE 
declarations in upsmon.conf you will see the action of the dummy-ups 
displayed in an xterm or equivalent console.


I have tested this setup with NUT 2.7.4 on openSUSE 13.2 and 42.2.
Comments and suggestions welcome.

Roger


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] how do you test (nagios) that upsmon is connected?

[Roger Price]

On Sat, 1 Apr 2017, Stuart Gathman wrote:


On 04/01/2017 03:14 PM, Dan Craciun wrote:

On my Nagios monitoring system I use check_nut_plus (that in turn
calls upsc) to monitor the status (ups.status), load (ups.load),
battery charge (battery.charge) and runtime (battery.runtime).

If these return "unknown", it means upsd is no longer monitoring the
UPS. As long as you get data, upsd is working.


That's great, but Spike wants to know whether *upsmon* is working.  He
already has a way to check that upsd is working.


How about using a dummy ups to set up a regular end-to-end heart beat. 
As long as the heart beats, there is no news, but if it stops, 
upssched-cmd sends out an e-mail or other warning.


In ups.conf, add

[heartbeat]
driver = dummy-ups
port = heartbeat.dev
desc = "Dummy ups sends heart beat to upssched-cmd"

In heartbeat.dev, write

ups.status: REPLBATT
TIMER 300

In upsmon.conf, write

NOTIFYFLAG REPLBATT SYSLOG+EXEC

In upssched.conf, add

# Heatbeat from dummy ups every 5 minutes, re-start 6 minute timer
AT REPLBATT heartbeat CANCEL-TIMER heatbeat-timer
AT REPLBATT heartbeat START-TIMER  heatbeat-timer 360

In upssched-cmd, if heatbeat-timer completes, then send "UPS heatbeat 
failure" message to sysadmin.


If this works, let me know, and I will use it myself :-)
It would be nice to have a HEARTBEAT status instead of using REPLBATT.

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Is a timer a file?

[Roger Price]

Hi Arnaud,

On Wed, 22 Mar 2017, Arnaud Quette wrote:


  The technique is very general and is to send SIGUSR1/SIGUSR2 to the upsd 
daemon.  SIGUSR1 and SIGUSR2 are events just like ONBATT and ONLINE.
  The patch runs successfully on my opensuse 13.2 box, and solves my 
problem. In upssched.conf I now have declarations such as

     AT SIGUSR1 * CANCEL-TIMER shutdown-timer

  Will my patches be included in NUT?

I've quickly checked your 2 patches.  The solution seems to me not broad 
enough for injecting upstream. This works nice for a single device / UPS 
setup, but would not make it when there are more devices, as I get it.


True, I use SIGUSR1 and SIGUSR2 which do not allow a payload such as a UPS 
unit name.  That would require SIGQUEUE, which accepts integers and 
pointers to other values (such as UPS unit names), but a Bash script can 
only send integers with SIGQUEUE.  Sending pointers to UPS unit names 
would require a new C program.  This would be a good programming exercise, 
but no-one has asked for such a facility in NUT.


I suspect that only a small percentage of NUT users use upssched timers.

At first sight, I would more see something injecting into the PIPEFN 
fifo, i.e. acting the same way upsmon would when calling upssched with 
the upsname and the triggering event.
I think that this can be solved more easily with tools like socat or nc, 
sending the command directly to the pipe. For example, to cancel the 
timer "shutdown-timer" from the upssched-cmd script, you would:


   echo "CANCEL shutdown-timer" | socat - 
UNIX-CLIENT:/var/run/nut/upssched.pipe


What a hack! :-) Sure, it is possible to do clever things with such tools, 
but I wanted something that used the .conf files to express the 
configuration.


I also considered using a dummy UPS with a .dev script written and erased 
as needed by a Bash script.



Please tell me back if such solution would make it for you.


For the moment I will stick with my SIGUSR patches.

I also realize that the distributed sample configuration and scripts do 
not fully match the doc. I'll make another round of update for this, 
still on the same branch.


I would warmly welcome your help to complete the documentation, both 
with part of your patches that make sense,


I think the user documentation would benefit from an explanation that 
there are two possible approaches to NUT configuration: Simple/optimistic, 
without timers, and pessimistic with timers.  And then a complete, fully 
worked example of the NUT setup for the simplest usage based on OB and LB 
(no timers).  The example on my website covers the pessimistic (with 
timers) approach only.



along with the above solution if it's good too.


I would not recommend putting a technique based on socat/nc/netcat in the 
NUT user documentation, but perhaps under a heading such as "Debugging" it 
would be worth having it in the Developer Guide.


Best Regards, Roger
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Is a timer a file?

[Roger Price]

On Tue, 21 Mar 2017, Arnaud Quette wrote:


Hi Roger,

reviving this discussion, since we have a Github ticket for 2.7.5:
https://github.com/networkupstools/nut/issues/293
... 

I've made some additions to clarify things on the timer, and complete the 
script:
https://github.com/networkupstools/nut/compare/upssched-doc?expand=1


Hi Arnaud, Your change to the documentation clears up what I had 
mis-understood.  The new text makes it clear that the upssched timers are 
an in-memory device, and that they can only be turned on and off with 
upssched.conf declarations such as


    AT ONBATT * START-TIMER onbattwarn 30
    AT ONLINE * CANCEL-TIMER onbattwarn


  Is there some other way of forcing routine cancel_timer from a script or 
a configuration file?

this is the last point to address, but I'd need to better understand prior to 
potentially taking action:
theoretically, each event that triggers a timer (like ONBATT) has a counterpart 
to cancel it (like ONLINE).
Ex (from the doc):
    AT ONBATT * START-TIMER onbattwarn 30
    AT ONLINE * CANCEL-TIMER onbattwarn

So is there any use case we're missing here?


My use case was for a UPS unit which gave transient stupid status changes 
such as "OL DISCHARG CHARG LB" when the battery was 100% charged.  It was 
an old MGE unit which has since died.


When the stupid status change occured, the LB began a system shutdown.  To 
overcome this unwanted stutdown, I wanted to start a 5 second timer, and 
when this ran out, upssched-cmd would review the situation, and decide if 
a shutdown was really needed.  If it was not needed, I had to cancel the 
system-shutdown timer.  I mistakenly assumed that such a timer was a file, 
and that it was sufficient to erase the file.


To solve the problem of cancelling an arbitrary timer from a script such 
as upssched-cmd, I submitted a proposal to nut-upsdev:


   [Nut-upsdev] Proposal for technique to stop a timer at any moment
https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007202.html

and a set of patches :

https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007203.html
https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007204.html

The technique is very general and is to send SIGUSR1/SIGUSR2 to the upsd 
daemon.  SIGUSR1 and SIGUSR2 are events just like ONBATT and ONLINE. The 
patch runs successfully on my opensuse 13.2 box, and solves my problem. 
In upssched.conf I now have declarations such as


   AT SIGUSR1 * CANCEL-TIMER shutdown-timer

Will my patches be included in NUT?

Roger
___
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 - General Concept Question

[Roger Price]

On Thu, 2 Mar 2017, Garrett Michael Hayes wrote:

I would like to set up a Linux host as a central monitoring system for 
UPSs throughout our network.  I’d like that system to be able to see the 
various UPSs basically in one of two ways:


1)  Tapping into a native network interface on the target UPS (such as some 
larger APC and Tripp-Lite UPSs we have)
2)  Talking to a Raspberry Pi connected to the UPS via a USB or serial 
cable (for lower end UPSs that don’t have network capability)

I’m interested in monitoring and alerting, not so much in making changes 
to the UPS settings or shutting down computers, etc.


I think it would be much easier to write a central monitoring script which 
talks to the instances of upsd monitoring the UPS units.  Let upsd do all 
the hard work of talking to the UPS's.


Roger___
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 configuration complicated by Stonith/Fencing cabling

[Roger Price]

On Sun, 5 Feb 2017, Tim Richards wrote:

Setup: Active/Passive Two Node Cluster. Two UPSes (APC Smart-UPS 1500 C) 
with USB communication cables cross connected (ie UPS-webserver1 
monitored by webserver2, and vice versa) to allow for stonith/fencing


OS OpenSuse Leap 42.2
NUT version 2.7.1-2.41-x86_64
Fencing agent: external/nut

Problem: When power fails to a single UPS, both nodes are shutdown. The 
node with the still powered UPS comes back up, but requires manual 
intervention to keep it providing services. I would like only the node 
with the “On Battery” UPS to shutdown.


I think your title hints at the solution.  What is the advantage of the 
cross-connection of the UPS units?  Wouldn't it be simpler to have each 
node connected to the UPS which supplies the power?  This is easier to set 
up, extends easily to n servers, and is independent of the stonith/fencing 
which I assume you use for other purposes.


The resupply of services problem seems to be that NUT on the node that 
comes back up will not restart until the other node restarts.


With a simpler setup, this problem should go away.

Roger
___
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 Client shuts down when performing runtime calibration on APC UPS

[Roger Price]

On Wed, 11 Jan 2017, Merk - Oliver wrote:


nas4free: /# more /usr/local/bin/upssched-cmd
#!/bin/sh


I would strongly recommend specifying which script interpreter is to be 
used: dash, bash, csh, ksh, ...  For example


 #!/bin/bash

There seem to be too many case statements in this script.


case "${1}" in
   shutdown-warning)
   _shutdowntimer=`configxml_get "//ups/shutdowntimer"`;
   _message="${_notifymessage}.
Shutdown imminent in ${_shutdowntimer} seconds.";;

   shutdown)


This is where a test looking for the letters "CAL" in ups.status is 
needed.  If found, then issue a modified message.



   _message="${_notifymessage}.
Shutdown in progress.";
   ONLINE)
   _notifymessage="UPS ${UPSNAME} - Running on line power";;


Isn't this just duplication?  Can $1 really take the value ONLINE ?


case "${1}" in
   shutdown-warning)
   _shutdowntimer=`configxml_get "//ups/shutdowntimer"`;
   _message="${_notifymessage}.
Shutdown imminent in ${_shutdowntimer} seconds.";;

   shutdown)
   _message="${_notifymessage}.


More duplication! Test needed here for "CAL" in ups.status. If found, no 
shutdown.



Shutdown in progress.";
   shutdown -p now ${_message};;


It looks as if this script needs a thorough code review.

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] unclear about expected shutdown behavior

[Roger Price]

On Sat, 24 Dec 2016, Spike wrote:

... from reading the docs it seems the UPS should power off, is that the 
case?


Yes, The UPS should be sent a "delayed shutdown" command, upsdrvctl 
shutdown, to tell it to shut down _after_ the box.  The amount of the 
delay can be set in ups.conf.  The UPS delayed shutdown turns off the 
output sockets on the UPS.  On some UPS's this gives an audible clunk.


The box correctly shuts down, but the UPS does not and, maybe as a 
consequence, the box never came back on its own (I waited a few 
minutes).


It looks as if the command upsdrvctl shutdown is not being executed. Does 
the Ubuntu distribution of NUT include a script to do this?


Roger

___
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 Client shuts down when performing runtime calibration on APC UPS

[Roger Price]

On Tue, 20 Dec 2016, Merk - Oliver wrote:

Last week I need to change the battery pack and then I needed to perform 
a runtime calibration. I used the web interface of the AP9630 card to 
start the runtime calibration. However, after 2min. of runtime 
calibration the SAN shut down!


This is because the UPS status goes "On Battery" during runtime 
calibration and this is the signal for NUT to shut down the Client.


Out of curiosity : Is there any difference between the output of command 
"upsc my-ups" during a runtime calibration and during a wall power 
failure?  Specifically, is there any difference between the ups.status 
values?


Roger

___
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 get NUT slave to connect to master

[Roger Price]

On Fri, 25 Nov 2016, Jonah Naylor wrote:

I'm still getting "Connection refused on the client cgi screen as well 
as in the shell it gives me UPS upsname@ipaddresshere is unavailable...


You reported that access works correctly from elsewhere on the master 
subnetwork.  Does access from the master subnetwork produce the "accepts" 
e-mail message generated by the hosts.allow specification ?


You need to test that this is working correctly.


Any ideas what I can try next to debug why it's not working.


Being able to ping from A to B does not guarantee that TCP gets through. 
Can you ssh from slave to master?


Are you intending to shut down the slave if wall power fails for the 
master?, or is it just for administrative access?


For general debugging, have you tried sniffing the two subnetworks with 
tcpdump to see if the slave traffic reaches the master or is blocked 
elsewhere?


If the slave traffic reaches the master, then running upsd with -DDD 
options might show something.


Also should the "allowfrom = clientIPaddresshere" line be in my monuser 
entry in upsd.users on the master, or should I take that out?


I have no experience of this option, perhaps others could help you there.

Roger

___
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 get NUT slave to connect to master

[Roger Price]

On Fri, 25 Nov 2016, Jonah Naylor wrote:


upsd : ipaddressofclientgoeshere


If it were me I would write

 upsd : ipaddressofclient :\
spawn (/bin/mail -r hosts.allow@localhost\
  -s '%s@%h accepted access to %d from %c'\
  sysadmin@somedomain) &  : ALLOW

 upsd : ALL :\
spawn (/bin/mail -r hosts.allow@localhost\
  -s '%s@%h refused access to %d from %c'\
  sysadmin@somedomain) &   : DENY

so I get a trace of what happens, at least during testing.


ups : monuser@127.0.0.1/32 monuser@masterstaticIP monuser@slavestaticIP


I'm not sure what you are trying to do here.  In any case, the 
daemon_list should specify upsd, not ups. See man 5 hosts_access.


Rogr

___
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 get NUT slave to connect to master

[Roger Price]

On Fri, 25 Nov 2016, Jonah Naylor wrote:

I don't think nut is built with TCP wrappers support, although the 
package is listed as depending on libwrap...


Why would you have such a dependency if nut didn't use TCP Wrappers?

I ran this command: ldd /sbin/upsd | grep libwrap.so and it has returned 
no output.


If I run that command I get

maria:~ # ldd /usr/sbin/upsd
linux-vdso.so.1 (0x78fa8000)
libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x7f05a4ea6000)
libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x7f05a4ab9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f05a489b000)
libc.so.6 => /lib64/libc.so.6 (0x7f05a44ed000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f05a42e9000)
libz.so.1 => /lib64/libz.so.1 (0x7f05a40d3000)
/lib64/ld-linux-x86-64.so.2 (0x7f05a510e000)
maria:~ #

No mention of libwrap, yet I have TCP wrappers compiled in.

Does this mean I have to compile from source or is there a way to add 
the tcp wrapper support?


If your binary does not include TCP Wrappers, then you don't need to add 
it, and you don't need /etc/hosts.allow.  If your binary does include it, 
you need /etc/hosts.allow.  You don't have to have TCP Wrappers, and you 
don't have to recompile.


Does your distribution have a mailing list which could answer the 
configuration question?


Roger

___
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 get NUT slave to connect to master

[Roger Price]

On Thu, 24 Nov 2016, Jonah Naylor wrote:

I installed Nut via apt-get, not from source (which I'd rather stick 
with if possible just for ease of security updates etc) - so I'm not too 
sure if TCP wrappers are there or available...


This could be the problem, am I still able to add the wrappers in with prebuilt 
packages?


Could you apt-get the source and look for the .spec file if your 
distribution has one.  The openSUSE distribution nut.spec file contains


%configure \
--disable-static \
--with-pic \
--sysconfdir=%{CONFPATH} \
--datadir=%{_datadir}/nut \
--with-all \
--without-doc \
--with-ssl \
--with-openssl \
--without-nss \
--with-wrap \ ...

which shows that TCP Wrappers are included.

I have the following declaration in the master's hosts.allow. (I have no 
hosts.deny file)


 upsd : localhost, LOCAL, 127.0.0.1,[::1]   : ALLOW
 upsd : ALL :  spawn (/bin/mail -r hosts.allow@localhost\
  -s '%s@%h (mybox) refused access to %d from %c'\
  roger@localhost) &: DENY

 # And now the denials which previously appeared in /etc/hosts.deny
 ALL :  ALL : DENY

You may need to add the IP address of your slave.

Roger

___
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 get NUT slave to connect to master

[Roger Price]

On Thu, 24 Nov 2016, Jonah Naylor wrote:


Hi can anyone please help.
Although I have two servers in the same cabinet/room and sharing the same UPS - 
they're on different networks.
I've tried everything I can find online, but whatever I do I can't get the 
slave nut client to connect to the master.
When testing then on the same LAN, they DO work - but how do I allow the IP of 
the slave to connect to the master when both on different networks?


Can you ping from one server to the other?  If not, then this is a 
network/subnetwork routing problem.  Is it a deliberate site policy that 
systems on diferent subnets cannot connect?  Are you the administrator of 
the networks? Do the network routers have rules to allow traffic between 
subnets? Can you see in the router logs where the traffic is blocked?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with failing Nut slave/client connection

[Roger Price]

On Sat, 15 Oct 2016, Jonah Naylor wrote:


HI again, Sorry I didn't mean to cause a security debate.
I'd like things to be secure of course, but I've got a dilema that I don't use 
DHCP and instead have a block of static IPs from my ISP.
So my nut server has 68.68.452.02 for example
and my two slave clients have 68.68.452.03 and .04
ideally I'd like to allow access for the whole static IP block to access the 
nut server machine.
I've tried all sorts in the nut.conf upsd.users and other config files but just 
can't get it to work.

Any advice or help would be really appreciated.


Is your NUT compiled with TCP-wrappers support included?

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS Shutdown

[Roger Price]

On Wed, 5 Oct 2016, Jeff Bowman wrote:

I’m trying to better understand OffDelay and OnDelay: 
http://networkupstools.org/docs/man/usbhid-ups.html#_extra_arguments


My server requires ~3½ minutes to shut itself down. Considering this I’m 
comfortable setting OffDelay to 300 (five minutes).


How does this work in conjunction with the UPS hardware? Does NUT 
immediately send a command to the UPS to wait for 300 seconds and then 
shut itself down, thereby allowing the server enough time to safely shut 
itself down as well?


Yes.

This is the only way I can think of that the arrangement can work. As 
it’s naturally impossible for a turned-off computer to send any command 
anywhere, an option for sending a “take-this-now-but act-on-it-later” 
command surely must exist.


The command is "upsdrvctl shutdown".

I’ll be initiating my own shutdown sequence as a result of NOTIFYCMD 
with a NOTIFYTYPE of ONBATT. My process will poll battery status for 
five minutes (to reduce false positives) before finally deciding to send 
individual shutdown commands to the server, NAS, other devices, etc. In 
other words, I’m going to write my own upssched, suited specifically to 
my platform and configuration needs.


Given this configuration, at what point will the 300 seconds start 
counting down? What trigger sends the actual command which in turn tells 
the UPS hardware to start that countdown? The documentation is unclear 
on this finer point.


The 300 seconds start when the effect of "upsdrvctl shutdown" reaches the 
UPS hardware.  See the diagrams at 
http://rogerprice.org/NUT.html#SYSD_RACE which assume an offdelay of 20 
seconds.


Roger___
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 unable to resolve host despite DNS working.

[Roger Price]

On Sat, 17 Sep 2016, Yevgeniy Kuksenko wrote:


Hello all, I have been having a problem with upsmon on Fedora 24 on boot. NUT 
is configured as a netclient to a Raspbian NUT server. After boot up upsmon
repeatedly says "connect failed: No such host". It is not able to connect at 
all until the service is bounced. This seems to indicate a name resolution
problem but shouldn't this auto correct once name resolution is working 
properly regardless? upsmon on the Raspbian NUT server works fine and is 
attached
to localhost:3493.

If I use an ip instead of a DNS name this config works correctly on boot.


Do commands on the client such as:

 echo "GET VAR ups01 battery.charge" | netcat ups.server.lan 3493
 echo "GET VAR ups01 battery.charge" | netcat 11.22.33.44 3493

reproduce the problem?  If so, the problem may be with the DNS rather than 
NUT.  What does command dig ups.server.lan on the client report?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with failing Nut slave/client connection

[Roger Price]

On Mon, 12 Sep 2016, Jonah Naylor wrote:


I have two linux servers both with static IPs not using NAT.
My slave can't connect to my host. Whatever I try.


I assume that these two machines are on the same LAN, so here are a few 
suggestions.  Can you ping from each one to the other?  Can you ssh from 
each one to the other?  Are they running firewalls?  Do both the firewalls 
allow traffic on port 3493?  Have you tested with netcat?  What do the 
firewall logs report?  Is there anything in dmesg, /var/log/messages or 
journalctl?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] How to get started (Windows)

[Roger Price]

On Sun, 11 Sep 2016, Jeff Bowman wrote:


But first I have to get it working  :-)


Have you seen 
https://grafenthal.de/wiki/index.php/Installation_Network_UPS_Tools_%28NUT%29_unter_Windows_Server_2012_USB 
which shows a working NUT configuration under Windows Server 2012. It's in 
german, but the configuration files are readable.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Errors when running on Windows

[Roger Price]

On Fri, 9 Sep 2016, Jeff Bowman wrote:


All of this leads me to the conclusion that NUT isn't working on my system. 
Here is my configuration:


What command(s) do you use to start NUT? Do usbhid-ups, upsd and upsmon 
start up?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] How to get started (Windows)

[Roger Price]

On Thu, 8 Sep 2016, Jeff Bowman wrote:

That said, is there a way to manually poll the driver for UPS/power line 
status? I ask because I can foresee a scenario such as this:

...
So I'd like to be able to remote in and check the status to make sure 
everything is OK. If not, then I can manually run my shutdown 
script/process and start the cycle all over again. (Note: running 'upsc 
ups@localhost' echoes only a blank line to the screen, as do both 
'upsmon' and 'upsd.')


Something is wrong here.  Is the daemon upsd running?  On a Unix/Linux 
system, the command ps aux | grep ups gives the report


 upsd 3196  0.0  0.0  13228   880 ? Ss août30   2:14 
/usr/lib/ups/driver/usbhid-ups -a Eaton-66781
 upsd 3200  0.0  0.0  17560   736 ? Ss août30   0:49 /usr/sbin/upsd -u upsd
 root 3203  0.0  0.0  19432   664 ? Ss août30   0:00 /usr/sbin/upsmon
 upsd 3204  0.0  0.0  19856  1612 ? S  août30   0:41 /usr/sbin/upsmon

I don't have any Windows boxes, but I guess there is a similar command on 
Windows.  What does it show?


Is it possible to ssh into the system which runs NUT, and then run command 
"upsc "?


So to confirm my understanding: You're stating that I'll want to do this 
via NOTIFYFLAG ONBATT SYSLOG+EXEC and NOTIFYCMD (no WALL in Windows), 
using that combination to run my script/process and skipping SHUTDOWNCMD 
altogether--correct?


Remember that I don't use windows or the LB status so my suggestion is 
only a suggestion.  Above all, you need to test thoroughly with your 
system and your UPS.


Given that a perfect data set is mission critical for you, I would 
recommend having a test rig where you can check that you can handle 
wall power return at every phase of NUT action.


Sounds good. Next up: how to then send the 'delayed shutdown' command to 
the UPS hardware itself? Does the driver automatically handle that?


The command upsdrvctl shutdown does this.  See man upsdrvctl.

I'd like everything to occur shortly after the OB signal, so as to 
preserve battery as much as possible.


"Shortly after" means using timers. If you want to preserve the battery 
charge, but not use timers, you need to use a combination of OB and LB and 
set your LB level high using a command such as


 upsrw -s battery.charge.low=60 -u upsmaster -p sekret my-ups

Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] How to get started (Windows)

[Roger Price]

On Thu, 8 Sep 2016, Jeff Bowman wrote:


I’ve been able to get the latest Windows port installed on my Hyper-V 2012 R2 
instance and start the service.

But as I’m an absolute beginner I’m not sure how to proceed further. I’ve 
browsed the archives, but discussions here tend to assume at least an
intermediate level of understanding; thus it’s still quite a bit over my head. 
Your patience and slow explanations are appreciated.

1. CLI error: I get an error when running ‘upsdrvctl start’: “Can't claim USB 
device [051d:0003]: libusb0-dll:err [claim_interface] could not claim
interface 0, win error: The requested resource is in use.”

2. Event log errors: As noted the service starts fine, but I’m getting these 
two errors on service stop--“Error stopping upsd (2)” and “Error stopping
upsmon (2).”

3. I don’t understand what’s meant by “shutting down the UPS.” (e.g. upsdrvctl,
http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-April/009652.html) 
Why would we want to do that? It should be the other way around--the UPS
stays running while the computer shuts down--no? Please clarify.


It's assumed in the NUT world that you are running a server which is a) to 
be shut down when wall power fails for too long, and which is b) to be 
brought back into service automatically when wall power finally returns.


a) is shutting down the server using the SHUTDOWNCMD

b) is more subtle.  After, and I repeat _after_, the server has shut down, 
the UPS unit must be put into a state where is can react to the return of 
wall power, and signal the server to restart.  A UPS which is left beeping 
cannot do that.  To get the server going again it is necessary to perform 
a "delayed shutdown" of the UPS unit itself.  This might be some 30 
seconds after the server has shut down.  Once the UPS unit is itself 
shutdown, it will react to a return of wall power by applying power supply 
to the server, and the server will, if the BIOS is set up correctly, power 
up, and resume duty.


The use of the term "shutdown" for both the server and the UPS unit is not 
the happiest choice, but we live with it.



4. What’s next? I’d like to configure things to run a simple batch file after 
[x] minutes of on-battery time.


There are two schools of thought for managing wall power loss.

 Optimist: Keep going as long as possible on battery and turn off the 
server when the low-battery signal is received.  No timer needed,  This is 
the simplest approach.


 Pessimist: Whenever OB is received, start timers to shut down the server 
after a short interval. Expect wall power to return and then fail again. 
Hope that the battery will recover enough between failures for the next 
shutdown.  This is for people with unreliable wall power supplies.  Using 
timers is more complicated.


If you want simplicity, use the LB state as your guide, and set up your 
upsmon.conf to react to it.  ( I don't do this, so the following is 
speculative. ) In upsmon.conf set


 NOTIFYMSG  LOWBATT "Power failure - system is shutting down"
 NOTIFYFLAG LOWBATT SYSLOG+EXEC+WALL
 NOTIFYCMD  /path/to/your/system-shutdown-batch-file

You don't use upssched.

If you want timers, look at http://rogerprice.org/NUT.html which contains 
a fully worked example.  It's more complicated.  You have been warned.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Any good SNMP tutorial?

[Roger Price]

On Wed, 17 Aug 2016, Brian Hilmers wrote:


Hello, I am looking for good instructions on how to configure NUT to receive 
SNMP Trap signals and how to shutdown a server. My setup is:

NUT: version 2.7.1-1ubuntu1, from package
OS: Ubuntu 14.04.5 LTS
UPS: Tripp Lite SMART3000RM2U


The only thing I was able to understand from the documentation is to an entry 
in ups.conf:

[tripplite-pa3]
   driver = snmp-ups
   port = tripplite-pa3.domain.com
   community = public
   mibs = ietf

Then start upsd:

root@dell1850:/etc/nut# upsd
Network UPS Tools upsd 2.7.1
fopen /var/run/nut/upsd.pid: No such file or directory
listening on 127.0.0.1 port 3493
listening on ::1 port 3493
Connected to UPS [tripplite-pa3]: snmp-ups-tripplite-pa3

And that is as far as I got. How does one receive a low battery warning and 
shutdown the server?


Have you seen the User Manual "6.3. Configuring automatic shutdowns for 
low battery events"? 
http://networkupstools.org/docs/user-manual.chunked/ar01s06.html#UPS_shutdown 
You need to have upsmon configured and running.


Have you seen "Configuring NUT for the Eaton 3S UPS on Ubuntu Linux" 
https://srackham.wordpress.com/2013/02/27/configuring-nut-for-the-eaton-3s-ups-on-ubuntu-linux/ 
with an example of upsmon configuration?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Best practice to shutdown hosts which has not NUT via upssched

[Roger Price]

On Thu, 14 Jul 2016, Dmitri Stepanov wrote:

Some of those hosts haven't NUT including upsmon (and other software 
which is not included by suppliers of the hosts) for a number of 
reasons. I don't need to inform not-NUT hosts about any UPS events, 
etc... but only shutdown all the hosts after upssched timer expired. So 
I think shutdown them via ssh would be enough and creating some 
replacement for upsmon is too much.


Perhaps it is possible to have a micro upsmon in the form of a cron job in 
every slave which, every minute, runs something like


 rprice@maria:~> X=$( echo "GET VAR my-ups battery.charge" | netcat -w1 
upsd-server 3493 )
 rprice@maria:~> if [[ "$X" =~ \"([0-9]*)\" ]] ; then Y=${BASH_REMATCH[1]}; 
else Y=999 ; fi
 rprice@maria:~> if [[ "$Y" -gt 35 ]] ; then echo "Carry on $Y" ; else echo 
"Shutdown $Y" ; fi
 Carry on 100

Different slaves could have different low battery values. I'm sure that a 
netcat expert would be able to find a way of executing netcat only once.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Best practice to shutdown hosts which has not NUT via upssched

[Roger Price]

On Wed, 13 Jul 2016, Dmitri Stepanov wrote:


   shutdown-all-hosts.sh contains:
# Linux hosts
HOSTLIST="sim iogate br"
for host in $HOSTLIST
do
...
 ssh $host halt -p
...
done



   shutdown-all-hosts.sh works fine if it runned manually.
   But it does not work even if I insert sleep 30 sec before upsmon -c fsd


When you say "it does not work", what are the symptoms? Does 
shutdown-all-hosts.sh get called?


System has installed far away (in China) and there is bad Internet 
connection, so I might have ability to connect and check log files in a 
few day or weeks. Now I know exactly only that NUTed hosts shutdown via 
NUT as expected and no one host listed in shutdown-all-hosts.sh script 
don't.


Roger, I would appreciate if you give me a hint how to "reproduce the 
NUT protocol ... ". Do you mean getting feedback to CMDSCRIPT about the 
"no NUTed" slaves indeed shutting down and/or some timing in NUT config 
files...?


Without knowing the details of your system architecture, it looks as if 
your system is very different from the typical case for which NUT is 
intended.  I'm assuming that your with-NUT machine is far away from the 
"slaves" with an unreliable connection.  In this case the "slaves" will 
have to be autonomous and decide for themselves if and when they shut 
down.  I notice that you set up the SSH connection only when you want to 
remotely order a slave shutdown.  Perhaps in your case it would be better 
to have the ssh link open all the time with a periodic "heartbeat" between 
the no-NUT slaves and the master-with-NUT. In other words, sim, iogate and 
br behave as masters, not slaves.



It is not good to shutdown from CMDSCRIPT the master itself. Is it correct?


If the no-NUT machines were autonomous, then NUT is in charge of just the 
with-NUT machine, and there is no problem with shutting down from the 
CMDSCRIPT.


Could you build a local version of your setup for testing?

Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Best practice to shutdown hosts which has not NUT via upssched

[Roger Price]

On Wed, 13 Jul 2016, Dmitri Stepanov wrote:


Hi

   I need to shutdown a number of hosts which has not NUT from one which has it.

   I tried to do it from upssched script (after upssched's timer) like this:

case $1 in
    earlyshutdown)
    logger -t upssched-cmd "Early shutdown is started"
    /bin/sh /usr/local/sbin/shutdown-all-hosts.sh
    /usr/local/sbin/upsmon -c fsd
    ;;
esac

   shutdown-all-hosts.sh contains:
# Linux hosts
HOSTLIST="sim iogate br"
for host in $HOSTLIST
do
...
 ssh $host halt -p
...
done
# Windows hosts
ssh shut@com "shutdown -s -t 0"

   shutdown-all-hosts.sh works fine if it runned manually.
   But it does not work even if I insert sleep 30 sec before upsmon -c fsd


When you say "it does not work", what are the symptoms? Does 
shutdown-all-hosts.sh get called?



   Also I read somewhere that it is not a good idea to shutdown other hosts 
from the CMDSCRIPT.


The User Manual chapter 7.2:

<< It’s not a good idea to call your system’s shutdown routine directly 
from the CMDSCRIPT, since there’s no synchronization with the slave 
systems hooked to the same UPS. FSD is the master’s way of saying "we’re 
shutting down now like it or not, so you’d better get ready". >> 
http://networkupstools.org/docs/user-manual.chunked/ar01s07.html


If you want to shutdown your slave systems siom, iogate and br from the 
CMDSCRIPT, you will need to reproduce the NUT protocol of "slaves first", 
then the master.  Your current protocol does not check that the slaves are 
indeed shutting down.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Driver Inform Sinus SS 230

[Roger Price]

Sorry if this is a duplicated message.

On Tue, 12 Jul 2016, Barbieri, Matteo wrote:

... a new model "Inform Sinus SS 230". Obviously I already saw on the 
official NUT website that the model is not supported, but I was wondering if 
there are some compatible drivers or maybe someone who are currently working 
on that model...


Hi, Since the Inform Sinus SS 210 is supported by the blazer_ser driver, try 
specifying that driver in ups.conf, and tell us how that goes.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS is not turned off in slave-only configuration?

[Roger Price]

On Wed, 22 Jun 2016, André Hänsel wrote:


Now, what I see is that when the UPS feeding server-1 goes LB, server-1 is
indeed shut down, but it seems that the UPS is never switched off.

This is a problem because when power is restored after shutdown, but before
the battery runs out (with no load, it continues for quite a while),
server-1 is not rebooted.


I'm assuming that you have one UPS per server, and that server-1 is fed 
by UPS-1.


When server-1 shuts down, whichever server is in charge of UPS-1 should 
execute command


 upsdrvctl shutdown UPS-1

Does this happen?  Is this command called by a script or a systemd service 
unit?  Is there any trace of the action of that script/service unit in 
/var/log/messages or the systemd journal?


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Besoin d’aide pour upssched

[Roger Price]

On Tue, 14 Jun 2016, Philippe Le Mesle wrote:


I finally received a delayed SMS saying power was back.


I'm guessing that your test action is to disconnect the building power 
from the UPS for a certain time and then re-connect.  How long do you 
wait?


Even when all the gear is permanently powered directly from the building 
and not the UPS, the command "upssched-cmd upssms" does not send an SMS 
when the UPS is disconnected from the wall socket, but does so correctly 
when the command is typed in directly. Have I understood correctly?


If this is what is happening then the next thing to check is whether when 
the UPS is disconnected the value "upssms" is indeed received by 
upssched-cmd.


Do you receive the notifications from upsmon correctly?

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Besoin d’aide pour upssched

[Roger Price]

On Tue, 14 Jun 2016, Philippe Le Mesle wrote:


Roger? Can your read me?


I receive a single e-mail from you via the list.  Remember that the 
mailing list very probably removes duplicates.  If you do not receive a 
copy of your own messages to the list, check your options on the list 
administration page.



The command from the command line works fine.


Then perhaps the way the UPS supplies power to other equipment is suspect. 
To check this, disconnect all the equipment connected to the UPS power 
outlets, leaving only the control line to the Linux box and the UPS input 
power cable.


Connect all that gear to a permanent wall power socket so that it is 
always powered, even if the UPS is turned off.  When everything is running 
again, pull the UPS power cord from the wall.  If the Linux box sends you 
an SMS, then you know that the SMS's are being blocked by some other 
equipment problem as suggested earlier.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Besoin d’aide pour upssched

[Roger Price]

On Tue, 14 Jun 2016, Philippe Le Mesle wrote:

"essayer la commande /usr/bin/upssched-cmd upssms manuellement sans 
passer par NUT." Là je ne comprends pas (je débute en Linux). Comment 
puis-je exécuter cette commande ,



PS: préférez-vous que cet échange soit en anglais ?


It is better to write in english on this list.  Also, please reply to the 
list, not to the writer.


In the same way that you can execute directly commands such as "date", "w" 
and "pwd", you can also execute "/usr/bin/upssched-cmd upssms" from the 
command line.  Try it!


Perhaps an introductory book to Linux would help you.

Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Besoin d’aide pour upssched

[Roger Price]

On Tue, 14 Jun 2016, Philippe Le Mesle wrote:


Voici ma configuration :
**
3/ le script /usr/bin/upssched-cmd
#!/bin/bash
case $1 in
upssms)
logger -t upssched-cmd "The UPS has been gone for 30 secs. Warn by sms..."
/bin/echo "Power failed. System will hibernate soon..." | curl "command"
;;

...

ups-back-on-power)
logger -t upssched-cmd "The UPS power has been restored."
/bin/echo "Power restored." | curl "command"
;;

...

esac

**
Le problème que je rencontre est le suivant :

quand je coupe l’électricité se coupe je ne reçois pas la notification 
par SMS (via CURL) alors que je reçois la notification quand 
l’électricité est rétablie.


Si je comprends bien, dans le cas ups-back-on-power, curl envoie un SMS, 
mais dans le cas upssms curl n'envoie rien.  Si ups-back-on-power marche, 
c'est que NUT marche correctement.  Alors il faut regarder de plus pres 
l'operation de curl.  Je suggere dans le cas upssms, ajouter -v à curl, et 
essayer la commande /usr/bin/upssched-cmd upssms manuellement sans passer 
par NUT.


(Try adding the -v option to curl in the case where it doesn't send an 
SMS, and run the command /usr/bin/upssched-cmd upssms manually)


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Is a timer a file?

[Roger Price]

On Sat, 4 Jun 2016, Charles Lepple wrote:


On Jun 3, 2016, at 6:48 AM, Roger Price <ro...@rogerprice.org> wrote:
... the timer.  I don't see it in /var/lib/ups where the locate tool 
finds upsd.pid, and I don't see it in /run or /var/run where I see 
upsmon.pid.


... it seems that the timers are only stored in memory. See 
checktimers(): 
https://github.com/networkupstools/nut/blob/master/clients/upssched.c#L129


Hello Charles, thanks for the link.  If timers are only stored in memory 
then the example given at 
http://networkupstools.org/docs/user-manual.chunked/ar01s07.html chapter 
7.2 is wrong.  It is not possible to turn off a timer with rm as shown in


#! /bin/sh
case $1 in
...
ups-back-on-power)
/bin/rm -f /some/path/ups-on-battery
;;
...
esac

This would explain the problem I have with a current script.

Is there some other way of forcing routine cancel_timer from a script or a 
configuration file?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Is a timer a file?

[Roger Price]

Hi, I'm trying to get a better understanding of what a timer is, so I 
added the following line to upssched.conf


 # Debug - turn on long-running timer to find out where upssched puts it
 AT ONBATT * START-TIMER where-am-I 1000

I can then start this timer by pulling the power cord from the wall for 
just a few seconds.


I now have 1000 seconds to find the timer.  I don't see it in /var/lib/ups 
where the locate tool finds upsd.pid, and I don't see it in /run or 
/var/run where I see upsmon.pid.


Is a timer a file?, and if it is, where should I find it?  Any suggestion 
would be much appreciated.  Thanks, Roger


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Low Battery event not occurring

[Roger Price]

On Fri, 13 May 2016, Kamran Khan wrote:

I have a TrippLite SMART2200RM2UN UPS.  I have installed and configured 
NUT as instructed on the website, and am able to monitor the status of 
the UPS without much problem.  The only problem I am seeing is that I 
cannot get the machine to actually send a Low Battery ( LB ) signal.  


When I run "upsc myups@localhost", the "battery.charge.low" is "10".  My 
current "battery.charge" is "6".  However, when I type "upsc 
myups@localhost ups.status", it only shows OB and DISCHRG, not LB.


If I understand the NUT process correctly, it looks for this LB status 
in order to create the POWERDOWNFLAG.  "In upsmon.conf, add a 
POWERDOWNFLAG directive with a filename. upsmon will create this file 
when the UPS needs to be powered off during a power failure when low 
battery is reached."


What does command

sudo grep -v -E "#.*$|^[[:space:]]*$" /etc/ups/upsmon.conf

report?

Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] cyberpower ups need to manully turn on the switch

[Roger Price]

On Sun, 8 May 2016, Min Wang wrote:


Hi
centos 6.3 uses traditional SysV script ( not systemctl)

here is the /etc/init.d/ups ( script) assuming it similar to nutshutdown


File /etc/init.d/ups is an administrative script which is used to set up 
the nut daemon - I was looking for a run-time script called by systemd, 
but since there is no systemd, could you run the attached Bash script 
which will prepare a report on your NUT configuration for you to post. 
Perhaps this will show what is not sending the "upsdrvctl shutdown" order.


Check the address C="/usr/sbin/upssched-cmd" You may not have a file 
upssched-cmd, or CentOS may put this somewhere else.


Roger

#!/bin/bash
# Report NUT configuration
# Remove comments, blank lines and passwords

C="/usr/sbin/upssched-cmd" # Please check !!
D="/etc/ups"   # Where does CentOS hide the UPC configuration?
T=`mktemp` # Temporary file
R="/tmp/NUT.report"# T without passwords

echo -e "NUT configuration`date --utc '+%Y-%m-%d %T %Z'`" > $T

# Configuration files, remove comments and empty lines
RE="^#.*$|^[[:space:]]*$"
for F in $D/nut.conf $D/ups.conf $D/upsd.conf $D/upsd.users $D/upsmon.conf 
$D/upssched.conf $C
 do echo -e "\n### $F ###" >> $T
   if [[ -f "$F" && -r "$F" ]] ; then
  cat $F | grep -v -E "$RE" >> $T
   else echo "Cannot access $F" >> $T
   fi
 done
# Get upsd rules out of hosts.allow
HA="/etc/hosts.allow"
echo -e "\n### $HA ###" >> $T
if [[ -f "$HA" && -r "$HA" ]] ; then
grep -v -E "^#.*$|^[[:space:]]*$" < $HA |
while read L || [[ -n "$L" ]]
do if [[ "$L" =~ ^.*(upsd.*)$ ]]
   then TRIM=$L  # Bash removes unwanted white space
echo $TRIM >> $T
   fi
done
else echo "Cannot access $HA" >> $T
fi

# Processes
echo -e "\n### ps aux ###" >> $T
ps aux | grep "/ups" | grep -v "grep" >> $T

# Ownership and permissions
echo -e "\n### Ownership and permissions ###" >> $T
ls -alF /usr/sbin/ups* >> $T
ls -alF /etc/ups/* | grep -v -E "~|stats|set" >> $T

# Remove password from report
L=`grep password $T | tr -d " \t\n\r"`
if [[ "$L" =~ ^.*=(.+)$ ]]
then PASS="${BASH_REMATCH[1]}"
  sed "s/$PASS/*/" < $T > $R
else # Could not find a password
  cat $T > $R
fi

echo "I have created file \"$R\" with a summary of your NUT configuration."
echo "Passwords have been removed."
rm $T;
exit

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] cyberpower ups need to manully turn on the switch

[Roger Price]

On Sat, 7 May 2016, Min Wang wrote:


I am using centos 6.3, and nut-2.6.5-2.el6.x86_64.
could you explain why not sending "a delayed command to the UPS to turn it off" 
may cause that issue?  


You need to stop the UPS from beeping.  Only then can you get a clear 
restart when power returns.  To stop the UPS from beeping, you must turn 
it off.



ups.delay.shutdown: 20
ups.delay.start: 30

is it something related?


Yes, they are related: the two ups.delay values are used by the program 
which turns off the UPS.  This program is called by by script nutshutdown 
which is part of the nut package.  Do you have this script installed?


What does command "systemctl status nutshutdown" report?

Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] cyberpower ups need to manully turn on the switch

[Roger Price]

On Sat, 7 May 2016, Min Wang wrote:

Hi  I have CP825AVR-G UPS.  sometimes the UPS is shutdown due to 
whatever reason. 


But the annoying thing is even if the electrical power is back, that UPS 
will continue to beep, and I have to manually turn on the switch button 
in order for it to supply the load/power.


I am wondering if there is any setting in the UPS I need to config? I 
just want the UPS to supply the power when the main electrical power is 
back.


It sounds as if you are not sending a delayed command to the UPS to turn 
it off.  Are you using a GNU/Linux distribution with systemd?  Which 
version of nut are you using? Do you have 
/usr/lib/systemd/system-shutdown/nutshutdown enabled?


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] KDE loses NUT wall notifications

[Roger Price]

On Wed, 28 Oct 2015, George Anchev wrote:


> However there was no any notification on desktop at


I'm guessing you use KDE and this may be a problem in the default way 
KDE treats the output of the "wall" program.  I don't have a KDE setup 
to test with,


Hi George, I finally have a 42.1 Leap to play with and it is clear that 
the wall notifications from NUT are getting lost in KDE Plasma. After 
fiddling with the notification options, the best I can get is a 4-second 
pop-up which is useless.


It seems to me to be a KDE problem.  Perhaps the opensuse-kde mailing list 
would be a better place to ask. http://lists.opensuse.org/


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Cannot access Patriot Pro II from new system

[Roger Price]

On Wed, 2 Dec 2015, Olav Seyfarth wrote:

I'd ideally set it to "shut down when only 20% battery left" (which 
should give at least five minutes power left, shutdown takes far less 
than one minute). BUT:



# upsc eaton@localhost
battery.charge: 89
*battery.charge.low: 20*
...

... but mine does not:


Could someone please point me to where (or what for) to look to 
configure that? Or is it not necessary? Or is my UPS not capable of 
triggering based on power left and I must use a time based setup (sleep 
in notifycmd) shown in this 
[https://srackham.wordpress.com/2013/02/27/configuring-nut-for-the-eaton-3s-ups-on-ubuntu-linux/] 
article? Or should I really have a script as complicated as in this 
[http://rogerprice.org/NUT.html] article? I really wan to keep things as 
simple as possible...


Hi, The UPS doesn't report its battery charge, but since the DB-9 pinouts 
described in the User Guide, page 11 include a "Low Battery Alarm" you may 
be able to get enough from this to avoid a timer-based shutdown.


You will probably need to do some experiments (without risking your 
server) to see what signals are received from the battery as it runs down 
to empty. For that you will need a suitable upsmon.conf with at least a

 NOTIFYFLAG LOWBATT SYSLOG+WALL
 NOTIFYFLAG ONBATT SYSLOG+WALL
 NOTIFYFLAG ONLINE SYSLOG+WALL

Roger


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] The system doesn't shutdown

[Roger Price]

On Wed, 2 Dec 2015, George Anchev wrote:

Did find a solution regarding the wall notifications?


Hello George, I'm still struggling to install openSUSE 42.1 with KDE. 
When I have this (almost) working, I will have a look at the effect of 
wall on KDE.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] The system doesn't shutdown

[Roger Price]

On Wed, 28 Oct 2015, George Anchev wrote:


P.S. There is a typo in your nut-delayed-ups-shutdown.service. Line:
ExecStart=/usr/bin/logger -t upsdrvctl "nut-delayed-ups-shudown.service calling 
upsdrvctl to shut down UPS unit"

shudown is missing a 't'. It is in the log message but might still be worth 
fixing for grepping.


Thanks! Fixed.


BTW why is that service in /etc/systemd/system/ and not in 
/usr/lib/systemd/system/ ?


Its quite possible that I put nut-delayed-ups-shutdown.service in the 
wrong place.  systemd is not evident.


Roger
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] The system doesn't shutdown

[Roger Price]

On Thu, 29 Oct 2015, George Anchev wrote:

Today I experienced something weird. As I was working, the system 
started a shutdown and did shut down, then the UPS got powered off and 
then back on - an expected behavior for a power fail situation. However 
there was no power failure!


...

Oct 29 10:46:46 i7 upsmon[2239]: UPS myups@localhost battery is low
Oct 29 10:46:46 i7 upssched[3581]: Executing command: ups-low-battery
Oct 29 10:46:46 i7 upssched-cmd[3583]: Calling upssched-cmd ups-low-battery
Oct 29 10:46:46 i7 upssched-cmd[3584]: Unrecognized command: ups-low-battery
Oct 29 10:46:46 i7 upssched[3585]: Timer daemon started
Oct 29 10:46:46 i7 upssched[3585]: New timer: shutdown-timer (35 seconds)
Oct 29 10:47:21 i7 upssched[3585]: Event: shutdown-timer
Oct 29 10:47:21 i7 upssched-cmd[3593]: Calling upssched-cmd shutdown-timer
Oct 29 10:47:21 i7 upssched-cmd[3594]: Shutdown timer reached: Calling upsmon 
-c fsd

...

It seems NUT has executed a shutdown because of low battery. However the 
battery was at 100% before shutdown and right after boot. I suspect this 
is just another case of those false positive alarms 
(disconnects/reconnects) which happen randomly and are also sometimes 
accompanied by messages for low battery (instantly followed by a message 
of battery ok). So I removed the +EXEC on certain lines in upsmon.conf:


NOTIFYFLAG ONLINE       SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT       SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT      SYSLOG+WALL
NOTIFYFLAG FSD  SYSLOG+WALL+EXEC
NOTIFYFLAG COMMOK       SYSLOG+WALL
NOTIFYFLAG COMMBAD      SYSLOG+WALL
NOTIFYFLAG SHUTDOWN     SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT     SYSLOG+WALL
NOTIFYFLAG NOCOMM       SYSLOG+WALL
NOTIFYFLAG NOPARENT     SYSLOG+WALL+EXEC

Can you confirm if that is enough as a measure not to initiate shutdown 
on low battery without actual power failure?


I had exactly the same thing two days ago with an MGE Ellipse 1500 in 
which I had changed the batteries.  Its clear that the script upssched-cmd 
should check the real battery charge before shutting anything down.  I'll 
look at this, but it will be next week at the earliest.


Meantime your change to the NOTIFYFLAGs is a good fix.

Also - what would be the proper config to *execute* a shutdown if there 
is a low battery but *only* when there is an actual power failure 
situation (i.e. the UPS is running on battery power)? [I suppose that 
might work for the "optimistic" setup]


At present I don't have an example, perhaps others could advise you.

Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] The system doesn't shutdown

[Roger Price]

On Wed, 28 Oct 2015, George Anchev wrote:


 ${sbinPath}upsmon -c fsd
In 'upsmon --help' I read: "- fsd: shutdown all master UPSes (use with 
caution)". What exactly does this line do?


My understanding is that it calls upsmon running as root to execute the 
command specified by SHUTDOWNCMD in upsmon.conf, and that it checks that 
it is running as root.



I decided to make a simple test with this script named test:

#!/bin/bash
MSG0=$'test'
echo $MSG0 | /usr/bin/wall
echo "abc"

If I run it as root, there is a notification - both in console and in 
KDE and "abc" in console. But if I attempt to run the test script it as 
upsd:

su - upsd -c "./test"
the result is only silence.


Its upsmon which executes the shutdown command, not upsd.  upsmon only 
accepts the -c values it understands, and will remind you of this if you 
try something else.


I don't know if upsmon is running as root or upsd when it calls wall for a 
shutdown.  If it is running as upsd then there could be a problem.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] The system doesn't shutdown

[Roger Price]

On Wed, 28 Oct 2015, George Anchev wrote:


Beautiful! The shutdown succeeded.


Did you see a line in the journal similar to this ?

 Oct 06 22:49:54 pinta nut-delayed-ups-shutdown[1854]:
 nut-delayed-ups-shudown.service calling
 upsdrvctl to shut down UPS unit


However there was no any notification on desktop at


I'm guessing you use KDE and this may be a problem in the default way KDE 
treats the output of the "wall" program.  I don't have a KDE setup to test 
with, but try looking at KDE's System settings -> Common appearance and 
Behaviour -> Applications and System notifications -> Manage notifications 
to find out what is happening.


It may also be something in your mesg y/n setting.  What does "mesg" 
report?


One thing that caught my attention: I have disabled the 
nut-delayed-ups-shutdown service one day ago (many reboots since then) 
in order to avoid the effect of the UPS self-shutting on normal reboot. 
After this last test right now, and after the system shut down 
completely I plugged the cord in and booted. However during the boot 
process the UPS powered off while the power was on and the boot was not 
yet complete (argh...). Then in a second or two, without me doing 
anything, the UPS got back ON and I started the computer - this time the 
boot was clean, without power off.


It seems this solves the problem to have a clean reboot without UPS 
powering off. However it looks like a misbehavior after all because the 
UPS is not supposed to shutdown if the nut-delayed-ups-shutdown service 
is disabled, right? Or is anything else shutting down the UPS itself?


Its systemd trying to "help" you.  OpenSUSE 13.2 includes a delayed UPS 
shutdown script in /usr/lib/systemd/system-shutdown/nutshutdown . I 
suggest you comment out the command in that script.


Another thing (a bit of a side question, I hope it is ok to ask): During 
the last 3-4 months (using simply KNotify about UPS connection states) I 
noticed that sometimes unpredictably a notification appears that the USB 
connection to the UPS is lost and a few seconds later another 
notification appears that the connection is restored. And this repeats 
to infinity. The only way to get out of it is to shutdown the machine, 
turn off the UPS, unplug the power and restart everything again. I had 
no luck finding a pattern when and why it happens. This has never 
happened before. The batteries are fairly new (changed late January 
2015) and there have been no power outages since then (maybe one or two 
for 2-3 minutes only). However I notice that a short power off test 
(like the one I just did) makes the battery fall from 100% to 85% for 
less than a minute and then charges very long to reach 100% again. A 
friend said he has noticed similar peculiarity with other MGE UPS units. 
Can you share thoughts on this? I hope you don't mind me asking.


Endless repetitions of (Communication lost - Communication 
re-established): its been reported before in this mailing list for various 
drivers, and others may know what causes it.  I suggest opening a new 
issue in this mailing list with a specific technical description.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] The system doesn't shutdown

[Roger Price]

On Tue, 27 Oct 2015, George Anchev wrote:


Oct 26 21:02:56 i7 upsd[2227]: Startup successful

...

Oct 26 21:02:56 i7 upsmon[2229]: Startup successful

...

Oct 26 21:04:51 i7 upsmon[2230]: UPS myups@localhost on battery
Oct 26 21:05:11 i7 upsmon[2230]: UPS myups@localhost on line power


Power was off for 20 seconds so you should have seen upssched activity. 
Could you run the nut-report utility which I have added to the "NUT on 
OpenSUSE" website in section 5.16. 
http://rogerprice.org/NUT.html#NUT_REPORT It probably has to be run as 
root.  This will generate a condensed presentation of your NUT 
configuration with passwords removed.


The output is a bit too much for an e-mail so the best way of presenting 
the result in file /tmp/NUT.report is to upload it to a free file hoster

such as filehosting.org and post the URL they give you here in this list.
You might want to use a throw-away e-mail address when dealing with 
filehosting.org.  I use Mailinator.com


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] The system doesn't shutdown

[Roger Price]

On Tue, 27 Oct 2015, George Anchev wrote:

Yes, that was the power off test. However the upssched-cmd script gave 
absolutely no signs of activity. Even it's logger lines don't show up in 
journalctl. No any permission error messages - nothing. Only the 2 
messages from upsmon - on battery and then on line power.


Here is the nut-report:
http://www.filehosting.org/file/details/518300/NUT.report


Hi George, Thanks for the report.  I think the problem may be in your 
upsmon.conf.  Could you try adding "+EXEC" to the NOTIFYFLAG declarations. 
These will then activate the NOTIFYCMD declaration which should cause 
upssched to get called.   Roger


### /etc/ups/upsmon.conf ###
RUN_AS_USER upsd
MONITOR myups@localhost 1 upsmaster * master
MINSUPPLIES 1
SHUTDOWNCMD "logger -t upsmon.conf \"SHUTDOWNCMD calling /sbin/shutdown to shut down 
system\" ; /sbin/shutdown -h +0"
NOTIFYCMD /usr/sbin/upssched
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/ups/killpower
NOTIFYMSG ONLINE"UPS %s on line power"
NOTIFYMSG ONBATT"UPS %s on battery"
NOTIFYMSG LOWBATT   "UPS %s battery is low"
NOTIFYMSG FSD   "UPS %s: forced shutdown in progress"
NOTIFYMSG COMMOK"Communications with UPS %s established"
NOTIFYMSG COMMBAD   "Communications with UPS %s lost"
NOTIFYMSG SHUTDOWN  "Auto logout and shutdown proceeding"
NOTIFYMSG REPLBATT  "UPS %s battery needs to be replaced"
NOTIFYMSG NOCOMM"UPS %s is unavailable"
NOTIFYMSG NOPARENT  "upsmon parent process died - shutdown impossible"
NOTIFYFLAG ONLINE   SYSLOG+WALL   <== add +EXEC to this line
NOTIFYFLAG ONBATT   SYSLOG+WALL   ...
NOTIFYFLAG LOWBATT  SYSLOG+WALL   ...
NOTIFYFLAG FSD  SYSLOG+WALL   ...
NOTIFYFLAG COMMOK   SYSLOG+WALL   ...
NOTIFYFLAG COMMBAD  SYSLOG+WALL   ...
NOTIFYFLAG SHUTDOWN SYSLOG+WALL   ...
NOTIFYFLAG REPLBATT SYSLOG+WALL   ...
NOTIFYFLAG NOCOMM   SYSLOG+WALL   ...
NOTIFYFLAG NOPARENT SYSLOG+WALL   up to this line
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] The system doesn't shutdown

[Roger Price]

On Mon, 26 Oct 2015, George Anchev wrote:


Hello,
I have been following the details in this article to configure my UPS:

http://rogerprice.org/NUT.html

However the system won't shutdown although file permissions look ok:

ls -alF /usr/sbin/ups*
-rwxr--r-- 1 upsd daemon 64984 Oct 15  2014 /usr/sbin/upsd*
-rwxr--r-- 1 upsd daemon 48584 Oct 15  2014 /usr/sbin/upsmon*
-rwxr--r-- 1 upsd daemon 31536 Oct 15  2014 /usr/sbin/upssched*
-rwxr--r-- 1 upsd daemon  1798 Oct 26 13:52 /usr/sbin/upssched-cmd*

When plugging the cord the only notification is "on battery/ line power" in 
journalctl and nothing happens.

When I run /usr/sbin/upssched-cmd as root the journal says:

Oct 26 20:22:37 i7 upssched-cmd[19433]: Calling upssched-cmd
Oct 26 20:22:37 i7 upssched-cmd[19434]: Unrecognized command:

However when trying su - upsd -c "/usr/sbin/upssched-cmd" I don't get this 
output in journalctl although the file permissions look ok.

What might be wrong?


Could you show us the output of the utility script nut-journal ? Chapter 
5.15 in the referenced article.


Roger___
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 configuration problem

[Roger Price]

On Mon, 26 Oct 2015, George Anchev wrote:


> The best way to shut down becomes a power disconnection.

Hm. Not quite convenient for a dual boot system. Actually that 
contradicts the very idea of being the power being non-interrupted. 
Isn't there any way to reporgram the service to distinguish between 
shutdown and reboot? Or even better - between shutdown induced by a 
power loss and normal shutdown. I suppose it is best for the UPS not to 
be shut off while the PC is off when there is wall power?


The setup described in the article is for an unattended server running in 
an uncertain electrical environment.  If you use your machine primarily as 
a desktop station, then in your case it might be better to remove the bios 
option "restart on power return", and leave the PC off until you need it.


Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] No power cycle after shutdown on Atlantis Land OnePower A03-S1001

[Roger Price]

On Wed, 14 Oct 2015, Davide Baldini wrote:

Is there any command in the list provided by "upscmd -l myups" which is 
accepted by this UPS?


None of the command sin the list successfully completes, not even 
beeper.toggle.


It looks as if the problem is more general than turning off the UPS. The 
command mechanism is broken.



I added -q and -D to /etc/nut/ups.conf, as:

 [myups]
   driver = nutdrv_qx -D -q
   port = auto

I couldn't find more info on where to append driver parameters, not sure if 
that's the correct way. After that, I restarted nut with:


 # service nut-server restart
 # service nut-client restart


My naive reading of function conf_args in common/upsconf.c is that only 
the form driver = something is seen, any additional parameters are 
ignored.


I'm not sure how to add a debugging option to a "service" call in 
Debian.  Is /etc/init.d/nut-client a Bash/Dash script?  Is it possible to 
add the option to the call of the driver in this script?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] No power cycle after shutdown on Atlantis Land OnePower A03-S1001

[Roger Price]

On Wed, 14 Oct 2015, Davide Baldini wrote:


the full output of upsc ${myups} is at https://pastebin.mozilla.org/8849188 ;
in particular:

ups.delay.shutdown: 30
ups.delay.start: 180

However, the UPS does not shut down, not immediately nor well after the 
timeout of the command: upscmd -u admin -p mypass myups shutdown.return 360


What does "ps aux | grep ups" report?  Does "upsdrvctl shutdown" have any 
effect?  Make sure that your box is not taking power from the UPS when 
you do this.  Load the UPS with a table lamp so that you see any shutdown.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] No power cycle after shutdown on Atlantis Land OnePower A03-S1001

[Roger Price]

On Wed, 14 Oct 2015, Davide Baldini wrote:


upsdrvctl shutdown
...
 instcmd(shutdown.return, [NULL])
 instcmd: FAILED
 Shutdown failed!
 Driver failed to start (exit status=1)

This time /var/log/syslog doesn't register anything about the UPS after 
issuing the command above. Instead, It logged some errors after a

 upscmd -u admin -p mypass myups shutdown.return 360

These logs are reported in my second mail of this thread.



Oct  6 19:03:07 debianBunker upsmon[3115]: UPS myups at localhost on
 battery
Oct  6 19:03:07 debianBunker upsd[2946]: Instant command: admin at
 127.0.0.1 did shutdown.return with value "360" on myups
Oct  6 19:03:07 debianBunker nutdrv_qx[2936]: instcmd(shutdown.return,
 360)
Oct  6 19:03:07 debianBunker nutdrv_qx[2936]: instcmd: FAILED


Is there any command in the list provided by "upscmd -l myups" which is 
accepted by this UPS?


Do the driver options -q or -D produce any further information about the 
failure?


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] NUT with openSUSE 13.2

[Roger Price]

I have been looking closely at using NUT with openSUSE 13.2.  Here is
a quick summary.

1. Like the alien plant in the Quatermass Experiment, systemd is
reaching into every corner of the distribution.  New systemd service
units exist in /usr/lib/systemd/system:

 Power devices information server, nut-server.service, starts upsd
 Power devices monitor and shutdown controller, nut-monitor.service, starts 
upsmon
 Power device driver controller, nut-driver.service, starts upsdrvctl

The first two need to be enabled using Yast => System => Services
Manager for them to start automatically when the box is turned on.

nut-driver.service needs fixing. Replace

 ExecStart=/upsdrvctl start
 ExecStop=/upsdrvctl stop

with

 ExecStart=/usr/lib/ups/driver/upsdrvctl start
 ExecStop=/usr/lib/ups/driver/upsdrvctl stop

2. On my box, openSUSE hangs for 30 seconds trying to shut down a WiFi
connection. This increases the system shutdown time, so I increased
offdelay and ondelay in ups.conf by 30 seconds.

3. openSUSE have declared TCP-wrappers to be "abandon-ware", but the
libwrap package is installed and used by a half dozen programs.  In
release 13.2 openSUSE compile NUT with the wrappers, but other
programs, such as openssh are now stripped of their wrappers.

4. All logging goes to systemd's journalctl - there is no more
/var/log/messages.  Since journalctl provides extraction by service
unit rather than by tag, I wrote a Bash script to extract the lines
generated by NUT activity.

 #! /bin/bash
 # nut-journal Display NUT activity recorded by journald for
 # previous complete boot and current (unfinished) boot.

 TEMPFILE=`mktemp`
 JOURNALCTL=/usr/bin/journalctl
 NUT_ACTIVITY="upsd|upsmon|upssched|upsdrvctl"

 # Does user have access to journalctl for upsd?
 $JOURNALCTL -b 0 -n 10 --no-pager > /dev/null
 if [ $? -eq 0 ]; then :
else echo "Welcome to nut-journal"
 echo "You do not seem to have access to the journal"
 echo "for system commands such as those of NUT."
 echo "Ask your system administrator to add your"
 echo "account to the systemd-journal group."
 echo "When this is done, log out and then log in"
 echo "and try again."
 exit 1
 fi

 echo "Previous complete boot through shutdown" > $TEMPFILE
 $JOURNALCTL -b -1 --no-pager | grep -E $NUT_ACTIVITY >> $TEMPFILE
 # Include Journal stopped message
 $JOURNALCTL -b -1 -n 1 --no-pager | tail -n 1 >> $TEMPFILE
 echo "Current boot" >> $TEMPFILE
 $JOURNALCTL -b  0 --no-pager | grep -E $NUT_ACTIVITY >> $TEMPFILE
 less $TEMPFILE
 rm $TEMPFILE

5. openSUSE supply a script to shutdown the UPS.  The script
"nutshutdown" sits in systemd drop-in directory
/usr/lib/systemd/system-shutdown/ and automatically executes

 /usr/sbin/upsmon -K >/dev/null 2>&1 && /usr/lib/ups/driver/upsdrvctl shutdown

There is no trace in the log of the action of this script.

I personally prefer a traceable service unit for shutting down the
UPS, so I replaced the openSUSE script with
nut-delayed-ups-shutdown.sevice enabled by Yast => System => Services
Manager.  For details of this and a more complete discussion of NUT
with openSUSE 13.2, see http://rogerprice.org/NUT.html

Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Roger Price]

On Tue, 8 Sep 2015, Rob Groner wrote:

I executed lsusb to verify the USB device is there, and it is.  I tried 
the shutdown command again with debug enabled, but it didn't seem to 
reveal much more:

---
rtd@linux-5048:~> sudo /usr/local/ups/sbin/upsdrvctl -D shutdown
Network UPS Tools - UPS driver controller 2.7.2.6_RTD

...

  0.000137 Shutdown UPS: rtdups
  0.000160 exec:  /usr/local/ups/bin/usbhid-ups -a rtdups -k
Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD)
USB communication driver 0.32
Can't claim USB device [2a37:5110]: No such file or directory
  0.007491 Driver failed to start (exit status=1)
---


Hello Bob, What happens if you execute the command

  /usr/local/ups/bin/usbhid-ups -a rtdups -k -DDD

Best Regards, Roger


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Roger Price]

On Tue, 8 Sep 2015, Rob Groner wrote:


Roger,

rtd@linux-5048> sudo /usr/local/ups/bin/usbhid-ups -a rtdups -k -DDD
Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD)
USB communication driver 0.32
  0.00  debug level is '3'
  0.000405  upsdrv_initups...

...

  0.004555  Checking device (2A37/5110) (001/005)
  0.005862  - VendorID: 2a37
  0.005876  - ProductID: 5110
  0.005884  - Manufacturer: RTD Embedded Technologies, Inc.
  0.005891  - Product: UPS25110
  0.005898  - Serial Number: 123456789ABC
  0.005906  - Bus: 001
  0.005914  Trying to match device
  0.005927  Device matches
  0.005940  failed to claim USB device: Device or resource busy
  0.005954  failed to detach kernel driver from USB device: No such file or 
directory


Hello Bob, I'm not an expert in usbhid-ups: perhaps someone else on this
list can explain what's happening at 0.005940.  Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Roger Price]

On Fri, 4 Sep 2015, Rob Groner wrote:


Well, I tried the same script method with openSUSE 13.2, and it still did not 
execute.

So I tried the system method, and it worked 1 time out of 3 attempts.  I 
captured the last failure:
2015-09-04T11:43:38.825317-04:00 linux-5048 upsdrvctl[1887]: Can't claim USB 
device [2a37:5110]: No such file or directory
2015-09-04T11:43:38.825970-04:00 linux-5048 upsdrvctl[1887]: Network UPS Tools 
- Generic HID driver 0.39 (2.7.2.6_RTD)
2015-09-04T11:43:38.826243-04:00 linux-5048 upsdrvctl[1887]: USB communication 
driver 0.32
2015-09-04T11:43:38.826934-04:00 linux-5048 upsdrvctl[1887]: Driver failed to 
start (exit status=1)
2015-09-04T11:43:38.827185-04:00 linux-5048 upsdrvctl[1887]: Network UPS Tools 
- UPS driver controller 2.7.2.6_RTD


I'm confused here - the Bash script, and the systemd service unit, are for 
_shutting down_ the system on power failure, but in the trace you are 
having a problem _starting_ the driver.



Is it possible the USB bus is going away before that can execute?


I havn't tested with openSUSE 13.2 so there may be something in it which 
prevents the driver from connecting to the UPS.  Perhaps with a more 
detailed trace using the upsdrvctl -D option it may be possible to see 
more clearly.


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Roger Price]

Hello Bob,

I had preferred the shutdown script method because it was a little more 
straight-forward, and possibly more portable.  This guide is meant to 
help people get the UPS up and running, whatever their Linux distro. I 
don't know how common the systemd implementation is across various Linux 
distros.


You will need to support Linux systems with and without systemd for some 
time.  For example SUSE Linux Enterprise Desktop 11 which does not use 
systemd will be supported until 31 Mar 2019 and SUSE Linux Enterprise 
Server 11 will be supported until 31 Mar 2022. 
https://www.suse.com/lifecycle/


I assume that to undo the systemd service unit method, I do something 
like "systemctl --system disable /etc/syst.."?


Yes.  That will remove the soft link.

Best Regards, Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser