udev - Arch Linux 中文维基

跳至內容

# udev

出自 Arch Linux 中文维基

翻譯狀態：

- 本文（或部分內容）譯自 Udev，最近一次同步於 2023-01-26，若英文版本有所更改，則您可以幫助同步與翻譯更改的內容。
- 您可以在 ArchWiki 的對應頁面找到本文翻譯的原始修訂歷史。
- 本文可能與英文原文存在出入。

udev 是一個用戶空間的設備管理器，用於為事件設置處理程序。作為守護進程， udev 接收的事件主要由 linux 內核生成，這些事件是外部設備產生的物理事件。總之， udev 探測外設和熱插拔，將設備控制權傳遞給內核，例如加載內核模塊或設備固件。

udev 是一個用戶空間系統，可以讓作業系統管理員為事件註冊用戶空間處理器。為了實現外設偵測和熱插拔，udev 守護進程接收 Linux 內核發出的外設相關事件; 加載內核模塊、設備固件; 調整設備權限，讓普通用戶和用戶組能夠訪問設備。

作為 devfsd 和 hotplug 的替代品， udev 還負責管理 `/dev` 中的設備節點，即添加、連結和重命名節點，取代了 hotplug 和 hwdetect。

udev 並行處理事件，具有潛在的性能優勢，但是無法保證每次加載模塊的順序，例如如果有兩個硬碟， `/dev/sda` 在下次啟動後可能變成 `/dev/sdb` 。本文後面有更詳細的信息。

## 安裝

Udev 現在是 systemd包 的組成部分，默認已安裝。有關信息請查閱 `systemd-udevd.service(8)` 的手冊頁。

## udev 規則

udev 規則以管理員身份編寫並保存在 `/etc/udev/rules.d/` 目錄，其文件名必須以 `.rules` 結尾。各種軟體包提供的規則文件位於 `/lib/udev/rules.d/`。如果 `/usr/lib` 和 `/etc` 這兩個目錄中有同名文件，則 `/etc` 中的文件優先。

要學習 udev 規則，請參考 udev(7) 手冊和編寫 udev 規則及其提供的一些實用案例。

### 編寫 udev 規則

警告：要掛載可行動裝置，請不要通過在 udev 規則中調用 `mount` 命令的方法。對 FUSE 文件系統將會導致 `Transport endpoint not connected` 錯誤。應代之以 udisks 以正確處理自動掛載。或者把掛載動作放在 udev 規則內部：

將 `/usr/lib/systemd/system/systemd-udevd.service` 複製到 `/etc/systemd/system/systemd-udevd.service`，將 `MountFlags=slave` 替換為 `MountFlags=shared`。（來源）

udev 不應該用於啟動長期運行的進程.

- 要想學習寫udev規則，請訪問編寫 udev 規則。
- 要想查看 udev 規則的例子，請查閱上述文章的範例章節。

下面是一個規則的實例，當接入攝像頭時創建符號連結 `/dev/video-cam1` 。

假設攝像頭已經連接，加載的設備為 `/dev/video2`。編寫此規則的原因是下次引導時這個設備名可能變化，比如變成 `/dev/video0`。

    $ udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/dev/video2)

    Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices.
    It prints for every device found, all possible attributes in the udev rules key format.
    A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.

    looking at device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0/video4linux/video2':
      KERNEL=="video2"
      SUBSYSTEM=="video4linux"
       ...
    looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0':
      KERNELS=="3-2:1.0"
      SUBSYSTEMS=="usb"
      ...
    looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2':
      KERNELS=="3-2"
      SUBSYSTEMS=="usb"
      ATTRS{idVendor}=="05a9"
      ATTRS{manufacturer}=="OmniVision Technologies, Inc."
      ATTRS{removable}=="unknown"
      ATTRS{idProduct}=="4519"
      ATTRS{bDeviceClass}=="00"
      ATTRS{product}=="USB Camera"
      ...

為了確認 webcamera 設備，我們使用 `KERNEL=="video2"` 和 `SUBSYSTEM=="video4linux"`，向上兩極到 `SUBSYSTEMS=="usb"`，使用廠商和產品 ID 進行定位： `ATTRS{idVendor}=="05a9"` 和 `ATTRS{idProduct}=="4519"`。

可以為此設備編寫規則:

    /etc/udev/rules.d/83-webcam.rules

    KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam"

這裡使用 `SYMLINK+="video-cam"` 創建了軟連結，這樣可以設置用戶 `OWNER="john"` 或用戶組 `GROUP="video"` 或者通過 `MODE="0660"` 設置權限。

