Can't shutdown automatically, Fedora 42 KDE, SELinux enforcing, Prolink PRO1201SFCU 1200VA

[Onxr]

Host: Fedora 42 KDE
UPS: Prolink PRO1201SFCU 1200VA
SELinux enabled
Host doesn't shutdown automatically. I don't know what to do. I have followed many guides and was able to do these.

/etc/ups contents

$ ls -l /etc/ups
total 108
-rw-r-----. 1 root nut   142 Dec 19 17:57 nut.conf
-rw-r-----. 1 root nut  9105 Aug  6 19:50 nut-example.conf
-rw-r-----. 1 root nut   276 Dec 20 00:03 ups.conf
-rw-r-----. 1 root nut   242 Dec 19 18:07 upsd.conf
-rw-r-----. 1 root nut  9566 Apr 19  2025 upsd-example.conf
-rw-r-----. 1 root nut  2476 Apr 19  2025 upsd-example.users
-rw-r-----. 1 root nut    47 Dec 21 18:36 upsd.users
-rw-r-----. 1 root nut 11847 Apr 19  2025 ups-example.conf
-rw-r-----. 1 root nut  3467 Dec 21 18:37 upsmon.conf
-rw-r-----. 1 root nut 30718 Aug 14 06:00 upsmon-example.conf
-rwxr-x--x. 1 root nut   994 Dec 21 19:13 upssched-cmd
-rw-r-----. 1 root nut   783 Dec 21 20:48 upssched.conf
-rw-r-----. 1 root nut  4332 Aug 14 06:00 upssched-example.conf


$ ls -lZ /etc/ups
total 108
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0   142 Dec 19 17:57 nut.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0      9105 Aug  6 19:50 nut-example.conf
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0   276 Dec 20 00:03 ups.conf
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0   242 Dec 19 18:07 upsd.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0      9566 Apr 19  2025 upsd-example.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0      2476 Apr 19  2025 upsd-example.users
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0    47 Dec 21 18:36 upsd.users
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0     11847 Apr 19  2025 ups-example.conf
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0  3467 Dec 21 18:37 upsmon.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0     30718 Aug 14 06:00 upsmon-example.conf
-rwxr-x--x. 1 root nut unconfined_u:object_r:nut_conf_t:s0   994 Dec 21 19:13 upssched-cmd
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0   783 Dec 21 20:48 upssched.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0      4332 Aug 14 06:00 upssched-example.conf

# ups.conf
# How often will poll
pollinterval = 1
# Max retry before deemed failed
maxretry = 3

# UPS specific driver
# Get info using: sudo nut-scanner -U
[prolink]
    driver = nutdrv_qx
    port = auto
    desc = "Prolink PRO1201SFCU 1200VA"
    vendorid = 0665
    productid = 5161

# upsd.conf
# Use only one method
# REMEMBER: comment out the other one
# ----------------------------------------
# Use as standalone. Listens only localhost
LISTEN 127.0.0.1 3493

# Use as Server/Client. Listens all IP addresses
# LISTEN 0.0.0.0 3493

# upsd.users
[monuser]
  password = secret
  upsmon primary

# upsmon.conf
# You can setup additional account with restriction 
# Running as root is simpler method
RUN_AS_USER root

# Monitor UPS one line/entry for each UPS
# MONITOR devicename@host <how many ups are connected to this device> <account> <password> <type (use master if UPS is connected to this device else slave)>
MONITOR prolink@localhost 1 monuser secret primary



# Min UPS requires to be alive
MINSUPPLIES 1
# Shutdown command binary
SHUTDOWNCMD "/sbin/shutdown -h"
# Notification command binary
NOTIFYCMD /usr/sbin/upssched
POLLFREQ 2
POLLFREQALERT 1
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower



# NOTIFYMSG - change messages sent by upsmon when certain events occur
# --------------------------------------------------------------------------
# You can change the default messages to something else if you like.
# NOTIFYMSG <notify type> "message"
# Note that %s (where used) is replaced with the identifier of the UPS in question.

# Meanings of some possible values for <notify type>:
#
# ONLINE   : UPS is back online
# ONBATT   : UPS is on battery
# LOWBATT  : UPS has a low battery (if also on battery, it's "critical")
# FSD      : UPS is being shutdown by the primary (FSD = "Forced Shutdown")
# COMMOK   : Communications established with the UPS
# COMMBAD  : Communications lost to the UPS
# SHUTDOWN : The system is being shutdown
# REPLBATT : The UPS battery is bad and needs to be replaced
# NOCOMM   : A UPS is unavailable (can't be contacted for monitoring)
# NOPARENT : The process that shuts down the system has died (shutdown impossible)
# ALARM    : UPS has one or more alarms (look at "ups.alarm" for details)

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 - change behavior of upsmon when NOTIFY events occur
# --------------------------------------------------------------------------
# By default, upsmon sends walls (global messages to all logged in users)
# and writes to the syslog when things happen.
# Except for Windows where upsmon only writes to the syslog by default.
# You can change this.
#
# NOTIFYFLAG <notify type> <flag>[+<flag>][+<flag>] ...

# Possible values for the flags:
# SYSLOG - Write the message in the syslog
# WALL   - Write the message to all users on the system
# EXEC   - Execute NOTIFYCMD (see above) with the message
# IGNORE - Don't do anything
#
# If you use IGNORE, don't use any other flags on the same line.


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

