<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - udevd have no measure to avoid exiting before all jobs are done"
href="https://bugs.freedesktop.org/show_bug.cgi?id=90051#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - udevd have no measure to avoid exiting before all jobs are done"
href="https://bugs.freedesktop.org/show_bug.cgi?id=90051">bug 90051</a>
from <span class="vcard"><a class="email" href="mailto:tom.ty89@gmail.com" title="Tom Yan <tom.ty89@gmail.com>"> <span class="fn">Tom Yan</span></a>
</span></b>
<pre>(In reply to Tom Gundersen from <a href="show_bug.cgi?id=90051#c2">comment #2</a>)
<span class="quote">> What you should see is that once you call exit, udev exits "almost
> immediately".</span >
This is true for `udevadm control --exit`, but if udevd is started and stopped
as a service, this is generally false. Here is an example, which you can see
that it waits for exactly 30s:
[tom@localhost ~]$ systemctl status -l systemd-udevd
● systemd-udevd.service - udev Kernel Device Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static;
vendor preset: disabled)
Active: active (running) since Fri 2015-04-24 19:36:02 HKT; 46s ago
Docs: man:systemd-udevd.service(8)
man:udev(7)
Main PID: 194 (systemd-udevd)
CGroup: /system.slice/systemd-udevd.service
└─194 /usr/lib/systemd/systemd-udevd
Apr 24 19:36:02 localhost systemd-udevd[194]: starting version 219
[tom@localhost ~]$ systemctl status -l systemd-udevd
● systemd-udevd.service - udev Kernel Device Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static;
vendor preset: disabled)
Active: inactive (dead) since Fri 2015-04-24 19:37:26 HKT; 2s ago
Docs: man:systemd-udevd.service(8)
man:udev(7)
Process: 659 ExecStart=/usr/lib/systemd/systemd-udevd (code=exited,
status=0/SUCCESS)
Main PID: 659 (code=exited, status=0/SUCCESS)
Apr 24 19:36:55 localhost systemd-udevd[659]: starting version 219
Apr 24 19:36:55 localhost systemd[1]: Started udev Kernel Device Manager.
Apr 24 19:36:55 localhost systemd[1]: Stopping udev Kernel Device Manager...
Apr 24 19:36:55 localhost systemd-udevd[659]: worker [668] did not accept
message -1 (Connection refused), kill it
Apr 24 19:36:55 localhost systemd-udevd[659]: worker [672] did not accept
message -1 (Connection refused), kill it
Apr 24 19:36:55 localhost systemd-udevd[659]: worker [677] did not accept
message -1 (Connection refused), kill it
Apr 24 19:36:55 localhost systemd-udevd[659]: worker [682] did not accept
message -1 (Connection refused), kill it
Apr 24 19:36:55 localhost systemd-udevd[659]: worker [682] terminated by signal
9 (Killed)
Apr 24 19:37:25 localhost systemd-udevd[659]: timeout, giving up waiting for
workers to finish
Apr 24 19:37:26 localhost systemd[1]: Stopped udev Kernel Device Manager.
But during the wait, I only see the main pid with `watch -n 0.1 pgrep udev`.
(Well most of the wait, like 29.x seconds out of 30)
<span class="quote">> Lastly, if if you want to make sure that udevd only exits after all the
> events caused by trigger have been processed, that is precisely what settle
> is for. It waits for udevd to receive the triggered events and then it waits
> for udevd to finish procssing them all (new events may appear at any time,
> but we make no guarantees about those).</span >
It doesn't seem to work in the way you said. For example in this script:
<a href="https://projects.archlinux.org/svntogit/packages.git/tree/trunk/initcpio-hook-udev?h=packages/systemd">https://projects.archlinux.org/svntogit/packages.git/tree/trunk/initcpio-hook-udev?h=packages/systemd</a>
I assume that `udevadm settle` should make sure that events triggered by the
two commands before it should be finished? But from what I am experiencing it
does not.
For example, a number of kernel modules is included in the initramfs. Suppose
given enough time (with `sleep` command), 26 of them would be loaded in early
user space, but if only `udevadm settle` is used, the number could be random.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>