Bump NUT master branch from FTY: systemd integration

scripts/systemd/nut-driver-enumerator-daemon-activator.path.in

@@ -1,5 +1,5 @@
 # Network UPS Tools (NUT) systemd integration
-# Copyright (C) 2011-2023 by NUT contirbutors
+# Copyright (C) 2011-2024 by NUT contirbutors
 # Distributed under the terms of GPLv2+
 # See https://networkupstools.org/
 # and https://github.com/networkupstools/nut/
@@ -8,7 +8,7 @@
 # Trigger restart of nut-driver-enumerator-daemon-activator.service
 # whenever ups.conf is edited, which would cause reload-or-restart
 # of the nut-driver-enumerator-daemon.service for actual reconfig.
-Description=Network UPS Tools - Trigger restart of nut-driver-enumerator-daemon.service whenever ups.conf is edited
+Description=Network UPS Tools - Trigger reload-or-restart of nut-driver-enumerator-daemon.service whenever ups.conf is edited
 Conflicts=nut-driver-enumerator.service nut-driver-enumerator.path
 After=local-fs.target
 Before=nut-driver.target

scripts/systemd/nut-driver-enumerator-daemon-activator.service.in

@@ -26,6 +26,17 @@ Type=oneshot
 # Non-blocking systemd message posting should not take long,
 # or should be aborted and retried if it does (system bugs)
 TimeoutStartSec=10s
+# If some process is writing the ups.conf file, it can be interpreted in
+# some conditions by .path unit as many events requiring it to start -
+# and eventually this gets throttled as a quickly started-restarted unit.
+# While it should be permitted for manual start (likely .path trigger too)
+# after interval expiration, this might race-condition to not detect some
+# latest update into the configuration file if it happens after the main
+# script loop has slurped intermediate state of device config.
+# Note: Using the older but still supported Service/StartLimitInterval
+# see https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html
+# for broader compatibility.
+StartLimitInterval=0
 ExecStart=/bin/systemctl reload-or-restart --no-block nut-driver-enumerator-daemon.service
 
 [Install]

scripts/systemd/nut-server.service.in

@@ -26,6 +26,21 @@ Before=nut-monitor.service
 PartOf=nut.target
 
 [Service]
+# A busy server can be monitoring a lot of devices as well as replying
+# to many clients. The "infinity" definition is actually capped by OS
+# settings and hardcoded defaults; typically can be 65535+ nowadays.
+# On 64-bit distros this can well be set into hundreds of thousands
+# as well (though note each connnection has a CPU and RAM overhead
+# so one can strike physical limits upon deployment and/or bring the
+# poorly sized system to a crawl, or worse). On a running system you
+# can check /proc/$MAINPID/limits for active ulimits of the process.
+# From my experiments, up to 1048576 can be set, but any larger value
+# falls back to 65536. The systemd definition of "infinity" is 65536
+# too (or maybe it falls back to that); though this may be OS/distro
+# limitation and not systemd fault specifically.
+#LimitNOFILE=infinity
+#LimitNOFILE=65535
+LimitNOFILE=1048576
 EnvironmentFile=-@CONFPATH@/nut.conf
 SyslogIdentifier=%N
 # Note: foreground mode "-F" by default skips writing a PID file (and
@@ -34,6 +49,7 @@ SyslogIdentifier=%N
 ExecStartPre=-@SYSTEMD_TMPFILES_PROGRAM@ --create @systemdtmpfilesdir@/nut-common-tmpfiles.conf
 ExecStart=@SBINDIR@/upsd @SYSTEMD_DAEMON_ARGS_UPSD@
 ExecReload=@SBINDIR@/upsd -c reload -P $MAINPID
+ExecStartPost=-/bin/grep -E 'Units|Max open files' /proc/${MAINPID}/limits
 # No tracking for PIDFile path and service attribute here (it might not
 # even exist).
 # If "-FF" or background-daemon mode is used, so that PID file exists