如果要編寫設備移除時執行的腳本，請注意此時可能無法訪問設備屬性。需要使用提前設置的環境變量。要監控這些環境變量，在拔掉設備時執行如下命令：

    $ udevadm monitor --property --udev

在命令輸出中可以看到類似 `ID_VENDOR_ID` 和 `ID_MODEL_ID` 這樣的值，它們對應 `idVendor` 和 `idProduct` 屬性。下面是一個使用設備環境變量的規則示例：

    /etc/udev/rules.d/83-webcam-removed.rules

    ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="05a9", ENV{ID_MODEL_ID}=="4519", RUN+="/path/to/your/script"

### 列出設備屬性

要列出所有設備的屬性以用來編寫規則的話，運行下面的命令：

    $ udevadm info --attribute-walk --name=device_name

將 `device name` 替換為系統中存在的設備，比如 `/dev/sda` 或 `/dev/ttyUSB0`。

如果你不知道設備名，你也可以列出某個系統路徑的屬性：

     $ udevadm info --attribute-walk --path=/sys/class/backlight/acpi_video0

可以通過類型過濾掉不需要的輸出:

    $ ls /dev/class/by-id

可以在 `--name` 中使用最終文件或軟連接:

    $ udevadm info --attribute-walk --name=/dev/input/by-id/usb-foostan_Corne-event-kbd

要獲得裸 USB 設備(未創建任何子設備) 的信息，需要使用完整的 USB 設備路徑, 先啟動監控模式，然後插入 USB 設備：

    $ udevadm monitor

    ...
    KERNEL[26652.638931] add      /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3 (usb)
    KERNEL[26652.639153] add      /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3/1-3:1.0 (usb)
    ...

可以使用最深的路徑， `--attribute-walk` 會顯示全部父屬性：

    $ udevadm info --attribute-walk --path=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3/1-3:1.0

### 加載前測試規則

    # udevadm test $(udevadm info --query=path --name=device_name) 2>&1

這不會運行你的規則中的所有命令，但會處理已有設備的符號連接，如果你不能加載它們這也許會變得方便。也可以直接輸入你測試的設備路徑：

    # udevadm test /sys/class/backlight/acpi_video0/

### 加載新規則

Udev 自動偵測規則文件的變化，所以修改會立即生效，無需重啟 udev。但已接入設備的規則不會自動觸發。像 USB 這類熱插拔設備也許需要重新插拔才能使新規則生效，也可能需要卸載並重載內核的 ohci-hcd 和 ehci-hcd 模塊以重新掛載所有 USB 設備。

如果規則自動重載失敗

    # udevadm control --reload

可以手工強制觸發規則

    # udevadm trigger

## Udisks

參閱 Udisks.

## 提示與技巧

### Mounting drives in rules

To mount removable drives, do not call `mount` from udev rules. This is ill-advised for two reasons:

1. systemd by default runs `systemd-udevd.service` with a separate "mount namespace" (see namespaces(7)), which means that mounts will not be visible to the rest of the system.
2. Even if you change the service parameters to fix this (commenting out the `PrivateMounts` and `MountFlags` lines), there is another problem which is that processes started from Udev are killed after a few seconds. In case of FUSE filesystems, such as NTFS-3G, mount starts a user-space process to handle the filesystem internals; when this is killed you will get `Transport endpoint not connected` errors if you try to access the filesystem.

There are some options that work:

- Start a custom systemd service from the Udev rule; the systemd service can invoke a script which can start any number of long-running processes (like FUSE). A concise example which automatically mounts USB disks under `/media` is udev-media-automount. A variant of the same idea is explained in this blog post.
- Use `systemd-mount` instead of `mount` in your Udev rule. This is recommended by systemd developers. For example this Udev rule should mount USB disks under `/media`:

      ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --collect $devnode /media"

- Use a package like udisks or udiskie. These are very powerful, but difficult to set up. Also, they are meant to be used in single user sessions, since they make some filesystems available under the ownership of the unprivileged user whose session is currently active.

### Allowing regular users to use devices

When a kernel driver initializes a device, the default state of the device node is to be owned by `root:root`, with permissions `600`. [1] This makes devices inaccessible to regular users unless the driver changes the default, or a udev rule in userspace changes the permissions.

The `OWNER`, `GROUP`, and `MODE` udev values can be used to provide access, though one encounters the issue of how to make a device usable to all users without an overly permissive mode. Ubuntu's approach is to create a `plugdev` group that devices are added to, but this practice is not only discouraged by the systemd developers, [2] but considered a bug when shipped in udev rules on Arch (FS#35602). Another approach historically employed, as described in Users and groups#Pre-systemd groups, is to have different groups corresponding to categories of devices.

