<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <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#c2">Comment # 2</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 <a class="email" href="mailto:teg@jklm.no" title="Tom Gundersen <teg@jklm.no>"> Tom Gundersen</a> <pre>Hi, I'm having a hard time following this report. Let summarize how things are meant to work: Events received by udev (due to trigger) are either 'queued' or 'running' at any point in time. When you call 'exit', all the 'queued' events are dropped and the 'running' events are finished before we exit (up to a timeout of 30s). That means that even if one event is 'running' until the timeout, no new events are moved from 'queued' to running state. What you should see is that once you call exit, udev exits "almost immediately". If it does not, that should mean that an event is stuck in "running" state for a long time (this should not happen, but could happen due to kernel issues or other external factors). You can verify that by seeing if udevd has any child processes after you call exit. If udevd has no child processes, but still does not exit after you call exit, that is an udev bug. I was not able to reproduce that with your script though, so would be great if you could check that out. 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).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>