UPSSCHED doesn't work correct with multiple UPSs

[shgubar]

HI,
My configuration consists of two UPS.

System: Debian Buster
NUT: 2.8.0.1 (installed from source)

upsmon.conf

MONITOR riello1000@localhost 1 user pass primary
MONITOR rps1000@localhost 0 user pass secondary

upssched.conf

AT ONLINE riello1000@localhost START-TIMER upsgone 60
AT ONBATT riello1000@localhost CANCEL-TIMER upsgone

With this configuration UPSSCHED doesn't work, if I change to:

AT ONLINE * START-TIMER upsgone 60
AT ONBATT * CANCEL-TIMER upsgone

working perfectly.

Why I can't use specific UPS for this task?

[jimklimov]

Hi, looked through code and it boiled down to upssched.c::parse_at() expecting exactly the upsname from local configuration.

• https://github.com/networkupstools/nut/blob/master/clients/upssched.c#L1173

Try dropping the @localhost in AT lines. It is a bit inconsistent with upsmon sort of requiring a hostname (since it does talk TCP) and guessing a @localhost if there is no hostname part like upsc does; actually the upscli_splitname() library method does that. On the other hand, upssched supposedly only manages operations on local UPSes, so this makes sense.

[jimklimov]

Are you in position to build NUT locally and test if PR #1861 fixes the original issue (allows to use e.g. AT riello1000@localhost ...)? Would be nice to know it works and does not crash before merging it ;) Thanks.

[shgubar]

Hi, looked through code and it boiled down to upssched.c::parse_at() expecting exactly the upsname from local configuration.

• https://github.com/networkupstools/nut/blob/master/clients/upssched.c#L1173

Try dropping the @localhost in AT lines. It is a bit inconsistent with upsmon sort of requiring a hostname (since it does talk TCP) and guessing a @localhost if there is no hostname part like upsc does; actually the upscli_splitname() library method does that. On the other hand, upssched supposedly only manages operations on local UPSes, so this makes sense.

I tried as you said:
AT ONLINE riello1000 START-TIMER upsgone 60
but the command was not executed. It didn't help.

Are you in position to build NUT locally .....

What do you mean download branch again and install?
Because I already have NUT installed locally, where the UPSs is connected.

[jimklimov]

Hm, I must have read not all of the code initially to trace the logic correctly, too much on the run between dayjob tasks :(

So the upsname which parse_at() checks against is whatever string upsmon exports as UPSNAME envvar, and that probably should match the setting of upsmon.conf MONITOR line including hostname if used.

So that PR is probably not needed after all, or at worst - should be changed to try adding @localhost if a host part is missing in requested envvar or matched AT command, but that would probably muddy waters even more.

Did you try bumping debug level of upsmon -DDDDDD to see if maybe it reveals what value it passes to upssched?

OT: Git has "brAnches". People have "brUnches", if they mix breakfast and lunch.

[jimklimov]

Also, since you have a locally built NUT, you can add an upsdebugx(1, ...) message in parse_at to report the strings it compares for upsname and un...

[shgubar]

Also, I would like to add one more problem related to the fact that the command is not executed - a new status is set:
ups.status: FSD OL BYPASS CHRG

This causes all clients to simply shut down with error - power fail

Syslog:

Feb 28 17:40:30 raspserv nut-monitor[20087]: UPS riello1000@localhost: forced shutdown in progress
Feb 28 17:40:30 raspserv nut-server[20086]: Client monitor@127.0.0.1 set FSD on UPS [riello1000]
Feb 28 17:40:30 raspserv upsd[20086]: Client monitor@127.0.0.1 set FSD on UPS [riello1000]
Feb 28 17:40:30 raspserv nut-monitor[20087]: wall: cannot get tty name: Inappropriate ioctl for device
Feb 28 17:40:30 raspserv nut-monitor[20087]: Network UPS Tools upsmon 2.8.0.1
Feb 28 17:40:46 raspserv nut-monitor[20087]: Host sync timer expired, forcing shutdown
Feb 28 17:40:46 raspserv nut-monitor[20087]: Executing automatic power-fail shutdown
Feb 28 17:40:46 raspserv nut-monitor[20087]: wall: cannot get tty name: Inappropriate ioctl for device
Feb 28 17:40:46 raspserv nut-monitor[20087]: Auto logout and shutdown proceeding
Feb 28 17:40:46 raspserv nut-monitor[20087]: wall: cannot get tty name: Inappropriate ioctl for device
Feb 28 17:40:46 raspserv nut-monitor[20087]: Network UPS Tools upsmon 2.8.0.1
Feb 28 17:40:51 raspserv nut-monitor[20087]: Failed to create power down flag!
Feb 28 17:40:51 raspserv nut-monitor[20087]: Network UPS Tools upsmon 2.8.0.1
Feb 28 17:40:51 raspserv nut-monitor[20087]: Failed to set wall message, ignoring: Interactive authentication required.
Feb 28 17:40:51 raspserv nut-monitor[20087]: Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Interactive authentication required.
Feb 28 17:40:51 raspserv nut-monitor[20087]: Failed to set wall message, ignoring: Interactive authentication required.
Feb 28 17:40:51 raspserv nut-monitor[20087]: Failed to power off system via logind: Interactive authentication required.
Feb 28 17:40:51 raspserv nut-monitor[20087]: Failed to open initctl fifo: Access denied
Feb 28 17:40:51 raspserv nut-monitor[20087]: Failed to talk to init daemon.
Feb 28 17:40:51 raspserv nut-monitor[20087]: parent: Unable to call shutdown command: /sbin/shutdown -h +0
Feb 28 17:40:51 raspserv nut-monitor[20087]: Network UPS Tools upsmon 2.8.0.1

[shgubar]

OT: Git has "brAnches". People have "brUnches", if they mix breakfast and lunch.

Thanks for pointing out my mistake, it's just a typo.

[shgubar]

Also, since you have a locally built NUT, you can add an upsdebugx(1, ...) message in parse_at to report the strings it compares for upsname and un...

This is a very good idea, but I did not understand exactly where to add upsdebugx(1, ...) and how to write this command correctly?

[jimklimov]

Regarding the status, is it set after a real power outage? Was it long enough to deplete the battery and begin shutdown rituals (raise the FSD flag)?

If yes, that flag can not be removed from the running NUT data server (at best, you can restart upsd for the effect) since it is assumed that some monitoring clients began shutting down and the whole rack (generally) or the current server (usually) must complete its reboot even if wall-power returned.

Some UPSes (typically enterprise networked ones) also have a concept of alarming their clients that it is not safe to be powered on (even if charging, the UPS does not have batteries full enough to let clients shut down in emergency), and that status can be relayed as NUT FSD as well. So you press the buttons to force a boot-up after an outage (rather than wait for UPS to charge and power on the load), then NUT starts, finds the alarm on expensive UPS, raises FSD and your system shuts down ASAP.