shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-03-16 10:50:18 +03:00
Code
systemd/units/systemd-rfkill.socket

25 lines
776 B
SYSTEMD
Raw Permalink Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 13:23:58 +09:00
# SPDX-License-Identifier: LGPL-2.1-or-later
Add SPDX license headers to unit files
2017-11-18 17:35:03 +01:00
#
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 14:32:48 +02:00
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Load/Save RF Kill Switch Status /dev/rfkill Watch
Documentation=man:systemd-rfkill.socket(8)
units: condition out a few services in the initrd Let's make our units more robust to being added to an initrd: 1. systemd-boot-update only makes sense if sd-boot is available in /usr/ to copy into the ESP. This is generally not the case in initrds, and even if it was, we shouldn't update the ESP from the initrd, but from the host instead. 2. The rfkill services save/restore rfkill state, but that information is only available once /var/ is mounted, which generally happens after the initrd transition. 3. utmp management is partly in /var/, and legacy anyway, hence don't bother with it in the initrd.
2023-07-04 22:31:11 +02:00
ConditionPathExists=!/etc/initrd-release
units: do more reordering of ordering config No functional change, just a cleanup to make the subsequent changes easier to see. This is a continuation of 9810e419425263bde86787bc21251f1ad3c35628 > The block is reordered and split to have: > 1. description + documentation > 2. (optionally) conditions > 3. all the dependencies The dependencies for shutdown.target are listed separately because they are the other deps are for startup, and shutdown.target only matter much later.
2022-09-15 15:54:18 +02:00
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 14:32:48 +02:00
DefaultDependencies=no
BindsTo=sys-devices-virtual-misc-rfkill.device
units: order systemd-rfkill.socket after /var/lib/systemd/rfkill (#10904) Otherwise we might install the socket unit early, but the service backing it late, and then end up in strange loops when we enter rescue mode, because we saw an event on /dev/rfkill but really can't dispatch it nor flush it. Fixes: #9171
2018-11-24 15:59:37 +01:00
After=sys-devices-virtual-misc-rfkill.device systemd-remount-fs.service
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 14:32:48 +02:00
Conflicts=shutdown.target
Before=shutdown.target
units: do more reordering of ordering config No functional change, just a cleanup to make the subsequent changes easier to see. This is a continuation of 9810e419425263bde86787bc21251f1ad3c35628 > The block is reordered and split to have: > 1. description + documentation > 2. (optionally) conditions > 3. all the dependencies The dependencies for shutdown.target are listed separately because they are the other deps are for startup, and shutdown.target only matter much later.
2022-09-15 15:54:18 +02:00
RequiresMountsFor=/var/lib/systemd/rfkill
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 14:32:48 +02:00
[Socket]
ListenSpecial=/dev/rfkill
Writable=yes
Copy Permalink