# RBWARNTIME - replace battery warning time in seconds
RBWARNTIME 43200

# NOCOMMWARNTIME - no communications warning time in seconds
NOCOMMWARNTIME 600

# FINALDELAY - last sleep interval before shutting down the system
FINALDELAY 5

# upssched.conf
# You DO HAVE TO create the script
CMDSCRIPT /etc/ups/upssched-cmd

# Command pipe and lock-file
PIPEFN /etc/ups/upssched.pipe
LOCKFN /etc/ups/upssched.lock

#================================================#
# Log running on battery
AT ONBATT * EXECUTE onbatt

# Initiate / cancel shutdown timer
# AT ONBATT * START-TIMER shutdown_timer 150
AT ONBATT * START-TIMER shutdown_timer 30
AT ONLINE * CANCEL-TIMER shutdown_timer

# Critical shutdown when low battery
AT LOWBATT * EXECUTE shutdown_critical

# Start / stop timer on communicaion failure / restoration
AT COMMBAD * START-TIMER commbad_timer 45
AT COMMOK * CANCEL-TIMER commbad_timer

# Notify cant communicate with the UPS
AT NOCOMM * EXECUTE upsgone

# Executes powerdown on system shutdown
AT SHUTDOWN * EXECUTE powerdown

# upssched-cmd
#!/bin/sh
case $1 in
    onbatt)
        # Log the event
        logger -t upssched-cmd "UPS running on battery. Shutting down in 2m 30s"
        ;;
    shutdown_timer)
        # Log the event and initiate a controlled shutdown
        logger -t upssched-cmd "UPS running on battery for too long, initiating shutdown"
        /usr/sbin/upsmon -c fsd
        ;;
    shutdown_critical)
        logger -t upssched-cmd "UPS on battery critical, forced shutdown"
        /usr/sbin/upsmon -c fsd
        ;;
    commbad_timer)
        # Log persistent communication failures and initiate shutdown
        logger -t upssched-cmd "UPS communication failure persists, initiating shutdown"
        ;;
    upsgone)
        logger -t upssched-cmd "UPS has been gone too long, unable to communicate"
        ;;
    *)
        # Log unknown commands
        logger -t upssched-cmd "Unrecognized command: $1"
        ;;
esac

The followings I had to take help from LLM to get passed SELinux issue

sudo ausearch -c 'upsmon' --raw | audit2allow -M upsmon_dac
sudo semodule -i upsmon_dac.pp

sudo ausearch -c 'sh' --raw | sudo audit2allow -M nut_upssched
sudo semodule -i nut_upssched.pp

sudo ausearch -c 'sh' --raw | sudo audit2allow -M nut_upssched_no_trans
sudo semodule -i nut_upssched_no_trans.pp

Here are the *.te files content

module upsmon_dac 1.0;

require {
	type nut_upsmon_t;
	class capability dac_override;
}

#============= nut_upsmon_t ==============
allow nut_upsmon_t self:capability dac_override;

module nut_upssched 1.0;

require {
	type nut_conf_t;
	type nut_upsmon_t;
	class file execute;
}

#============= nut_upsmon_t ==============
allow nut_upsmon_t nut_conf_t:file execute;

module nut_upssched_no_trans 1.0;

require {
	type nut_upsmon_t;
	type nut_conf_t;
	class file { execute execute_no_trans };
}

#============= nut_upsmon_t ==============

#!!!! This avc is allowed in the current policy
allow nut_upsmon_t nut_conf_t:file execute;
allow nut_upsmon_t nut_conf_t:file execute_no_trans;

$ sudo journalctl -t upssched-cmd
[sudo] password for user:
Dec 21 19:14:25 fedora upssched-cmd[21641]: UPS scheduler script testing.
-- Boot f751874da77d48879b3040f0fe7c725e --
Dec 21 19:54:22 fedora upssched-cmd[3934]: UPS running on battery. Shutting down in 2m 30s
-- Boot 04725c6cf64b42b7befad2322ae0e86c --
Dec 21 20:50:37 fedora upssched-cmd[3752]: UPS running on battery. Shutting down in 2m 30s
Dec 21 21:18:12 fedora upssched-cmd[17399]: UPS running on battery for too long, initiating shutdown
Dec 21 21:18:14 fedora upssched-cmd[17438]: Unrecognized command: powerdown

Here I ran manually

• Dec 21 19:14:25 fedora upssched-cmd[21641] To check if I can execute the script
• Dec 21 21:18:12 fedora upssched-cmd[17399] To check shutdown_timer argument actually work.
  • It did but took over a minute.
  • At first I got a wall msg. It was there for a while (BTW I did close all the apps window).
  • Then I guess plasmashell was closed, I was getting a blackscreen and some texts (felt like tty)
  • PC shutdown but I cant remember but within less than 10sec I guess my PSU turned itself off. I cant say what triggered that
  • Others triggered automatically

nut-driver-enumerator.path

