SD_EVENT_SET_WATCHDOG(3)

💖 SD_EVENT_SET_WATCHDOG(3) 💖

okay bestie, welcome to the sd_event_set_watchdog manual page — yes, manual name folded right in near the top, no copied header line energy here 💅. this page is all about letting your event loop do watchdog notifications, and it's highkey important. let's go 🫶

---

✨ NAME ✨

sd_event_set_watchdog, sd_event_get_watchdog — enable event loop watchdog support 💅

🎀 SYNOPSIS 🎀

#include <systemd/sd-event.h>

int sd_event_set_watchdog(sd_event *event, int b);

int sd_event_get_watchdog(sd_event *event);

🌸 DESCRIPTION 🌸

okay so sd_event_set_watchdog() is your function for turning automatic watchdog notification support on or off in the event loop object you pass as event. specifically, depending on the boolean b argument, it makes sure the event loop wakes up in regular intervals and sends watchdog notification messages to the service manager — but only if the service manager requested that. watchdog support is determined with sd_watchdog_enabled(3), and watchdog messages are sent with sd_notify(3). for the whole "how do I enable watchdog support for a service and what protocol is used" situation, see the WatchdogSec= setting in systemd.service(5) ✨.

The wake-up interval is chosen as half the watchdog timeout declared by the service manager via the $WATCHDOG_USEC environment variable. If the service manager did not request watchdog notifications, or if the process was not invoked by the service manager, this call with a true b parameter executes no operation. Passing a false b parameter disables the automatic sending of watchdog notification messages if it was enabled before. Newly allocated event loop objects have this feature disabled. fr fr.

The first watchdog notification message is sent immediately when sd_event_set_watchdog() is invoked with a true b parameter. periodt.

The watchdog logic is designed to allow the service manager to automatically detect services that ceased processing of incoming events, and thus appear "hung". Watchdog notifications are sent out only at the beginning of each event loop iteration — the way that this works is a whole thing. If an event source dispatch function blocks for an excessively long time and does not return execution to the event loop quickly, this might hence cause the notification message to be delayed, and possibly result in abnormal program termination, as configured in the service unit file. that's the dramatic part, bestie 😭.

sd_event_get_watchdog() is how you determine whether watchdog support was previously requested by a call to sd_event_set_watchdog() with a true b parameter and successfully enabled 👑.

💜 RETURN VALUE 💜

On success, sd_event_set_watchdog() and sd_event_get_watchdog() return a non-zero positive integer if the service manager requested watchdog support and watchdog support was successfully enabled. They return zero if the service manager did not request watchdog support, or if watchdog support was explicitly disabled with a false b parameter. On failure, they return a negative errno-style error code. no cap, that's the return-value vibe.

Errors 💀

the returned errors can mean these things:

• -ECHILD — the event loop has been created in a different process, library or module instance.
• -EINVAL — the passed event loop object was invalid.

🦋 NOTES 🦋

the functions described here are available as a shared library, which can be compiled against and linked to with the libsystemd pkg-config(1) file.

All functions listed here are thread-agnostic, and only a single thread may operate on a given object at any given time. Different threads may access the same object at different times. Multiple independent objects may be used from different threads in parallel. slay for concurrency rules 💅.

The code described here uses getenv(3), which is declared to be not multi-thread-safe. This means that the code calling the functions described here must not call setenv(3) from a parallel thread. It is recommended to only do calls to setenv() from an early phase of the program when no other threads have been started. lowkey important 🫶.

🎀 HISTORY 🎀

sd_event_set_watchdog() and sd_event_get_watchdog() were added in version 229. iconic behavior from way back.

🌈 SEE ALSO 🌈

systemd(1), sd-event(3), sd_event_new(3), sd_event_add_io(3), sd_event_add_time(3), sd_event_add_signal(3), sd_event_add_child(3), sd_event_add_inotify(3), sd_event_add_defer(3), sd_watchdog_enabled(3), sd_notify(3), systemd.service(5)

---

okay that's the whole page, bestie. the footer sign-off here is systemd 261.3 and the manual name SD_EVENT_SET_WATCHDOG(3) — there's no date line in the original footer, so that's the cute little bye-bye. stay watchful 💖✨