Introduce optional sd_notify() support for READY, RELOADING and STOPPING states, and a WATCHDOG (if enabled)
#1777
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
Nice, status messages work - as well as MAINPID setting for systemd to monitor the intended upsd/upsmon/driver process after all the forking involved in starting one: A call to |
…onally integrate with sd_notify() [networkupstools#1590]
…rvice.in: provide an Alias for convenience (upsd, upsmon)
…r upsd, upsmon and drivers [networkupstools#1590]
… if "WATCHDOG_PID" mismatches [networkupstools#1590]
…rvice.in: use Restart=on-failure so that clean intentional exit (e.g. by signal handling) does not revive it [networkupstools#1781]
…if available after reporting MAINPID to systemd [networkupstools#1590]
…t-posting the pings if expected PID is not ours [networkupstools#1590]
…psnotify_reported_watchdog_systemd hush-flag when troubleshooting [networkupstools#1590]
…itor.service.in: provide an Alias for convenience (upsd, upsmon)
Member
Author
|
Fixed watchdog integration per comments from @poettering and rebased over recent master branch. Hopefully this burst of activity is done :) |
This was referenced Jan 8, 2023
jimklimov
added a commit
to jimklimov/nut
that referenced
this pull request
Aug 4, 2023
… of got_monoclock in upsnotify() [networkupstools#1777 follow-up] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
jimklimov
added a commit
to jimklimov/nut
that referenced
this pull request
Aug 4, 2023
…etworkupstools#1777 follow-up] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
jimklimov
added a commit
to jimklimov/nut
that referenced
this pull request
Aug 4, 2023
…rkupstools#2007, networkupstools#1777] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes: #1590
While the systemd notifications are first/primary cause of this change, I tried to implement it in a somewhat abstract manner to allow easy extension to other service management frameworks. No strong opinion yet if this should supplant existing (currently nearby)
upslogx()orupsdebugx()messages about the lifecycle milestones.While the watchdog notification support was added, it is currently not configured by the service unit templates (something to do more exploration about to provide decent timeouts, even for busy systems). One idea for the future was to use
WATCHDOG_USEC=<NUM>(andEXTEND_TIMEOUT_USEC=<NUM>) messages for drivers (daemons) to actually tell systemd that they want to be watchdogged, e.g. based on optionalmaxstartdelaysetting parsed fromups.conf. For example, full SNMP walks can take a while, tens of seconds or more, and wall-clock times depend on stress and performance of both the monitoring system and UPS interface hardware.Other NUT units, such as NDE script's service (and related path), are not covered by this change at this time.
Loosely related to #1771 (might conflict a bit). Not sure if this general daemon lifecycle notification support should also get peppered into drivers as thoroughly (e.g. track reconnection attempts as a "reloading" state).
CC @bigon