shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-01 00:51:24 +03:00
Code
0718266017
systemd/man/systemd-rfkill.service.xml

66 lines
2.1 KiB
XML
Raw Normal View History

rfkill: add new rfkill tool to save/restore rfkill state across reboots This works analogous to the existing backlight and random seed services
2013-10-14 06:31:49 +04:00
<?xml version="1.0"?>
<!--*-nxml-*-->
man: use same header for all files The "include" files had type "book" for some raeason. I don't think this is meaningful. Let's just use the same everywhere. $ perl -i -0pe 's^..DOCTYPE (book|refentry) PUBLIC "-//OASIS//DTD DocBook XML V4.[25]//EN"\s+"http^<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"\n "http^gms' man/*.xml
2019-03-14 16:40:58 +03:00
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 07:23:58 +03:00
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
rfkill: rework and make it listen on /dev/rfkill With this rework we introduce systemd-rfkill.service as singleton that is activated via systemd-rfkill.socket that listens on /dev/rfkill. That way, we get notified each time a new rfkill device shows up or changes state, in which case we restore and save its current setting to disk. This is nicer than the previous logic, as this means we save/restore state even of rfkill devices that are around only intermittently, and save/restore the state even if the system is shutdown abruptly instead of cleanly. This implements what I suggested in #1019 and obsoletes it.
2015-10-01 15:32:48 +03:00
<refentry id="systemd-rfkill.service" conditional='ENABLE_RFKILL'>
rfkill: add new rfkill tool to save/restore rfkill state across reboots This works analogous to the existing backlight and random seed services
2013-10-14 06:31:49 +04:00
Reindent man pages to 2ch
2015-02-04 05:14:13 +03:00
<refentryinfo>
rfkill: rework and make it listen on /dev/rfkill With this rework we introduce systemd-rfkill.service as singleton that is activated via systemd-rfkill.socket that listens on /dev/rfkill. That way, we get notified each time a new rfkill device shows up or changes state, in which case we restore and save its current setting to disk. This is nicer than the previous logic, as this means we save/restore state even of rfkill devices that are around only intermittently, and save/restore the state even if the system is shutdown abruptly instead of cleanly. This implements what I suggested in #1019 and obsoletes it.
2015-10-01 15:32:48 +03:00
<title>systemd-rfkill.service</title>
Reindent man pages to 2ch
2015-02-04 05:14:13 +03:00
<productname>systemd</productname>
</refentryinfo>
<refmeta>
rfkill: rework and make it listen on /dev/rfkill With this rework we introduce systemd-rfkill.service as singleton that is activated via systemd-rfkill.socket that listens on /dev/rfkill. That way, we get notified each time a new rfkill device shows up or changes state, in which case we restore and save its current setting to disk. This is nicer than the previous logic, as this means we save/restore state even of rfkill devices that are around only intermittently, and save/restore the state even if the system is shutdown abruptly instead of cleanly. This implements what I suggested in #1019 and obsoletes it.
2015-10-01 15:32:48 +03:00
<refentrytitle>systemd-rfkill.service</refentrytitle>
Reindent man pages to 2ch
2015-02-04 05:14:13 +03:00
<manvolnum>8</manvolnum>
</refmeta>
<refnamediv>
rfkill: rework and make it listen on /dev/rfkill With this rework we introduce systemd-rfkill.service as singleton that is activated via systemd-rfkill.socket that listens on /dev/rfkill. That way, we get notified each time a new rfkill device shows up or changes state, in which case we restore and save its current setting to disk. This is nicer than the previous logic, as this means we save/restore state even of rfkill devices that are around only intermittently, and save/restore the state even if the system is shutdown abruptly instead of cleanly. This implements what I suggested in #1019 and obsoletes it.
2015-10-01 15:32:48 +03:00
<refname>systemd-rfkill.service</refname>
<refname>systemd-rfkill.socket</refname>
Reindent man pages to 2ch
2015-02-04 05:14:13 +03:00
<refname>systemd-rfkill</refname>
rfkill: rework and make it listen on /dev/rfkill With this rework we introduce systemd-rfkill.service as singleton that is activated via systemd-rfkill.socket that listens on /dev/rfkill. That way, we get notified each time a new rfkill device shows up or changes state, in which case we restore and save its current setting to disk. This is nicer than the previous logic, as this means we save/restore state even of rfkill devices that are around only intermittently, and save/restore the state even if the system is shutdown abruptly instead of cleanly. This implements what I suggested in #1019 and obsoletes it.
2015-10-01 15:32:48 +03:00
<refpurpose>Load and save the RF kill switch state at boot and change</refpurpose>
Reindent man pages to 2ch
2015-02-04 05:14:13 +03:00
</refnamediv>
<refsynopsisdiv>
rfkill: rework and make it listen on /dev/rfkill With this rework we introduce systemd-rfkill.service as singleton that is activated via systemd-rfkill.socket that listens on /dev/rfkill. That way, we get notified each time a new rfkill device shows up or changes state, in which case we restore and save its current setting to disk. This is nicer than the previous logic, as this means we save/restore state even of rfkill devices that are around only intermittently, and save/restore the state even if the system is shutdown abruptly instead of cleanly. This implements what I suggested in #1019 and obsoletes it.
2015-10-01 15:32:48 +03:00
<para><filename>systemd-rfkill.service</filename></para>
<para><filename>systemd-rfkill.socket</filename></para>
man: revert dynamic paths for split-usr setups This did not really work out as we had hoped. Trying to do this upstream introduced several problems that probably makes it better suited as a downstream patch after all. At any rate, it is not releaseable in the current state, so we at least need to revert this before the release. * by adjusting the path to binaries, but not do the same thing to the search path we end up with inconsistent man-pages. Adjusting the search path too would be quite messy, and it is not at all obvious that this is worth the effort, but at any rate it would have to be done before we could ship this. * this means that distributed man-pages does not make sense as they depend on config options, and for better or worse we are still distributing man pages, so that is something that definitely needs sorting out before we could ship with this patch. * we have long held that split-usr is only minimally supported in order to boot, and something we hope will eventually go away. So before we start adding even more magic/effort in order to make this work nicely, we should probably question if it makes sense at all.
2015-06-18 20:47:44 +03:00
<para><filename>/usr/lib/systemd/systemd-rfkill</filename></para>
Reindent man pages to 2ch
2015-02-04 05:14:13 +03:00
</refsynopsisdiv>
<refsect1>
<title>Description</title>
rfkill: rework and make it listen on /dev/rfkill With this rework we introduce systemd-rfkill.service as singleton that is activated via systemd-rfkill.socket that listens on /dev/rfkill. That way, we get notified each time a new rfkill device shows up or changes state, in which case we restore and save its current setting to disk. This is nicer than the previous logic, as this means we save/restore state even of rfkill devices that are around only intermittently, and save/restore the state even if the system is shutdown abruptly instead of cleanly. This implements what I suggested in #1019 and obsoletes it.
2015-10-01 15:32:48 +03:00
<para><filename>systemd-rfkill.service</filename> is a service
Reindent man pages to 2ch
2015-02-04 05:14:13 +03:00
that restores the RF kill switch state at early boot and saves it
rfkill: rework and make it listen on /dev/rfkill With this rework we introduce systemd-rfkill.service as singleton that is activated via systemd-rfkill.socket that listens on /dev/rfkill. That way, we get notified each time a new rfkill device shows up or changes state, in which case we restore and save its current setting to disk. This is nicer than the previous logic, as this means we save/restore state even of rfkill devices that are around only intermittently, and save/restore the state even if the system is shutdown abruptly instead of cleanly. This implements what I suggested in #1019 and obsoletes it.
2015-10-01 15:32:48 +03:00
on each change. On disk, the RF kill switch state is stored in
Reindent man pages to 2ch
2015-02-04 05:14:13 +03:00
<filename>/var/lib/systemd/rfkill/</filename>.</para>
</refsect1>
<refsect1>
<title>Kernel Command Line</title>
<para><filename>systemd-rfkill</filename> understands the
following kernel command line parameter:</para>
<variablelist class='kernel-commandline-options'>
<varlistentry>
<term><varname>systemd.restore_state=</varname></term>
<listitem><para>Takes a boolean argument. Defaults to
<literal>1</literal>. If <literal>0</literal>, does not
restore the rfkill settings on boot. However, settings will
still be stored on shutdown. </para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
</para>
</refsect1>
rfkill: add new rfkill tool to save/restore rfkill state across reboots This works analogous to the existing backlight and random seed services
2013-10-14 06:31:49 +04:00
</refentry>
Copy Permalink