mirror of
https://github.com/systemd/systemd.git
synced 2024-11-01 17:51:22 +03:00
8274a30d0e
These man pages list references to the various sd_event_add_xyz() calls at the bottom, but sd_event_add_inotify() was never added there. Moreover, some list references to sd_event_add_post() and sd_event_add_exit() even though these have shared man pages with sd_event_add_defer(), and given that the "SEE ALSO" section should probably reference pages instead of functions let's drop this. Then, let's always specify the sd_event_add_xyz() calls in the same order. Finally, in the sd_event_new(3) text explaining the basic logic, actually mention sd_event_add_post() and sd_event_add_exit() as well, as in that case we actually want to list functions, not man pages.
153 lines
6.4 KiB
XML
153 lines
6.4 KiB
XML
<?xml version='1.0'?>
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
|
|
<!--
|
|
SPDX-License-Identifier: LGPL-2.1+
|
|
-->
|
|
|
|
<refentry id="sd_event_set_watchdog" xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<refentryinfo>
|
|
<title>sd_event_set_watchdog</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>sd_event_set_watchdog</refentrytitle>
|
|
<manvolnum>3</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>sd_event_set_watchdog</refname>
|
|
<refname>sd_event_get_watchdog</refname>
|
|
|
|
<refpurpose>Enable event loop watchdog support</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<funcsynopsis>
|
|
<funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo>
|
|
|
|
<funcprototype>
|
|
<funcdef>int <function>sd_event_set_watchdog</function></funcdef>
|
|
<paramdef>sd_event *<parameter>event</parameter></paramdef>
|
|
<paramdef>int b</paramdef>
|
|
</funcprototype>
|
|
|
|
<funcprototype>
|
|
<funcdef>int <function>sd_event_get_watchdog</function></funcdef>
|
|
<paramdef>sd_event *<parameter>event</parameter></paramdef>
|
|
</funcprototype>
|
|
|
|
</funcsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><function>sd_event_set_watchdog()</function> may be used to
|
|
enable or disable automatic watchdog notification support in the
|
|
event loop object specified in the <parameter>event</parameter>
|
|
parameter. Specifically, depending on the <parameter>b</parameter>
|
|
boolean argument this will make sure the event loop wakes up in
|
|
regular intervals and sends watchdog notification messages to the
|
|
service manager, if this was requested by the service
|
|
manager. Watchdog support is determined with
|
|
<citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
and watchdog messages are sent with
|
|
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. See
|
|
the <varname>WatchdogSec=</varname> setting in
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
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
|
|
<varname>$WATCHDOG_USEC</varname> 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 <parameter>b</parameter> parameter executes no
|
|
operation. Passing a false <parameter>b</parameter> parameter will
|
|
disable the automatic sending of watchdog notification messages if
|
|
it was enabled before. Newly allocated event loop objects have
|
|
this feature disabled.</para>
|
|
|
|
<para>The first watchdog notification message is sent immediately
|
|
when <function>set_event_set_watchdog()</function> is invoked with
|
|
a true <parameter>b</parameter> parameter.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para><function>sd_event_get_watchdog()</function> may be used to
|
|
determine whether watchdog support was previously requested by a
|
|
call to <function>sd_event_set_watchdog()</function> with a true
|
|
<parameter>b</parameter> parameter and successfully
|
|
enabled.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Return Value</title>
|
|
|
|
<para>On success, <function>sd_event_set_watchdog()</function> and
|
|
<function>sd_event_get_watchdog()</function> 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
|
|
<parameter>b</parameter> parameter. On failure, they return a
|
|
negative errno-style error
|
|
code.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Errors</title>
|
|
|
|
<para>Returned errors may indicate the following problems:</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><constant>-ECHILD</constant></term>
|
|
|
|
<listitem><para>The event loop has been created in a different process.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><constant>-EINVAL</constant></term>
|
|
|
|
<listitem><para>The passed event loop object was invalid.</para></listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<xi:include href="libsystemd-pkgconfig.xml" />
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|