summaryrefslogtreecommitdiffstats
path: root/upstream/debian-bookworm/man8/systemd-udev-settle.service.8
blob: 315e7e70faffda8cd64f4e8dca0769af202bd8fa (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
'\" t
.TH "SYSTEMD\-UDEV\-SETTLE\&.SERVICE" "8" "" "systemd 254" "systemd-udev-settle.service"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
systemd-udev-settle.service \- Wait for all pending udev events to be handled
.SH "SYNOPSIS"
.PP
systemd\-udev\-settle\&.service
.SH "DESCRIPTION"
.PP
This service calls
\fBudevadm settle\fR
to wait until all events that have been queued by
\fBudev\fR(7)
have been processed\&. It is a crude way to wait until "all" hardware has been discovered\&. Services may pull in this service and order themselves after it to wait for the udev queue to be empty\&.
.PP
\fIUsing this service is not recommended\&.\fR
There can be no guarantee that hardware is fully discovered at any specific time, because the kernel does hardware detection asynchronously, and certain buses and devices take a very long time to become ready, and also additional hardware may be plugged in at any time\&. Instead, services should subscribe to udev events and react to any new hardware as it is discovered\&. Services that, based on configuration, expect certain devices to appear, may warn or report failure after a timeout\&. This timeout should be tailored to the hardware type\&. Waiting for
systemd\-udev\-settle\&.service
usually slows boot significantly, because it means waiting for all unrelated events too\&.
.SH "SEE ALSO"
.PP
\fBudev\fR(7),
\fBudevadm\fR(8)