1
0
mirror of https://github.com/systemd/systemd.git synced 2025-01-06 17:18:12 +03:00
systemd/rules.d/99-systemd.rules.in

95 lines
5.4 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: LGPL-2.1-or-later
#
# 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.
2011-05-26 04:16:17 +04:00
ACTION=="remove", GOTO="systemd_end"
getty: Start getty on 3270 terminals available on Linux on System z Add the first 3270 terminal device that is associated with the Linux preferred console to the list of virtualization consoles. This is required to automatically start a getty if the conmode=3270 kernel parameter is specified for Linux on z/VM instances. Note that a queued upstream patch also enable the 3270 terminal device if it is associated with the Linux preferred console. How To successfully start agetty on a 3270 terminal, a change in the agetty parameter order is required. Previously, agetty would started like this: /sbin/agetty --keep-baud 3270/tty1 115200,38400,9600 TERM The agetty program interprets the "3270/tty1" as baud rate and fails to start with the "bad speed: 3270/tty1" error message. Fixing this in agetty is more complex rather than reordering the command line parameters like this: /sbin/agetty --keep-baud 115200,38400,9600 3270/tty1 TERM According to agetty sources and "agetty --help", agetty accepts the "tty", "baudrate tty", and "tty baudrate" specifications. P.S. The "tty: Set correct tty name in 'active' sysfs attribute" introduces a change to display the terminal device which is associated with the Linux preferred console. This change helps to let systemd handle this particular case only. Without the changes of this commit, no additional 3270 terminal device can be managed by systemd. https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git/commit/?id=723abd87f6e536f1353c8f64f621520bc29523a3
2014-03-11 21:41:09 +04:00
SUBSYSTEM=="tty", KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd"
# Exclude 8250 serial ports with a zero IO port, as they are not usable until "setserial /dev/ttySxxx port …" is invoked.
SUBSYSTEM=="tty", KERNEL=="ttyS*", DRIVERS=="serial8250", ATTR{port}=="0x0", ATTR{iomem_base}=="0x0", ENV{SYSTEMD_READY}="0"
KERNEL=="vport*", TAG+="systemd"
SUBSYSTEM=="ptp", TAG+="systemd"
SUBSYSTEM=="mtd", TAG+="systemd"
SUBSYSTEM=="ubi", TAG+="systemd"
SUBSYSTEM=="block", TAG+="systemd"
99-systemd.rules: rework SYSTEMD_READY logic for device mapper Device mapper devices are set up in multiple steps. The first step, which generates the initial "add" event, only creates an empty container, which is useless for higher layers. SYSTEMD_READY should be set to 0 on this event to avoid premature device activation. The event that matters is the "activation" event: the first "change" event on which DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 is not set. When this event arrives, the device is ready for being scanned by blkid and similar tools, and for being activated by systemd. Intermittent events with DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 should be ignored as far as systemd or higher-level block layers are concerned. Previous device properties and symlinks should be preserved: the device shouldn't be scanned or activated, but shouldn't be deactivated, either. In particular, SYSTEM_READY shouldn't be set to 0 if it wasn't set before, because that might cause mounted file systems to be unmounted. Such intermittent events may occur any time, before or after the "activation" event. DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 can have multiple reasons. One possible reason is that the device is suspended. There are other reasons that depend on the device-mapper subsystem (LVM, multipath, dm-crypt, etc.). The current systemd rule set 1) sets SYSTEMD_READY=0 if DM_UDEV_DISABLE_OTHER_RULES_FLAG is set in "add" events; 2) imports SYSTEMD_READY from the udev db if DM_SUSPENDED is set, and jumps to systemd_end; 3) sets SYSTEMD_READY=1, otherwise. This logic has several flaws: * 1) can cause file systems to be unmounted if an coldplug event arrives while a file system is suspended. This rule shouldn't be applied for coldplug events or in general, "synthetic" add events; * 2) evaluates DM_SUSPENDED=1, which is a device-mapper internal property. It's wrong to infer that a device is accessible if DM_SUSPENDED=0. The jump to systemd_end may cause properties and/or symlinks to be lost; * 3) is superfluous, because SYSTEMD_READY=1 is equivalent with SYSTEMD_READY being unset, and can create the wrong impression that the device was explicitly activated. This patch fixes the logic as follows: - apply 1) only if DM_NAME is empty, which is only the case for the first "genuine add" event; - change 2) to use DM_UDEV_DISABLE_OTHER_RULES_FLAG instead of DM_SUSPENDED, and remove the GOTO directive; - remove 3). Fixes: b7cf1b6 ("udev: use SYSTEMD_READY to mask uninitialized DM devices") Fixes: 35a6750 ("rules: set SYSTEMD_READY=0 on DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 only with ADD event (#2747)") Signed-off-by: Martin Wilck <mwilck@suse.com>
2024-03-06 13:39:00 +03:00
# When a dm device is first created, it's just an empty container. Ignore it.
# DM_NAME is not set in this case, but it's set on spurious "add" events that occur later.
SUBSYSTEM=="block", ACTION=="add", KERNEL=="dm-*", ENV{DM_NAME}!="?*", ENV{SYSTEMD_READY}="0"
99-systemd.rules: rework SYSTEMD_READY logic for device mapper Device mapper devices are set up in multiple steps. The first step, which generates the initial "add" event, only creates an empty container, which is useless for higher layers. SYSTEMD_READY should be set to 0 on this event to avoid premature device activation. The event that matters is the "activation" event: the first "change" event on which DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 is not set. When this event arrives, the device is ready for being scanned by blkid and similar tools, and for being activated by systemd. Intermittent events with DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 should be ignored as far as systemd or higher-level block layers are concerned. Previous device properties and symlinks should be preserved: the device shouldn't be scanned or activated, but shouldn't be deactivated, either. In particular, SYSTEM_READY shouldn't be set to 0 if it wasn't set before, because that might cause mounted file systems to be unmounted. Such intermittent events may occur any time, before or after the "activation" event. DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 can have multiple reasons. One possible reason is that the device is suspended. There are other reasons that depend on the device-mapper subsystem (LVM, multipath, dm-crypt, etc.). The current systemd rule set 1) sets SYSTEMD_READY=0 if DM_UDEV_DISABLE_OTHER_RULES_FLAG is set in "add" events; 2) imports SYSTEMD_READY from the udev db if DM_SUSPENDED is set, and jumps to systemd_end; 3) sets SYSTEMD_READY=1, otherwise. This logic has several flaws: * 1) can cause file systems to be unmounted if an coldplug event arrives while a file system is suspended. This rule shouldn't be applied for coldplug events or in general, "synthetic" add events; * 2) evaluates DM_SUSPENDED=1, which is a device-mapper internal property. It's wrong to infer that a device is accessible if DM_SUSPENDED=0. The jump to systemd_end may cause properties and/or symlinks to be lost; * 3) is superfluous, because SYSTEMD_READY=1 is equivalent with SYSTEMD_READY being unset, and can create the wrong impression that the device was explicitly activated. This patch fixes the logic as follows: - apply 1) only if DM_NAME is empty, which is only the case for the first "genuine add" event; - change 2) to use DM_UDEV_DISABLE_OTHER_RULES_FLAG instead of DM_SUSPENDED, and remove the GOTO directive; - remove 3). Fixes: b7cf1b6 ("udev: use SYSTEMD_READY to mask uninitialized DM devices") Fixes: 35a6750 ("rules: set SYSTEMD_READY=0 on DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 only with ADD event (#2747)") Signed-off-by: Martin Wilck <mwilck@suse.com>
2024-03-06 13:39:00 +03:00
# DM_UDEV_DISABLE_OTHER_RULES_FLAG==1 means that the device shouldn't be probed.
# Import previous SYSTEMD_READY state.
SUBSYSTEM=="block", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}=="", IMPORT{db}="SYSTEMD_READY"
# Ignore encrypted devices with no identified superblock on it, since
# we are probably still calling mke2fs or mkswap on it.
SUBSYSTEM=="block", ENV{DM_UUID}=="CRYPT-*", ENV{ID_PART_TABLE_TYPE}=="", ENV{ID_FS_USAGE}=="", ENV{SYSTEMD_READY}="0"
# add symlink to GPT root disk
SUBSYSTEM=="block", ENV{ID_PART_GPT_AUTO_ROOT}=="1", ENV{ID_FS_TYPE}!="crypto_LUKS", SYMLINK+="gpt-auto-root"
SUBSYSTEM=="block", ENV{ID_PART_GPT_AUTO_ROOT}=="1", ENV{ID_FS_TYPE}=="crypto_LUKS", SYMLINK+="gpt-auto-root-luks"
SUBSYSTEM=="block", ENV{DM_UUID}=="CRYPT-*", ENV{DM_NAME}=="root", SYMLINK+="gpt-auto-root"
# Ignore raid devices that are not yet assembled and started
SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", KERNEL=="md*", TEST!="md/array_state", ENV{SYSTEMD_READY}="0"
SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", KERNEL=="md*", ATTR{md/array_state}=="|clear|inactive", ENV{SYSTEMD_READY}="0"
# Ignore loop devices that don't have any file attached
SUBSYSTEM=="block", KERNEL=="loop[0-9]*", ENV{DEVTYPE}=="disk", TEST!="loop/backing_file", ENV{SYSTEMD_READY}="0"
# Ignore nbd devices until the PID file exists (which signals a connected device)
SUBSYSTEM=="block", KERNEL=="nbd*", ENV{DEVTYPE}=="disk", TEST!="pid", ENV{SYSTEMD_READY}="0"
# We need a hardware independent way to identify network devices. We
# use the /sys/subsystem/ path for this. Kernel "bus" and "class" names
# should be treated as one namespace, like udev handles it. This is mostly
# just an identification string for systemd, so whether the path actually is
# accessible or not does not matter as long as it is unique and in the
# filesystem namespace.
SUBSYSTEM=="net", KERNEL!="lo", TAG+="systemd", ENV{SYSTEMD_ALIAS}+="/sys/subsystem/net/devices/$name"
2020-09-07 09:06:00 +03:00
SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_ALIAS}+="/sys/subsystem/bluetooth/devices/%k", \
ENV{SYSTEMD_WANTS}+="bluetooth.target", ENV{SYSTEMD_USER_WANTS}+="bluetooth.target"
ENV{ID_SMARTCARD_READER}=="?*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="smartcard.target", ENV{SYSTEMD_USER_WANTS}+="smartcard.target"
SUBSYSTEM=="sound", KERNEL=="controlC*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="sound.target", ENV{SYSTEMD_USER_WANTS}+="sound.target"
SUBSYSTEM=="printer", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target", ENV{SYSTEMD_USER_WANTS}+="printer.target"
SUBSYSTEM=="usb", KERNEL=="lp*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target", ENV{SYSTEMD_USER_WANTS}+="printer.target"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target", ENV{SYSTEMD_USER_WANTS}+="printer.target"
SUBSYSTEM=="udc", TAG+="systemd", ENV{SYSTEMD_WANTS}+="usb-gadget.target"
# Apply sysctl variables to network devices (and only to those) as they appear.
ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="{{LIBEXECDIR}}/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
{% if ENABLE_BACKLIGHT %}
# Pull in backlight save/restore for all backlight devices and
# keyboard backlights
SUBSYSTEM=="backlight", TAG+="systemd", IMPORT{builtin}="path_id", ENV{SYSTEMD_WANTS}+="systemd-backlight@backlight:$name.service"
SUBSYSTEM=="leds", KERNEL=="*kbd_backlight*", TAG+="systemd", IMPORT{builtin}="path_id", ENV{SYSTEMD_WANTS}+="systemd-backlight@leds:$name.service"
{% endif %}
# Pull in rfkill save/restore for all rfkill devices
SUBSYSTEM=="rfkill", ENV{SYSTEMD_RFKILL}="1"
SUBSYSTEM=="rfkill", IMPORT{builtin}="path_id"
SUBSYSTEM=="misc", KERNEL=="rfkill", TAG+="systemd", ENV{SYSTEMD_WANTS}+="systemd-rfkill.socket"
# Asynchronously mount file systems implemented by these modules as soon as they are loaded.
SUBSYSTEM=="module", KERNEL=="fuse", TAG+="systemd", ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"
SUBSYSTEM=="module", KERNEL=="configfs", TAG+="systemd", ENV{SYSTEMD_WANTS}+="sys-kernel-config.mount"
# Pull in tpm2.target whenever /dev/tpmrm* shows up
SUBSYSTEM=="tpmrm", KERNEL=="tpmrm[0-9]*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="tpm2.target"
LABEL="systemd_end"