X-Git-Url: http://git.ipfire.org/?a=blobdiff_plain;f=man%2Fsystemd.device.xml;h=ff7ab9cccebf0326847d390f588ba52fac33c08f;hb=56fa3682b99b355166f6529e7eb2760528b56297;hp=6edf1090d0e0409b66b62d8336e86bcefadf0b67;hpb=f332611abee97247e40311d99492d53697152a1a;p=thirdparty%2Fsystemd.git diff --git a/man/systemd.device.xml b/man/systemd.device.xml index 6edf1090d0e..ff7ab9ccceb 100644 --- a/man/systemd.device.xml +++ b/man/systemd.device.xml @@ -1,39 +1,12 @@ - - - + systemd.device systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - @@ -88,59 +61,63 @@ corresponding device generates a changed event. Other units can use ReloadPropagatedFrom= to react to that event - - Implicit Dependencies - - Many unit types automatically acquire dependencies on device - units of devices they require. For example, - .socket unit acquire dependencies on the - device units of the network interface specified in - BindToDevice=. Similar, swap and mount units - acquire dependencies on the units encapsulating their backing - block devices. - + Automatic Dependencies - - Default Dependencies + + Implicit Dependencies + + Many unit types automatically acquire dependencies on device + units of devices they require. For example, + .socket unit acquire dependencies on the + device units of the network interface specified in + BindToDevice=. Similar, swap and mount units + acquire dependencies on the units encapsulating their backing + block devices. + + + + Default Dependencies - There are no default dependencies for device units. + There are no default dependencies for device units. + The udev Database - The settings of device units may either be configured via - unit files, or directly from the udev database (which is - recommended). The following udev device properties are understood - by systemd: + Unit settings of device units may either be configured via unit files, or directly from the udev + database. The following udev device properties are understood by the service manager: SYSTEMD_WANTS= SYSTEMD_USER_WANTS= - Adds dependencies of type - Wants from the device unit to all listed - units. The first form is used by the system systemd instance, - the second by user systemd instances. Those settings may be - used to activate arbitrary units when a specific device - becomes available. - - Note that this and the other tags are not taken into - account unless the device is tagged with the - systemd string in the udev database, - because otherwise the device is not exposed as a systemd unit - (see above). - - Note that systemd will only act on - Wants dependencies when a device first - becomes active. It will not act on them if they are added to - devices that are already active. Use - SYSTEMD_READY= (see below) to influence on - which udev event to trigger the dependencies. - + Adds dependencies of type Wants= from the device unit to the specified + units. SYSTEMD_WANTS= is read by the system service manager, + SYSTEMD_USER_WANTS= by user service manager instances. These properties may be used to + activate arbitrary units when a specific device becomes available. + + Note that this and the other udev device properties are not taken into account unless the device is + tagged with the systemd tag in the udev database, because otherwise the device is not + exposed as a systemd unit (see above). + + Note that systemd will only act on Wants= dependencies when a device first becomes + active. It will not act on them if they are added to devices that are already active. Use + SYSTEMD_READY= (see below) to configure when a udev device shall be considered active, and + thus when to trigger the dependencies. + + + + The specified property value should be a space-separated list of valid unit names. If a unit template + name is specified (that is, a unit name containing an @ character indicating a unit name to + use for multiple instantiation, but with an empty instance name following the @), it will be + automatically instantiated by the device's sysfs path (that is: the path is escaped and + inserted as instance name into the template unit name). This is useful in order to instantiate a specific + template unit once for each device that appears and matches specific properties. @@ -152,20 +129,14 @@ SYSTEMD_READY= - If set to 0, systemd will consider this device - unplugged even if it shows up in the udev tree. If this - property is unset or set to 1, the device will be considered - plugged if it is visible in the udev tree. This property has - no influence on the behavior when a device disappears from the - udev tree. - - This option is useful to support devices that initially - show up in an uninitialized state in the tree, and for which a - changed event is generated the moment they - are fully set up. Note that SYSTEMD_WANTS= - (see above) is not acted on as long as - SYSTEMD_READY=0 is set for a - device. + If set to 0, systemd will consider this device unplugged even if it shows up in the udev + tree. If this property is unset or set to 1, the device will be considered plugged if it is visible in the udev + tree. + + This option is useful for devices that initially show up in an uninitialized state in the tree, and for + which a changed event is generated the moment they are fully set up. Note that + SYSTEMD_WANTS= (see above) is not acted on as long as SYSTEMD_READY=0 is + set for a device.