udev racing between systemd and android container
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Canonical System Image |
New
|
Undecided
|
Unassigned | ||
Bug Description
In the vivid/upstart age, host system udev service was postponed until android container ueventd finished its cold boot process. Uevents are not filtered by network namespaces, so it follows, in vivid/upstart, when host system udevd begins its processing, android ueventd also receives the same event and re-process the same thing twice. However, the processing is relatively easy in android ueventd.
In contrast, in xenial/systemd configuration, udevd is the basis of most daemons/services, inclusive of lxc-android-config currently. This means systemd-udevd is started first, processes all the uevents, then invokes android container and its ueventd eventually. This time, when android ueventd is processing uevents, host systemd-udevd is affected. It will redo many complex handlings such as re-mount filesystem, re-trigger services, etc. This brings some uncertainties of the progress as well as startup stall as we currently know in bug 1644445.
Note that it's unlikely to move android ueventd startup before systemd-udevd. When we're migrating to lxd in bug 1641549, it's inevitable that lxd daemon runs after systemd-udevd, and android ueventd runs after lxd daemon. So applies to snap conversion in bug 1641561, systemd has to prepare the environment for snapd, and snapd prepares the environment for android container.
