Re: [Nut-upsuser] Trying to update the official docs for nut on FreeNAS - help needed to ensure it's written correctly
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
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
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
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
On Thu, 28 Dec 2017, Charles Lepple wrote: On Dec 28, 2017, at 6:35 AM, Roger Price 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
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
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
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
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
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
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
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
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
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
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
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
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
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 ... /u
Re: [Nut-upsuser] How do I configure NUT?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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?
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?
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?
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
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
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
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] NUT Client shuts down when performing runtime calibration on APC UPS
On Wed, 11 Jan 2017, Merk - Oliver wrote: I've setup nas4free (latest version 11.0.0.4, which has NUT 2.7.4) in a VM and configured it via webinterface to my APC UPS and set "shutdown mode" to "UPS goes on battery" with a timer of 30s. --- nas4free: etc# more upssched.conf CMDSCRIPT /usr/local/bin/upssched-cmd PIPEFN /var/run/upssched.pipe LOCKFN /var/run/upssched.lock AT COMMOK * EXECUTE notify AT COMMBAD * EXECUTE notify AT REPLBATT * EXECUTE notify AT NOCOMM * EXECUTE notify AT FSD * EXECUTE forced-shutdown AT NOPARENT * EXECUTE notify AT SHUTDOWN * EXECUTE notify AT ONLINE * CANCEL-TIMER shutdown AT ONLINE * EXECUTE resume AT ONBATT * START-TIMER shutdown 30 AT ONBATT * EXECUTE shutdown-warning AT LOWBATT * START-TIMER shutdown AT LOWBATT * EXECUTE shutdown-warning You have specified AT ONBATT * START-TIMER shutdown 30 which means that in 30 seconds after an OB appearing, script "/usr/local/bin/upssched-cmd shutdown" will be called. I'm guessing that this script has forgotten to test for "CAL" in ups.status. You specify AT LOWBATT * START-TIMER shutdown without the timer value. To the best of my knowledge this is undefined in NUT. Safer to specify the timer value. 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
On Sat, 24 Dec 2016, Charles Lepple wrote: ... after the switch to systemd. https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1512603 https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1603609 (includes workaround) Ah, systemd, what crimes are committed in thy name! 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
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
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
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
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
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
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
On Thu, 24 Nov 2016, Jonah Naylor wrote: The servers can ping each other... The router log doesn't show anything and I am the admin for the servers. The machines firewalls allow each other's ips etc. Part of the issue is possibly that I just don't know if I've set up NUT correctly for this arrangement? Like I say it works ok on LAN, but not across networks. Is there something I should be doing other than adding "allowfrom = ipaddressofslave" to the upsd.users file on the master? Does your NUT have TCP wrappers compiled in? In that case is /etc/hosts.allow on the master set to allow the traffic? When you issue a NUT command on the slave, addressed to the master, does tcpdump on the master's subnetwork show the traffic to port 3493? 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
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
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
On Wed, 5 Oct 2016, Mike wrote: I have found the shutdown delay to be quite elusive within the NUT realm. I have asked for the kind folk of this mailing list to post those UPS's which actually can implement the shutdown delay concept. I have not seen anything posted, here or on the website, to that effect. Nor have I seen any manner of documentation in the various UPS profiles that would suggest whether or not a specific UPS actually obeys and complies with the shutdown delay concept. Something as critical as the shutdown delay should be so supremely documented that it is child's play. But it is not. It currently is wizardry, if it exists at all. Hi Mike, The current NUT has evolved from a little documentation and a lot of experimenting. As an example of the lack of manufacturer's documentation, see Eaton's "POWER FAILURE SHUTDOWN TIMELINE" for their products. https://powerquality.eaton.com/Products-services/Power-Management/Software-Drivers/lansafe-help/LSHelp301.htm This page, from a leading UPS manufactuer fails to document the offdelay, which is hidden in the yellow bars labelled "System Shutdown". It does succeed in describing the Power-On Delay. It is not possible for NUT to take over the documentation of the idiosyncracies of each UPS. All NUT can say is "Try this with your UPS". However there is a need for a minimalist description of a working NUT setup. * A drawing and three sentences each to describe the NUT components (without upssched). * A working example of a set of configuration files for a single workstation which will shut down the workstation and the UPS when LB is reached. One sheet of A4. Or the electronic equivalent. We are looking for a volunteer to draft this sheet :-) 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 Shutdown
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.
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
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)
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
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)
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)
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] Panic timeout?
On Wed, 7 Sep 2016, Dark Penguin wrote: First of all, please forgive me is this question has already been covered in these mailing lists; the "Search mailing list" link is dead, and I've only read the most recent monthly archives. I often have a situation where, for one of many possible reasons, the UPS always thinks that its battery is critical. And I'm even fine with a situation when it's an emergency shutdown right from the beginning. However, every once in a while my UPS (APC SU1000) likes to do short self-tests, and sometimes my AC power blinks for a split second. Neither of those are of any concern, but they make the UPS go into "OB LB" state for a few seconds. And just because of something insignificant like this, my whole system goes down. A familiar problem. I use openSUSE and the UPS is an MGE/Eaton Ellipse 1500. I see wierd transient statuses such as "OL DISCHRG CHRG LB" which were bringing my box down. Is there a way to set a timeout for "how long to wait after seeing "OB LB" before raising the FSD flag"? I want NUT to be a bit less hasty, and only shut down if it sees "OB LB" for at lest ten or even twenty seconds. I can easily spare ten more seconds of the critical state, but I want to avoid everything going down because of one second in the critical state. (That would also allow me to "train" the UPS much easier by cutting the power and knowing that I have a few seconds to turn it back on once the UPS goes to emergency beeping.) After a lot of trial and error, I use the upssched timers as defined in the configuration file upssched.conf # Defective UPS shows low battery for no reason AT LOWBATT * EXECUTE ups-low-battery AT LOWBATT * START-TIMER check-low-battery-timer 5 AT LOWBATT * START-TIMER low-battery-shutdown-timer 65 In script upssched-cmd, the event ups-low-battery logs a message suggesting a possible problem. At the timeout of check-low-battery-timer, I check the UPS status and charge. It's usually OL and 100% charged. So I send an e-mail to the sysadmin and then turn off the low-battery-shutdown-timer. Turning off the timer is the delicate part. This is not a native NUT operation. I patched NUT 2.7.4 to add the facility of sending SIGUSR1 and SIGUSR2 to the upsd daemon. These signals create new NUT events, and allow me to add the lines NOTIFYMSG SIGUSR1 "SIGUSR1 received" NOTIFYFLAG SIGUSR1 SYSLOG+WALL+EXEC to upsmon.conf, and AT SIGUSR1 * CANCEL-TIMER low-battery-shutdown-timer to upssched.conf. About once a month, when the UPS gives me a false LB, I get some warnings on-screen and a summary e-mail, but the server carries on. I submitted the patches to the NUT development mailing list https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007202.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] Any good SNMP tutorial?
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
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
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
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
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?
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
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
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
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
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?
On Sat, 4 Jun 2016, Charles Lepple wrote: On Jun 3, 2016, at 6:48 AM, Roger Price 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?
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
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
On Mon, 9 May 2016, Min Wang wrote: HIin centos: C="/usr/bin/upssched-cmd" Noted, thanks. here is the output of that file: ### ps aux ### nut 2651 0.0 0.0 43396 1116 ? Ss May07 0:08 /usr/sbin/upsd root 2654 0.0 0.0 39116 1172 ? Ss May07 0:00 /usr/sbin/upsmon nut 2655 0.0 0.0 41208 1300 ? S May07 0:03 /usr/sbin/upsmon My NUT setup shows: upsd 2859 0.0 0.0 13228 880 ? Ss avril24 3:16 /usr/lib/ups/driver/usbhid-ups -a Eaton-66781 upsd 2863 0.0 0.0 19860 1052 ? Ss avril24 0:34 /usr/sbin/upsd -u upsd root 2866 0.0 0.0 19400 656 ? Ss avril24 0:00 /usr/sbin/upsmon upsd 2867 0.0 0.0 19824 824 ? S avril24 0:30 /usr/sbin/upsmon Note the extra "upshid-ups" line. If your driver is not running then perhaps that explains why the UPS shutdown command is not being sent. What does command grep usbhid /var/log/messages 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
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
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
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
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] The system doesn't shutdown
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] Cannot access Patriot Pro II from new system
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
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
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
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
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
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
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] NUT configuration problem
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] The system doesn't shutdown
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] No power cycle after shutdown on Atlantis Land OnePower A03-S1001
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
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