$ sudo systemctl status nut-driver-enumerator.path
● nut-driver-enumerator.path - Network UPS Tools - Trigger restart of nut-driver-enumerator.service whenever ups.conf is edited
     Loaded: loaded (/usr/lib/systemd/system/nut-driver-enumerator.path; enabled; preset: disabled)
     Active: active (waiting) since Sun 2025-12-21 21:21:05 +06; 26min ago
 Invocation: 0aef19f1af2040a0aa3273591d78065f
   Triggers: ● nut-driver-enumerator.service
       Docs: man:nut-driver-enumerator(8)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/nut-driver-enumerator.html
             man:ups.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/ups.conf.html
             man:upsdrvsvcctl(8)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/upsdrvsvcctl.html
             man:nut.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/nut.conf.html

Dec 21 21:21:05 fedora systemd[1]: Started nut-driver-enumerator.path - Network UPS Tools - Trigger restart of nut-driver-enumerator.service whenever ups.conf is edited.

nut-driver-enumerator.service

$ sudo systemctl status nut-driver-enumerator.service
○ nut-driver-enumerator.service - Network UPS Tools - enumeration of configure-file devices into systemd unit instances
     Loaded: loaded (/usr/lib/systemd/system/nut-driver-enumerator.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead) since Sun 2025-12-21 21:21:05 +06; 27min ago
 Invocation: 627882e0ad3f4584b37aa66981203ace
TriggeredBy: ● nut-driver-enumerator.path
       Docs: man:nut-driver-enumerator(8)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/nut-driver-enumerator.html
             man:ups.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/ups.conf.html
             man:upsdrvsvcctl(8)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/upsdrvsvcctl.html
             man:nut.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/nut.conf.html
    Process: 989 ExecStartPre=/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf (code=exited, status=0/SUCCESS)
    Process: 1021 ExecStart=/usr/libexec/nut-driver-enumerator.sh (code=exited, status=0/SUCCESS)
   Main PID: 1021 (code=exited, status=0/SUCCESS)
   Mem peak: 8.2M
        CPU: 77ms

Dec 21 21:21:05 fedora systemd[1]: Starting nut-driver-enumerator.service - Network UPS Tools - enumeration of configure-file devices into systemd unit instances...
Dec 21 21:21:05 fedora nut-driver-enumerator[1021]: Sun 21 Dec 15:21:05 UTC 2025 : OK: No changes to reconcile between systemd service instances and device configurations in '/etc/ups/ups.conf'
Dec 21 21:21:05 fedora systemd[1]: nut-driver-enumerator.service: Deactivated successfully.
Dec 21 21:21:05 fedora systemd[1]: Finished nut-driver-enumerator.service - Network UPS Tools - enumeration of configure-file devices into systemd unit instances.

nut-server.service

