1 files changed, 42 insertions, 0 deletions
diff --git a/upstream/archlinux/man8/systemd-udev-settle.service.8 b/upstream/archlinux/man8/systemd-udev-settle.service.8
new file mode 100644
index 00000000..d045f09e
--- /dev/null
+++ b/upstream/archlinux/man8/systemd-udev-settle.service.8
@@ -0,0 +1,42 @@
+'\" t
+.TH "SYSTEMD\-UDEV\-SETTLE\&.SERVICE" "8" "" "systemd 255" "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)