mirror of
https://github.com/systemd/systemd-stable.git
synced 2025-01-22 22:03:43 +03:00
bfde9421af
On some systems with lots of devices, device probing for certain drivers can take a very long time. If systemd-udevd detects a timeout and kills the worker running modprobe using SIGKILL, some devices will not be probed, or end up in unusable state. The --event-timeout option can be used to modify the maximum time spent in an uevent handler. But if systemd-udevd exits, it uses a different timeout, hard-coded to 30s, and exits when this timeout expires, causing all workers to be KILLed by systemd afterwards. In practice, this may lead to workers being killed after significantly less time than specified with the event-timeout. This is particularly significant during initrd processing: systemd-udevd will be stopped by systemd when initrd-switch-root.target is about to be isolated, which usually happens quickly after finding and mounting the root FS. If systemd-udevd is started by PID 1 (i.e. basically always), systemd will kill both udevd and the workers after expiry of TimeoutStopSec. This is actually better than the built-in udevd timeout, because it's more transparent and configurable for users. This way users can avoid the mentioned boot problem by simply increasing StopTimeoutSec= in systemd-udevd.service. If udevd is not started by systemd (standalone), this is still an improvement. udevd will kill hanging workers when the event timeout is reached, which is configurable via the udev.event_timeout= kernel command line parameter. Before this patch, udevd would simply exit with workers still running, which would then become zombie processes. With the timeout removed, the sd_event_now() assertion in manager_exit() can be dropped.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.