$ sudo systemctl status nut-server.service
● nut-server.service - Network UPS Tools - power devices information server
     Loaded: loaded (/usr/lib/systemd/system/nut-server.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2025-12-21 21:21:07 +06; 28min ago
 Invocation: 0ba16f01365a442aa57f4c374dcd2b24
       Docs: man:upsd(8)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/upsd.html
             man:ups.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/ups.conf.html
             man:upsd.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/upsd.conf.html
             man:upsd.users(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/upsd.users.html
             man:nut.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/nut.conf.html
    Process: 1369 ExecStartPre=/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf (code=exited, status=0/SUCCESS)
    Process: 1372 ExecStartPost=/bin/grep -E Units|Max open files /proc/${MAINPID}/limits (code=exited, status=0/SUCCESS)
   Main PID: 1371 (upsd)
      Tasks: 1 (limit: 18881)
     Memory: 1M (peak: 3.7M)
        CPU: 162ms
     CGroup: /system.slice/nut-server.service
             └─1371 /usr/bin/upsd -F

Dec 21 21:21:07 fedora nut-server[1371]: Running as foreground process, not saving a PID file
Dec 21 21:21:07 fedora nut-server[1371]: upsnotify: notify about state NOTIFY_STATE_READY_WITH_PID with libsystemd: was requested, but not running as a service unit now, will not spam more about it
Dec 21 21:21:07 fedora nut-server[1371]: upsnotify: failed to notify about state NOTIFY_STATE_READY_WITH_PID: no notification tech defined, will not spam more about it
Dec 21 21:21:07 fedora nut-server[1371]: upsnotify: logged the systemd watchdog situation once, will not spam more about it
Dec 21 21:21:07 fedora upsd[1371]: Running as foreground process, not saving a PID file
Dec 21 21:21:07 fedora upsd[1371]: upsnotify: notify about state NOTIFY_STATE_READY_WITH_PID with libsystemd: was requested, but not running as a service unit now, will not spam more about it
Dec 21 21:21:07 fedora upsd[1371]: upsnotify: failed to notify about state NOTIFY_STATE_READY_WITH_PID: no notification tech defined, will not spam more about it
Dec 21 21:21:07 fedora upsd[1371]: upsnotify: logged the systemd watchdog situation once, will not spam more about it
Dec 21 21:21:07 fedora nut-server[1371]: User monuser@127.0.0.1 logged into UPS [prolink]
Dec 21 21:21:07 fedora upsd[1371]: User monuser@127.0.0.1 logged into UPS [prolink]

nut-monitor.service

$ sudo systemctl status nut-monitor.service
● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
     Loaded: loaded (/usr/lib/systemd/system/nut-monitor.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2025-12-21 21:21:07 +06; 29min ago
 Invocation: e9d42d9eebc14f3ca5ae0dcca740850d
       Docs: man:upsmon(8)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/upsmon.html
             man:upsmon.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/upsmon.conf.html
             man:nut.conf(5)
             https://www.networkupstools.org/historic/v2.8.4/docs/man/nut.conf.html
    Process: 1374 ExecStartPre=/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf (code=exited, status=0/SUCCESS)
   Main PID: 1376 (upsmon)
      Tasks: 2 (limit: 18881)
     Memory: 1.7M (peak: 3.7M)
        CPU: 212ms
     CGroup: /system.slice/nut-monitor.service
             ├─1376 /usr/bin/upsmon -F
             └─1377 /usr/bin/upsmon -F

Dec 21 21:21:07 fedora nut-monitor[1376]: Network UPS Tools upsmon 2.8.4 release
Dec 21 21:21:07 fedora nut-monitor[1376]: UPS: prolink@localhost (primary) (power value 1)
Dec 21 21:21:07 fedora nut-monitor[1376]: Using power down flag file /etc/killpower
Dec 21 21:21:07 fedora nut-monitor[1377]: upsnotify: notify about state NOTIFY_STATE_READY_WITH_PID with libsystemd: was requested, but not running as a service unit now, will not spam more about it
Dec 21 21:21:07 fedora nut-monitor[1377]: upsnotify: failed to notify about state NOTIFY_STATE_READY_WITH_PID: no notification tech defined, will not spam more about it
Dec 21 21:21:07 fedora nut-monitor[1377]: upsmon: initialized OS integration for sleep inhibitor
Dec 21 21:21:07 fedora nut-monitor[1377]: upsmon: initialized OS integration for sleep/wake monitoring
Dec 21 21:21:07 fedora nut-monitor[1377]: upsnotify: logged the systemd watchdog situation once, will not spam more about it
Dec 21 21:21:07 fedora nut-monitor[1377]: UPS prolink@localhost: has at least one unclassified status token: [WAIT]
Dec 21 21:21:12 fedora nut-monitor[1377]: UPS prolink@localhost has no unclassified status tokens anymore

I want the PC to turn off itself after 2m30s but for now I wanna test 30s. I am not sure about UPS turning off itself, is it NUT ? or I have a faulty UPS ? From netgate source I can see there's an option about enabling/disabling beeping. Though I haven't tried that, does it mean NUT can shutdown UPS too?
Sorry I am new to these. I am trying my best to understand and fix it. Also is it possible to trigger different state for testing ?

If other information is required do tell me. I tried share everything I know here.

I followed these sources and used LLM for SELinux issue

• NUT: Fedora Server 36
• Fedora News Org
• Fedora Discussion
• Proxmox: Prolink
• IP Fire
• Gentoo Wiki
• Netgate
• Techno Tim: Network UPS Tools (NUT Server) Ultimate Guide on Pi - Written Guide

[jimklimov]

CC @opoplawski @svarshavchik - does this issue ring any bells on the systemic side? I am not well-versed in SELinux beside knowing how to turn it off, so far :-}

• A PR with contributed scripts/SELinux profiles and whatever else is needed, and a README.adoc on how to make use of them, would be welcome :) => See also Explore delivery of SELinux manifests for communications between NUT programs and their environment #2831

@Onxr : There were several fixes around upssched functionality since NUT v2.8.4 release, at least those tagged and listed here: https://github.com/networkupstools/nut/issues?q=label%3A%22upssched%22%20label%3Aimpacts-release-2.8.4 - I wonder if #3097 bites you here with the timer?..

AT SHUTDOWN * EXECUTE powerdown
Dec 21 21:18:14 fedora upssched-cmd[17438]: Unrecognized command: powerdown

Indeed, not handled in your script. Exception-handling works :)

over a minute

I think some parts of that logic are handled in a loop, so execution of longer external commands can add to the timer delay. In part this allows to ensure they do not step onto each other's toes running in parallel, but primarily a simple sequential loop was easier and safer to code, I guess (not originally my code, but I've learned quite a bit about it in the past few months).

Dec 21 20:50:37 fedora upssched-cmd[3752]: UPS running on battery. Shutting down in 2m 30s
Dec 21 21:18:12 fedora upssched-cmd[17399]: UPS running on battery for too long, initiating shutdown

If the logs are all correct, and clock was not changed, and you did not restart any daemons, this was delayed for 28 minutes, so well "over a minute" and "a bit too much" for 30 or 150 second config too.

If you can build and install NUT from current master-branch sources, these daemons have a lot more logging that you can see (also in service journal) when debug is enabled. For more details on this route, see:

• https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
• https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity

Dec 21 21:18:12 fedora upssched-cmd[17399]: UPS running on battery for too long, initiating shutdown
Dec 21 21:18:14 fedora upssched-cmd[17438]: Unrecognized command: powerdown

    shutdown_critical)
       logger -t upssched-cmd "UPS on battery critical, forced shutdown"
       /usr/sbin/upsmon -c fsd
       ;;

AT COMMBAD * START-TIMER commbad_timer 45
AT SHUTDOWN * EXECUTE powerdown

This seems to confirm that upsmon -c fsd actually got called, so it tried to notify about imminent SHUTDOWN event - which is handled by running an upssched instance as the notification handler, and tried to route this into the absent powerdown implementation. While this might be used to do some very special work when shutting down due to a power event (e.g. tell your 3D printer to safely park) or just to notify the users, it is not a necessary part of the routine - eventually upsmon should call the SHUTDOWNCMD "/sbin/shutdown -h".