The modern recommended approach for systemd systems is to use a `MODE` of `660` to let the group use the device, and then attach a `TAG` named `uaccess` [3]. This special tag makes udev apply a dynamic user ACL to the device node, which coordinates with systemd-logind(8) to make the device usable to logged-in users. For an example of a udev rule implementing this:

    /etc/udev/rules.d/71-device-name.rules

    SUBSYSTEMS=="usb", ATTRS{idVendor}=="vendor_id", ATTRS{idProduct}=="product_id", MODE="0660", TAG+="uaccess"

### Execute when HDMI cable is plugged in or unplugged

Create the rule `/etc/udev/rules.d/95-hdmi-plug.rules` with the following content:

    ACTION=="change", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/path/to/script.sh"

注意：If the rule triggers before the X server starts, it may not work as intended. See #X programs in RUN rules hang when no X server is present.

### VGA 線纜接入時執行規則

創建包含下列內容的規則文件 `/etc/udev/rules.d/95-monitor-hotplug.rules` ，可以在 VGA 線纜插入時執行 arandr包：

    KERNEL=="card0", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/arandr"

提示：某些顯示管理器把 .Xauthority 文件保存在用戶家目錄以外的位置，需要修改 ENV{XAUTHORITY} 的內容。例如，GNOME 顯示管理器 裡的.Xauthority 文件路徑如下所示：

    $ printenv XAUTHORITY

    /run/user/1000/gdm/Xauthority

注意：If the rule triggers before the X server starts, it may not work as intended. See #X programs in RUN rules hang when no X server is present.

### 偵測新的 eSATA 設備

If your eSATA drive is not detected when you plug it in, there are a few things you can try. You can reboot with the eSATA plugged in. Or you could try

    # echo 0 0 0 > /sys/class/scsi_host/host*/scan

Or you could install scsiaddAUR (from the AUR) and try

    # scsiadd -s

Hopefully, your drive is now in `/dev`. If it is not, you could try the above commands while running

    # udevadm monitor

to see if anything is actually happening.

### 將內置 SATA 接口標記為 eSATA

If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. GNOME and KDE will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal GNOME user can connect their eSATA drives to that port like a USB drive, without any root password and so on.

    /etc/udev/rules.d/10-esata.rules

    DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM}="0"

注意：The `DEVPATH` can be found after connection the eSATA drive with the following commands (replace `sdb` accordingly):

    # udevadm info -q path -n /dev/sdb
    /devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb

    # find /sys/devices/ -name sdb
    /sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb

### 設置靜態設備名

由於 udev 異步加載所有模塊，使得它們被初始化的次序不同。這將導致設備會隨機改變名稱。可以添加一條 udev 規則使得設備使用靜態名稱。

對於塊設備和網絡設備的規則配置，請分別參閱塊設備持久化命名和網絡配置-設備命名。

#### 視頻設備

For setting up the webcam in the first place, refer to 網絡攝像機配置.

Using multiple webcams will assign video devices as `/dev/video*` randomly on boot. The recommended solution is to create symlinks using a udev rule as in the #udev rule example:

    /etc/udev/rules.d/83-webcam.rules

    KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"
    KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="08f6", SYMLINK+="video-cam2"

注意：Using names other than `/dev/video*` will break preloading of `v4l1compat.so` and perhaps `v4l2convert.so`

#### 印表機

If you use multiple printers, `/dev/lp[0-9]` devices will be assigned randomly on boot, which will break e.g. CUPS configuration.

You can create following rule, which will create symlinks under `/dev/lp/by-id` and `/dev/lp/by-path`, similar to Persistent block device naming scheme:

    /etc/udev/rules.d/60-persistent-printer.rules

    ACTION=="remove", GOTO="persistent_printer_end"

    # This should not be necessary
    #KERNEL!="lp*", GOTO="persistent_printer_end"

    SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
    ENV{ID_TYPE}!="printer", GOTO="persistent_printer_end"

    ENV{ID_SERIAL}=="?*", SYMLINK+="lp/by-id/$env{ID_BUS}-$env{ID_SERIAL}"

    IMPORT{builtin}="path_id"
    ENV{ID_PATH}=="?*", SYMLINK+="lp/by-path/$env{ID_PATH}"

    LABEL="persistent_printer_end"

### Identifying a disk by its serial

To perform some action on a specific disk device `/dev/sdX` identified permanently by its unique serial `ID_SERIAL_SHORT` as displayed with `udevadm info /dev/sdX`, one can use the below rule. It is passing as a parameter the device name found if any to illustrate:

    /etc/udev/rules.d/69-disk.rules

    ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_SERIAL_SHORT}=="X5ER1ALX", RUN+="/path/to/script /dev/%k"

