Franck Bui
918e6f1c01
PID1 updates the state of device units upon 2 different events: - when it processes an event sent by udev and in this case the device deps are started if the device enters in the "plugged" state. - when it enumerates all devices during its startup or when it is asked to reload its configuration data but in this case the device deps (if any) are not retroactively started. When udev processes a new "add" kernel event, it first registers the new device in its databases then sends an event to systemd. If for any reason, systemd is asked to reload its configuration between the previous 2 steps, it might see for the first time the new device while scanning /sys for all devices. Only during a second step, udev will send the event for the new device. In this peculiar case the device deps wont be started (even though the device is first seen by PID1). Indeed when reloading its configurations, PID1 will put the device unit in the "plugged" state but without starting the device deps. Thereafter PID1 will get the event from udev for the new device but the device unit will be in "plugged" state already therefore it won't see any need to start the device dependencies. Rather than assuming that during the reloading of systemd manager configuration all devices listed in udev DBs have been already processed and should be put in the "plugged" state (done by device_coldplug()), this patch does that only for devices which have been processed via an udev event (device_dispatch_io()) previously. In this case we set "d->found" to "DEVICE_FOUND_UDEV" and we make also sure to no more initialize "d->found" while enumerating devices. Instead this field is now saved/restored while devices are serialized.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are 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 file for information 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.