PC shutdown but I cant remember but within less than 10sec I guess my PSU turned itself off. I cant say what triggered that

Seems consistent with shutdown -h (per man page, -h : Equivalent to --poweroff, unless --halt is specified).

I want the PC to turn off itself after 2m30s but for now I wanna test 30s.

That's what your configs do say.

I am not sure about UPS turning off itself, is it NUT ? or I have a faulty UPS ?

This is usually done by NUT scripts running late in the system shutdown - either via careful ordering of init script numbers or systemd unit anti-dependencies, so this late code runs when cutting power is as safe as it can be, or via systemd shutdown hooks. I am not sure if Fedora packages deliver a script like this (and how much like the reference one) - see if you have it installed as /usr/lib/systemd/system-shutdown/nutshutdown or similar:
https://github.com/networkupstools/nut/blob/master/scripts/systemd/nutshutdown.in

Sorry I am new to these. I am trying my best to understand and fix it.

No problem, "the only failure is not trying" ;)

From netgate source I can see there's an option about enabling/disabling beeping. Though I haven't tried that, does it mean NUT can shutdown UPS too?
Also is it possible to trigger different state for testing ?

Current NUT offers sdcommands setting via ups.conf, which you can try setting to e.g. beeper.enable (if supported by the device) so there is a verifiable interaction with the UPS which does not cut power. Use upscmd beeper.disable or upscmd beeper.mute to turn off the noise.

[svarshavchik]

Fedora 42 packages nut 2.8.4, so manually building nut won't move the needle forward, much.

The script for dealing with SELinux AVCs on Fedora, from Fedora's nut package:

1. Extract the filename that caused the AVC (SELinux block) out of syslog. Use ls -alZ to look at its context. Does running restorecon change it? No: use ABRT to spam bugzilla with all the gory details.
2. Yes: can you figure out a sequence of events that results in restorecon needing to fix the SELinux context? Yes: spam bugzilla with all the gory details. One common cause of AVCs is using an editor which saves files by creating a temporary file and then renaming it to replace the existing file. This can end up resetting a configuration file's SELinux context when it's edited. This wouldn't be a packaging error, it's on you to fix the context.
3. No: it's on you to figure it out

I've been using my passive-aggressive mode on the users list whenever the subject of SELinux comes up. It's been in Fedora for over 20 years, pushed by Red Hat. The fact that new AVCs are still getting reported every day, and closed twice a year without any response, in Bugzilla (as their reported Fedora version is EOLed) means that there's something fundamentally wrong with SELinux. Stuff like that is ok, at first. But 20 years is more than enough to figure out how to make it work in an easy to use manner. AVCs should be a rare event, and not a daily occurence. The fact that they still are, and there's nothing that suggests that this will change anytime soon, show that SELinux's fundamental design is just simply broken.

[Onxr]

@jimklimov I am not familiar with software development and also other git sites but slightly understand github.
I guess you didn't tell me about SELinux stuffs. I was thinking about writing a post in reddit if I get all working. IDK what to do about SELinux but will mention my fixes. I think I should report according to the logs but like I said I am not familiar to these.

There were several fixes around upssched functionality since NUT v2.8.4 release, at least those tagged and listed here: https://github.com/networkupstools/nut/issues?q=label%3A%22upssched%22%20label%3Aimpacts-release-2.8.4 - I wonder if #3097 bites you here with the timer?

#1962
I am not getting it how the shutdown process is working here. Here ups.delay.shutdown & ups.delay.reboot IDK what these do. The thing is IDK how much communication happens between the UPS and the Host. Eg. can UPS directly shutdown my host when battery is low even if I just have these only and no upssched* files like this?

# upsmon.conf
# You can setup additional account with restriction 
# Running as root is simpler method
RUN_AS_USER root

# Monitor UPS one line/entry for each UPS
# MONITOR devicename@host <how many ups are connected to this device> <account> <password> <type (use master if UPS is connected to this device else slave)>
MONITOR prolink@localhost 1 monuser secret primary

Right now I know I have to define NOTIFYMSG & NOTIFYFLAG, which triggers defined states, upsshed.conf reads (that's what I read from LLM response but I guess a separate service is running?!!) and triggers upssched-cmd. If I am not wrong nut-monitor.service reads upsmon.conf ?

I have specified these in upssched.conf

• PIPEFN /etc/ups/upssched.pipe
• LOCKFN /etc/ups/upssched.lock

But I haven't seen any of these file yet. Does it get created and removed ?

Indeed, not handled in your script. Exception-handling works :)

I am not sure about the SHUTDOWN. I didn't find reference for it. I thought it uses SHUTDOWNCMD "/sbin/shutdown -h" defined in upsmon.conf. That is why didn't add anything in the script. # SHUTDOWN : The system is being shutdown wasn't clear for me.

I think some parts of that logic are handled in a loop, so execution of longer external commands can add to the timer delay. In part this allows to ensure they do not step onto each other's toes running in parallel, but primarily a simple sequential loop was easier and safer to code, I guess (not originally my code, but I've learned quite a bit about it in the past few months).

Sorry I didn't get you.