### 喚醒掛起的 USB 設備

A udev rule can be useful to enable the wakeup triggers of a USB device, like a mouse or a keyboard, so that it can be used to wake the system from sleep.

注意：By default, the USB host controllers are all enabled for wakeup. The status can be checked using `cat /proc/acpi/wakeup`. The rule below is in this case not necessary but can be used as a template to perform other actions, like disabling the wakeup functionality for example.

First, identify the vendor and product identifiers of the USB device. They will be used to recognize it in the udev rule. For example:

    $ lsusb | grep Logitech

    Bus 007 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver

Then, find where the device is connected to using:

    $ grep c52b /sys/bus/usb/devices/*/idProduct

    /sys/bus/usb/devices/1-1.1.1.4/idProduct:c52b

Now create the rule to change the `power/wakeup` attribute of both the device and the USB controller it is connected to whenever it is added:

    /etc/udev/rules.d/50-wake-on-device.rules

    ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="enabled", ATTR{driver/1-1.1.1.4/power/wakeup}="enabled"

### 觸發事件

It can be useful to trigger various udev events. For example, you might want to simulate a USB device disconnect on a remote machine. In such cases, use `udevadm trigger`:

     # udevadm trigger --verbose --type=subsystems --action=remove --subsystem-match=usb --attr-match="idVendor=abcd"

This command will trigger a USB remove event on all USB devices with vendor ID `abcd`.

### Triggering desktop notifications from a udev rule

本文或本章節的事實準確性存在爭議。

原因： This is a lengthy monologue on how to hardcode variables（在 Talk:Udev 中討論）

Invoking an external script containing calls to `notify-send` via udev can sometimes be challenging since the notification(s) never display on the Desktop. Here is an example of what commands and environmental variables need to be included in which files for `notify-send` to successfully be executed from a udev rule.

注意：A number of variables are hardcoded in this example, thus consider making them portable (i.e., $USER rather than user's shortname) once you understand the example.

1) The following udev rule executes a script that plays a notification sound and sends a desktop notification when screen brightness is changed according to power state on a laptop. Create the file:

    /etc/udev/rules.d/99-backlight_notification.rules

    # Rule for when switching to battery
    ACTION=="change", SUBSYSTEM=="power_supply", ATTR{type}=="Mains", ATTR{online}=="0", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/USERNAME/.Xauthority" RUN+="/usr/bin/su USERNAME_TO_RUN_SCRIPT_AS -c /usr/local/bin/brightness_notification.sh"
    # Rule for when switching to AC
    ACTION=="change", SUBSYSTEM=="power_supply", ATTR{type}=="Mains", ATTR{online}=="1", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/USERNAME/.Xauthority" RUN+="/usr/bin/su USERNAME_TO_RUN_SCRIPT_AS -c /usr/local/bin/brightness_notification.sh"

- `USERNAME_TO_RUN_SCRIPT_AS` and `USERNAME` need to be changed to that of the shortname for the user of the graphical session where the notification will be displayed;
- the script needs to be executed with `/usr/bin/su`, which will place its ownership under the user of the graphical session (rather than root/the system) where the notification will be displayed.

2) Contents of the executable script to be run on trigger of the udev rule:

    /usr/local/bin/brightness_notification.sh

    #!/bin/sh

    export XAUTHORITY=/home/USERNAME_TO_RUN_SCRIPT_AS/.Xauthority
    export DISPLAY=:0
    export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/UID_OF_USER_TO_RUN_SCRIPT_AS/bus"

    /usr/bin/sudo -u USERNAME_TO_RUN_SCRIPT_AS /usr/bin/paplay --server=/run/user/UID_OF_USER_TO_RUN_SCRIPT_AS/pulse/native /home/USERNAME/.i3/sounds/Click1.wav > /dev/null 2>&1

    /usr/bin/notify-send --icon=/usr/share/icons/gnome/256x256/status/battery-full-charging.png 'Changing Power States' --expire-time=4000

- `USERNAME_TO_RUN_SCRIPT_AS`, `UID_OF_USER_TO_RUN_SCRIPT_AS` and `USERNAME` needs to be changed to that of the shortname for the user and user's UID of the graphical session where the notification will be displayed;
- `/usr/bin/sudo` is needed when playing audio via pulseaudio;
- three environmental variables (i.e., `XAUTHORITY`, `DISPLAY` and `DBUS_SESSION_BUS_ADDRESS`) for the user of the graphical session where the notification will be displayed need to be defined and exported.

提示：See also xpubAUR as a method for getting the user's display environment variables and exporting the last into udev rules via `IMPORT` key.

3) Load/reload the new udev rule (see above) and test it by unplugging the power supply to the laptop.

注意：If the rule triggers before the X server starts, it may not work as intended. See #X programs in RUN rules hang when no X server is present.

## 排錯

### 屏蔽模塊

極個別情況下，udev 也會犯錯或加載錯誤的模塊。為了防止錯誤的發生，你可以使用模塊禁用列表。只要模塊加入該列表，無論是啟動時，或者是運行時（如usb硬碟等）udev都不會加載這些模塊。參見blacklisting.

### Debug output

To get hardware debug info, use the 內核參數 `udev.log-priority=debug`. Alternatively you can set

    /etc/udev/udev.conf

    udev_log="debug"

This option can also be compiled into your initramfs by adding the config file to your `FILES` array

    /etc/mkinitcpio.conf

    FILES="... /etc/udev/udev.conf"

and then rebuilding the initramfs with

    # mkinitcpio -p linux

### udevd 引導時掛起

After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.

Extract the group names referenced in udev rules and the group names actually present on the system:

    # grep -Fr GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d/ | sed 's:.*GROUP="\([-a-z_]\{1,\}\)".*:\1:' | sort -u >udev_groups
    # cut -d: -f1 /etc/gshadow /etc/group | sort -u >present_groups

To see the differences, do a side-by-side diff:

    # diff -y present_groups udev_groups
    ...
    network							      <
    nobody							      <
    ntp							      <
    optical								optical
    power							      |	pcscd
    rfkill							      <
    root								root
    scanner								scanner
    smmsp							      <
    storage								storage
    ...

In this case, the `pcscd` group is for some reason not present in the system. Add the missing groups. Also, make sure that local resources are looked up before resorting to LDAP. `/etc/nsswitch.conf` should contain the following line:

    group: files ldap

### 一些行動裝置不可移除

You need to create a custom udev rule for that particular device. To get definitive information of the device you can use either `ID_SERIAL` or `ID_SERIAL_SHORT` (remember to change `/dev/sdb` if needed):

    $ udevadm info /dev/sdb | grep ID_SERIAL

Then we set `UDISKS_AUTO="1"` to mark the device for automounting and `UDISKS_SYSTEM="0"` to mark the device as "removable". See udisks(8) for details.

    /etc/udev/rules.d/99-removable.rules

    ENV{ID_SERIAL_SHORT}=="serial_number", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"

Remember to reload udev rules with `udevadm control --reload`. Next time you plug your device in, it will be treated as an external drive.

### 聲音問題和一些不能自動加載的模塊

一些用戶發現 `/etc/modprobe.d/sound.conf` 中的遺留配置會引起這些問題，請清理配置並重試。

注意：從 `udev>=171` 開始 OSS 模擬模塊(`snd_seq_oss, snd_pcm_oss, snd_mixer_oss`) 默認不會自動裝載。

### IDE CD/DVD 驅動器的支持

Starting with version 170, udev does not support CD-ROM/DVD-ROM drives that are loaded as traditional IDE drives with the `ide_cd_mod` module and show up as `/dev/hd*`. The drive remains usable for tools which access the hardware directly, like cdparanoia, but is invisible for higher userspace programs, like KDE.

A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your initramfs. In that case you can just replace it with ata_piix in your `/etc/mkinitcpio.conf`.

### 光碟機被標識為磁碟

If the group ID of your optical drive is set to `disk` and you want to have it set to `optical`, you have to create a custom udev rule:

    /etc/udev/rules.d

    # permissions for IDE CD devices
    SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"

    # permissions for SCSI CD devices
    SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"

### X programs in RUN rules hang when no X server is present

When xrandr or another X-based program tries to connect to an X server, it falls back to a TCP connection on failure. However, due to `IPAddressDeny` in the systemd-udev service configuration, this hangs. Eventually the program will be killed and event processing will resume.

If the rule is for a drm device and the hang causes event processing to complete once the X server has started, this can cause 3D acceleration to stop working with a `failed to authenticate magic` error.

## 參閱

- udev manual
- An Introduction to udev
- udev 郵件列表
- 編寫 udev 規則
- Writing udev rules
- LFS 系統設備與模塊處理
- Running GUI or accessing display variables from udev rules
- openSUSE udev documentation
- 中文讀者可參閱金步國先生翻譯的 udev 中文手冊

分類：​

- 硬體檢測和故障排除

隱藏分類：​

- 使用「模板:準確性」標記的頁面或章節

udev
新增話題