int sd_event_set_watchdog(sd_event *event, int b);
int sd_event_get_watchdog(sd_event *event);sd_watchdog_enabled(3), and watchdog messages are sent with sd_notify(3). See the WatchdogSec= setting in systemd.service(5) for details on how to enable watchdog support for a service and the protocol used. 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 will disable the automatic sending of watchdog notification messages if it was enabled before. Newly allocated event loop objects have this feature disabled. The first watchdog notification message is sent immediately when set_event_set_watchdog() is invoked with a true b parameter. 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. 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. sd_event_get_watchdog() may be used to determine whether watchdog support was previously requested by a call to sd_event_set_watchdog() with a true b parameter and successfully enabled.
The event loop has been created in a different process.-EINVAL
The passed event loop object was invalid.pkg-config(1) file. 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_defer(3), sd_event_add_post(3), sd_event_add_exit(3), sd_watchdog_enabled(3), sd_notify(3), systemd.service(5)