If the logs are all correct, and clock was not changed, and you did not restart any daemons, this was delayed for 28 minutes, so well "over a minute" and "a bit too much" for 30 or 150 second config too.

1. Dec 21 19:14:25 fedora upssched-cmd[21641]: UPS scheduler script testing.
-- Boot f751874da77d48879b3040f0fe7c725e --
2. Dec 21 19:54:22 fedora upssched-cmd[3934]: UPS running on battery. Shutting down in 2m 30s
-- Boot 04725c6cf64b42b7befad2322ae0e86c --
3. Dec 21 20:50:37 fedora upssched-cmd[3752]: UPS running on battery. Shutting down in 2m 30s
4. Dec 21 21:18:12 fedora upssched-cmd[17399]: UPS running on battery for too long, initiating shutdown
5. Dec 21 21:18:14 fedora upssched-cmd[17438]: Unrecognized command: powerdown

I guess I wasn't clear

1. I was testing if script actually works and I get logs (was fixing SELinux issue). I ran sudo ./upssched-cmd test (location: /etc/ups)
2. Just unplugged UPS cable. Waited nothing happened. So tried to look further
3. Again unplugged and waited but nothing happened. Tried to look again
4. Finally as upssched.conf at ONBATT executes onbatt & shutdown_timer I tried to do it manually. If I am not wrong ONBATT triggers a timer named shutdown_timer and if not cancelled executes upssched-cmd with shutdown_timer argument when the time is up. I waited but nothing happened (2 & 3). As it wasn't triggered I did manually like 1. Which means 4 was because I ran sudo ./upssched-cmd shutdown_timer. So yep it was over minute from running the command but not more than 2min if I am not wrong
5. IDK how this was triggered

If you can build and install NUT from current master-branch sources, these daemons have a lot more logging that you can see (also in service journal) when debug is enabled. For more details on this route, see:

Regarding build I don't think I can do that. I have never build from sources. As I heard dependency hell or something + IDK how to clean up or where files go.
I should mention, I didn't read any documentation of NUT. I like doc but when there's a lot info then most of the time I just look for basics and start from there. I read the example from /etc/ups. But I will read the linked articles to enable verbosity.

Also svarshavchik said

Fedora 42 packages nut 2.8.4, so manually building nut won't move the needle forward, much.

This seems to confirm that upsmon -c fsd actually got called, so it tried to notify about imminent SHUTDOWN event - which is handled by running an upssched instance as the notification handler, and tried to route this into the absent powerdown implementation. While this might be used to do some very special work when shutting down due to a power event (e.g. tell your 3D printer to safely park) or just to notify the users, it is not a necessary part of the routine - eventually upsmon should call the SHUTDOWNCMD "/sbin/shutdown -h".

I will add a msg then for powerdown

This is usually done by NUT scripts running late in the system shutdown - either via careful ordering of init script numbers or systemd unit anti-dependencies, so this late code runs when cutting power is as safe as it can be, or via systemd shutdown hooks

see if you have it installed as /usr/lib/systemd/system-shutdown/nutshutdown

I have it

$ ls -l /usr/lib/systemd/system-shutdown/nutshutdown
-rwxr-xr-x. 1 root root 4583 Aug 14 06:00 /usr/lib/systemd/system-shutdown/nutshutdown

Not good with scripting but after looking a bit I think here its defined to shutdown the UPS. Which means it is a feature. But I do have a question will it turn on the UPS when AC power is restored ?

Regarding beeper I guess I have it. BTW where can I get the command list ?

$ sudo upsc prolink | grep beeper
ups.beeper.status: enabled

• Right now I don't have any major issue other than the timer execution. How do I know the timer was triggered ? Is there a way to check the timer?
• SELinux isn't messing up (I think) but couldn't say either cause the shutdown_timer I ran manually.
• One issue I can say is that even when I manually triggered shutdown_timer it was long. Which means even if I have 150s timer and when the shutdown will be triggered it will consume one more minute
• How can I check the states ? eg. ONBATT, ONLINE, LOWBATT etc. BTW is there a way to trigger this for testing purpose ?
• Can I combine two line of AT ONBATT (I didn't find example like this but saw technotim doing this AT ONLINE * CANCEL-TIMER onbatt online but he didn't have online specified in the script) ? as I am sure if its possible and the first one gets executed AT ONBATT * EXECUTE onbatt

[Onxr]

@svarshavchik

Does running restorecon change it? No: use ABRT to spam bugzilla with all the gory details.

How does that work ? I mean is there an automated way ? or I have to create an account and spam there manually ?

One common cause of AVCs is using an editor which saves files by creating a temporary file and then renaming it to replace the existing file. This can end up resetting a configuration file's SELinux context when it's edited. This wouldn't be a packaging error, it's on you to fix the context.

I renamed/moved all the files as an example then created new files using nvim. Then ran these

