SHUTDOWNEXIT flag for upsmon doesn't work on Windows

[dvdesolve]

I'm struggling with configuring secondary systems based on Windows. I've successfully installed NUT-Windows from release page (2.8.4) as Windows Service. NUT service is configured to be netclient. upsmon is able to read config file successfully but shutdown design doesn't work as expected

I have RPi (CentOS Stream 9, NUT 2.8.3) as primary UPS controller and a bunch of secondary systems (Windows 7, 10 etc; NUT 2.8.4). Secondary systems drive heavy equipment which should be parked properly before shutdown. My plan is to use NUT as netclient just to catch FSD event on primary UPS and then execute equipment-specific script with consequent shutdown. For the test purposes I've created simple bash script which just emulates long shutdown process:

#!/usr/bin/bash

# as for now I'm using Cygwin for quick tests
DT=`date`
echo "SHUTDOWN at ${DT}" >> /cygdrive/c/nut/history.log
sleep 900 # we're emulating long process here; on real system here will be equipment-specific incantation
/cygdrive/c/Windows/System32/shutdown.exe /s /t 5

exit 0

On primary system I've set HOSTSYNC to the number just a bit higher than required to properly shut down secondaries (1200). On the secondaries I have SHUTDOWNEXIT set to -1 (also tried false and even big numbers like 2000). According to the docs primary upsmon should wait until all secondaries disconnect (which should occur because I'm requesting Windows shutdown at the end of the process) and only then switch off itself and controlled UPS. However Windows logs tell me that secondary upsmon quits right after its FINALDELAY count of seconds which means two things: executing of SHUTDOWNCMD doesn't wait for it; SHUTDOWNEXIT flag is ignored at all. Otherwise upsmon should live until Windows is powered off even in case of non-blocking system() call in upsmon code.

I'm not sure if this is something special for Windows systems. As for me it looks like the only way to implement required shutdown design is to set FINALDELAY on primary to the big enough number which guarantees that even the longest shutdown process among secondaries will end properly. But in that case I'm forced to wait predefined number of seconds even if shutdown of secondaries will complete even earlier.

May be someone could point me in the right direction...

[jimklimov]

FWIW, SHUTDOWNEXIT configurability was added in #2133 and first published in NUT v2.8.1 release. It may be possible there are some issues with the logic there, not sure how well its non-default behavior was tested in practice since then.

Looking for ideas in doshutdown() as of v2.8.4 tag now:

nut/clients/upsmon.c

Lines 996 to 1019 in 541c2ec

	if (shutdownexitdelay == 0) {
	upsdebugx(1,
	"Exiting upsmon immediately "
	"after initiating shutdown, by default");
	} else
	if (shutdownexitdelay < 0) {
	upslogx(LOG_WARNING,
	"Configured to not exit upsmon "
	"after initiating shutdown");
	/* Technically, here we sleep until SIGTERM or poweroff */
	do {
	sleep(1);
	} while (!exit_flag);
	} else {
	upslogx(LOG_WARNING,
	"Configured to only exit upsmon %d sec "
	"after initiating shutdown", shutdownexitdelay);
	do {
	sleep(1);
	shutdownexitdelay--;
	} while (!exit_flag && shutdownexitdelay);
	}
	exit(EXIT_SUCCESS);
	}

• All three different code paths should leave a corresponding log message (probably in Windows Event Log in your case) to confirm whether the SHUTDOWNEXIT configuration was seen and used at all (immediately, never, after X seconds)
• For non-zero values of shutdownexitdelay (internal variable), the program actually loops not infinitely, but until the global exit_flag variable gets set (e.g. as part of SIGTERM or Ctrl+C signal processing from the OS).

Given your struggles, I now wonder if:

• such exit_flag actually gets raised before entering this loop (so it simply ends after one cycle), or if some signal/event/... causes it to be raised early?
• being diligently stuck in this loop probably causes the looping client to no longer talk to the "primary" upsmon (I think this part of code is single-process/single-thread, so there is no other thread that would do the talking), so the primary assumes an incommunicado secondary as dead - and proceeds with the shutdown?

[jimklimov]

Posted PR #3086 to address the hypothesis above, and to add some logging about when/why upsmon program exits.

When the Appveyor CI build passes there (sometimes it breaks due to VM timeout), you can download the 7-zip archive to test if the updated upsmon there handles the situation better.

[jimklimov]

UPDATE: Check this one - https://ci.appveyor.com/api/buildjobs/fsbymjddj6aq3hg9/artifacts/NUT-for-Windows-x86_64-SNAPSHOT-2.8.4.3513-master.7z

Please note that CI artifacts may get deleted after a few days, so fetch it soon at least.

[jimklimov]

@dvdesolve : Also, for the PoC script in top post, I suggest adding another echo "CALLING SHUTDOWN at $(date)" to make sure ~15 min do elapse between two echoes (that the requested sleep is honoured in fact).

[dvdesolve]

Interesting enough... logging about minsupplies worked fine, but no info about exit reason.

Excerpt from Windows Event Log in reverse order (on secondary system):

12.09.2025 10:39:38
Exiting

12.09.2025 10:39:38
Stopping upsmon (client only)

12.09.2025 10:39:33
upsmon - Auto logout and shutdown proceeding

12.09.2025 10:39:33
upsmon - Too few UPS(es) are healthy (0<1), initiating forced shutdown

12.09.2025 10:39:33
upsmon - UPS ups@ups01.phit: forced shutdown in progress

12.09.2025 10:37:27
upsmon - Communications with UPS ups@ups01.phit established

nut.conf from secondary system:

MODE=netclient

ALLOW_NO_DEVICE=true
export ALLOW_NO_DEVICE

NUT_DEBUG_LEVEL=5
export NUT_DEBUG_LEVEL

upsmon.conf from secondary system:

RUN_AS_USER nut
MONITOR ups@ups01.phit 1 LOGIN PASSWORD secondary
MINSUPPLIES 1
SHUTDOWNCMD "C:\\cygwin64\\bin\\bash.exe --login C:\\nut\\script.sh"
SHUTDOWNEXIT -1
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG C:\\nut\\mingw64\\etc\\killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

As you may note time difference between messages Auto logout and shutdown proceeding and Stopping upsmon (client only) is exactly FINALDELAY (also checked with other values). So for some reason it doesn't wait until my SHUTDOWNCMD finishes (which for now emulates long sleep instead of real equipment parking). Problematic line in clients/upsmon.c seems to be like that:

sret = system(shutdowncmd);

Also shutdownexitdelay seems to be zero despite of settings in upsmon.conf on secondary system.

upsmon.conf from primary system (ups01.phit):

RUN_AS_USER nut
MONITOR ups 1 LOGIN PASSWORD primary
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 1200
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 20