sudo chmod 0640 /etc/ups/*
sudo chown root:nut /etc/ups/*
sudo restorecon -Rv /etc/ups

I wasn't able start monitor service (the first avc denial). After fixing I got another for upssched-cmd then another for upssched-cmd again. Unfortunately sealert -l <the-number> says not found, SELinux troubleshooter also removed the entries so cant add here.

From the log I was instructed to run these

# This avc denial happened when I wanted to start nut-monitor.service
sudo ausearch -c 'upsmon' --raw | audit2allow -M upsmon_dac
sudo semodule -i upsmon_dac.pp

# These iirc when I unplugged UPS
sudo ausearch -c 'sh' --raw | sudo audit2allow -M nut_upssched
sudo semodule -i nut_upssched.pp

# This one required after nut_upssched.pp
sudo ausearch -c 'sh' --raw | sudo audit2allow -M nut_upssched_no_trans
sudo semodule -i nut_upssched_no_trans.pp

I didn't know the commands will create files (*.pp,*.te). *.te was readable
Here are the *.te files content

module upsmon_dac 1.0;

require {
	type nut_upsmon_t;
	class capability dac_override;
}

#============= nut_upsmon_t ==============
allow nut_upsmon_t self:capability dac_override;

module nut_upssched 1.0;

require {
	type nut_conf_t;
	type nut_upsmon_t;
	class file execute;
}

#============= nut_upsmon_t ==============
allow nut_upsmon_t nut_conf_t:file execute;

module nut_upssched_no_trans 1.0;

require {
	type nut_upsmon_t;
	type nut_conf_t;
	class file { execute execute_no_trans };
}

#============= nut_upsmon_t ==============

#!!!! This avc is allowed in the current policy
allow nut_upsmon_t nut_conf_t:file execute;
allow nut_upsmon_t nut_conf_t:file execute_no_trans;

Running ls -lZ /etc/ups

$ ls -lZ /etc/ups
total 108
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0   142 Dec 19 17:57 nut.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0      9105 Aug  6 19:50 nut-example.conf
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0   276 Dec 20 00:03 ups.conf
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0   242 Dec 19 18:07 upsd.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0      9566 Apr 19  2025 upsd-example.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0      2476 Apr 19  2025 upsd-example.users
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0    47 Dec 21 18:36 upsd.users
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0     11847 Apr 19  2025 ups-example.conf
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0  3467 Dec 21 18:37 upsmon.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0     30718 Aug 14 06:00 upsmon-example.conf
-rwxr-x--x. 1 root nut unconfined_u:object_r:nut_conf_t:s0   994 Dec 21 19:13 upssched-cmd
-rw-r-----. 1 root nut unconfined_u:object_r:nut_conf_t:s0   783 Dec 21 20:48 upssched.conf
-rw-r-----. 1 root nut system_u:object_r:nut_conf_t:s0      4332 Aug 14 06:00 upssched-example.conf

I've been using my passive-aggressive mode on the users list whenever the subject of SELinux comes up.

Like in permissive mode.

The fact that new AVCs are still getting reported every day, and closed twice a year without any response, in Bugzilla (as their reported Fedora version is EOLed) means that there's something fundamentally wrong with SELinux.

So it's just because EOLed ? Here I thought new version already had fixed so it was closed. I found many were closed because of EoL.

[svarshavchik]

@svarshavchik

Does running restorecon change it? No: use ABRT to spam bugzilla with all the gory details.

How does that work ? I mean is there an automated way ? or I have to create an account and spam there manually ?

It's slightly obscure. I don't have the steps memorized, since it needs to be done rarely. I have to figure it out each time my API key expires. Yes you have to have an account on Fedora's Bugzilla. There's a link somewhere there that creates an API key. You do that, first.

ABRT is the applet that pops up every time there's an AVC denial, and delivers the happy news. You can view the details and delete it. There's a hidden link somewhere where you get to copy/paste your API key. If you do that, then the "Report" button should show an option to file a bug. It'll spam Bugzilla on your behalf and attach all sorts of collected data about the SELinux issue that will, hopefully, get the minions to figure out the problem.

The fact that new AVCs are still getting reported every day, and closed twice a year without any response, in Bugzilla (as their reported Fedora version is EOLed) means that there's something fundamentally wrong with SELinux.

So it's just because EOLed ? Here I thought new version already had fixed so it was closed. I found many were closed because of EoL.

Yes. I'd say most of them get closed when they get reported against a Fedora release that goes EOL. There's some advanced warning so if you feel motivated you can update the bug to the current release. I did that, a couple of times, it made no difference. It just took longer for them to get closed as EOL.

This is why I never miss a chance to rag on SELinux. This shouldn't happen. The fact that it does points to a fundamental flaw with SELinux.

[Onxr]

ABRT is the applet that pops up every time there's an AVC denial, and delivers the happy news. You can view the details and delete it. There's a hidden link somewhere where you get to copy/paste your API key. If you do that, then the "Report" button should show an option to file a bug. It'll spam Bugzilla on your behalf and attach all sorts of collected data about the SELinux issue that will, hopefully, get the minions to figure out the problem.

Found it. I can also open the SELinux troubleshooter. It will show the latest alert.
Have to click troubleshoot > Report bug > Submit report, then it will process and ask for API key.

But as you said, what's the point if nothing happens and gets closed.

[Onxr]

@jimklimov Following this as you said, I added debug_min 6 in upsd.conf and upsmon.conf
Changed scheduler for COMMBAD and NOCOMM so I can test just by pulling the USB
upssched.conf

# You DO HAVE TO create the script
CMDSCRIPT /etc/ups/upssched-cmd

# Command pipe and lock-file
PIPEFN /etc/ups/upssched.pipe
LOCKFN /etc/ups/upssched.lock

#================================================#
# Log running on battery
AT ONBATT * EXECUTE onbatt

# Initiate / cancel shutdown timer
# AT ONBATT * START-TIMER shutdown_timer 150
AT ONBATT * START-TIMER shutdown_timer 30
AT ONLINE * CANCEL-TIMER shutdown_timer

# Critical shutdown when low battery
AT LOWBATT * EXECUTE shutdown_critical

# Start / stop timer on communicaion failure / restoration
# AT COMMBAD * START-TIMER commbad_timer 45
AT COMMBAD * START-TIMER test_timer 5
AT COMMBAD * execute test_cb
AT NOCOMM * START-TIMER upsgone 5
AT COMMOK * CANCEL-TIMER commbad_timer

# Notify cant communicate with the UPS
# AT NOCOMM * EXECUTE upsgone

# Executes powerdown on system shutdown
AT SHUTDOWN * EXECUTE powerdown

upssched-cmd

#!/bin/sh
case $1 in
    onbatt)
        # Log the event
        logger -t upssched-cmd "UPS running on battery. Shutting down in 2m 30s"
        ;;
    shutdown_timer)
        # Log the event and initiate a controlled shutdown
        logger -t upssched-cmd "UPS running on battery for too long, initiating shutdown"
        /usr/sbin/upsmon -c fsd
        ;;
    shutdown_critical)
        logger -t upssched-cmd "UPS on battery critical, forced shutdown"
        /usr/sbin/upsmon -c fsd
        ;;
    commbad_timer)
        # Log persistent communication failures and initiate shutdown
        logger -t upssched-cmd "UPS communication failure persists, initiating shutdown"
        ;;
    upsgone)
        logger -t upssched-cmd "UPS has been gone too long, unable to communicate"
        ;;
    test_timer) 
        logger -t upssched-cmd "UPS scheduler script testing. Testing timer"
        ;;
    test_cb) 
        logger -t upssched-cmd "UPS scheduler script testing. Testing timer exec"
        ;;

    *)
        # Log unknown commands
        logger -t upssched-cmd "Unrecognized command: $1"
        ;;
esac

After these restarted the host and pulled out USB.

$ journalctl -flu nut-driver@prolink.service
Dec 26 15:11:10 fedora nutdrv_qx[1684]: Please check if you are not trying to both start a NUT driver program manually (directly or via upsdrvctl), and as a service at the same time. Please see 'man nut-driver-enumerator' or https://www.networkupstools.org/historic/v2.8.4/docs/man/nut-driver-enumerator.html for details
Dec 26 15:11:11 fedora nutdrv_qx[1684]: libusb1: Could not open any HID devices: insufficient permissions on everything
Dec 26 15:11:11 fedora nutdrv_qx[1684]: Please check if you are not trying to both start a NUT driver program manually (directly or via upsdrvctl), and as a service at the same time. Please see 'man nut-driver-enumerator' or https://www.networkupstools.org/historic/v2.8.4/docs/man/nut-driver-enumerator.html for details
Dec 26 15:11:12 fedora nutdrv_qx[1684]: libusb1: Could not open any HID devices: insufficient permissions on everything
Dec 26 15:11:12 fedora nutdrv_qx[1684]: Please check if you are not trying to both start a NUT driver program manually (directly or via upsdrvctl), and as a service at the same time. Please see 'man nut-driver-enumerator' or https://www.networkupstools.org/historic/v2.8.4/docs/man/nut-driver-enumerator.html for details
Dec 26 15:11:13 fedora nutdrv_qx[1684]: libusb1: Could not open any HID devices: insufficient permissions on everything
Dec 26 15:11:13 fedora nutdrv_qx[1684]: Please check if you are not trying to both start a NUT driver program manually (directly or via upsdrvctl), and as a service at the same time. Please see 'man nut-driver-enumerator' or https://www.networkupstools.org/historic/v2.8.4/docs/man/nut-driver-enumerator.html for details
Dec 26 15:11:14 fedora nutdrv_qx[1684]: libusb1: Could not open any HID devices: insufficient permissions on everything
Dec 26 15:11:14 fedora nutdrv_qx[1684]: Please check if you are not trying to both start a NUT driver program manually (directly or via upsdrvctl), and as a service at the same time. Please see 'man nut-driver-enumerator' or https://www.networkupstools.org/historic/v2.8.4/docs/man/nut-driver-enumerator.html for details
Dec 26 15:11:15 fedora nutdrv_qx[1684]: Communications with the UPS re-established

$ sudo journalctl -t upssched-cmd Returns nothing new. which means neither execute nor the timer works.
I need to know where should I look for logs and the states. BTW wall msg works when pulling out the USB.

Update:
Finally I disabled SELinux and timer did work. IDK why didn't I get any information about the issue even SELinux troubleshooter didn't throw any error.

But the issue remains
AT COMMBAD * execute test_cb never triggers
I changed the position

AT COMMBAD * execute test_cb
AT COMMBAD * START-TIMER test_timer 5

the result is same. After testing a bit, I found if there's a timer for an event such as COMMBAD then execute wont work. But the following works

AT COMMBAD * START-TIMER test_cb
AT COMMBAD * START-TIMER test_timer 35
AT COMMOK* CANCEL-TIMER test_timer 

Which means I have to start a short and long timer instead of one execute and one timed execution.

I will update if shutdown actually works.