Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

device flags logic is borked #8832

Closed
poettering opened this issue Apr 26, 2018 · 3 comments
Closed

device flags logic is borked #8832

poettering opened this issue Apr 26, 2018 · 3 comments
Assignees
Labels
Milestone

Comments

@poettering
Copy link
Member

Just a tracker so that we fix the fall-out from #8675 fully (see #8798 for details)

@keszybz
Copy link
Member

keszybz commented May 28, 2018

Copying the relevant part from #8798 (comment):

The "DEVICE_FOUND_UDEV_DB" flag shouldn't be there.

I am not sure I grok everything fully, but I think we might not need to serialize the flag set at all, and always use what the kernel reports, but then when we notice that the new flag set is not in sync with the unit state enum we enqueue another state change, but do that in a defer event. That means that after deserialization we'll initially be in the old state, but pretty soon on react to the new state, and thus trigger the usual deps...

@poettering poettering self-assigned this Jun 4, 2018
@poettering
Copy link
Member Author

working on this now...

poettering added a commit to poettering/systemd that referenced this issue Jun 5, 2018
This reworks how device units are "powered on".

This makes sure that any device changes that might have happened while
we were restarting/reloading will be noticed properly. For that we'll
now properly serialize/deserialize both the device unit state and the
device "found" flags, and restore these initially in the "coldplug"
phase of the manager deserialization. While enumerating the udev devices
during startup we'll put together a new "found" flags mask, which we'll
the switch to in the "catchup" phase of the manager deserialization,
which follows the "coldplug" phase.

Note that during the "coldplug" phase no unit state change events are
generated, which is different for the "catchall" phase which will do
that. Thus we correctly make sure that the deserialized state won't pull
in new deps, but any device's change while we were reloading would.

Fixes: systemd#8832
Replaces: systemd#8675
@poettering
Copy link
Member Author

Fix waiting in #9200 now.

poettering added a commit to poettering/systemd that referenced this issue Jun 6, 2018
This reworks how device units are "powered on".

This makes sure that any device changes that might have happened while
we were restarting/reloading will be noticed properly. For that we'll
now properly serialize/deserialize both the device unit state and the
device "found" flags, and restore these initially in the "coldplug"
phase of the manager deserialization. While enumerating the udev devices
during startup we'll put together a new "found" flags mask, which we'll
the switch to in the "catchup" phase of the manager deserialization,
which follows the "coldplug" phase.

Note that during the "coldplug" phase no unit state change events are
generated, which is different for the "catchall" phase which will do
that. Thus we correctly make sure that the deserialized state won't pull
in new deps, but any device's change while we were reloading would.

Fixes: systemd#8832
Replaces: systemd#8675
poettering added a commit to poettering/systemd that referenced this issue Jun 7, 2018
This reworks how device units are "powered on".

This makes sure that any device changes that might have happened while
we were restarting/reloading will be noticed properly. For that we'll
now properly serialize/deserialize both the device unit state and the
device "found" flags, and restore these initially in the "coldplug"
phase of the manager deserialization. While enumerating the udev devices
during startup we'll put together a new "found" flags mask, which we'll
the switch to in the "catchup" phase of the manager deserialization,
which follows the "coldplug" phase.

Note that during the "coldplug" phase no unit state change events are
generated, which is different for the "catchall" phase which will do
that. Thus we correctly make sure that the deserialized state won't pull
in new deps, but any device's change while we were reloading would.

Fixes: systemd#8832
Replaces: systemd#8675
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants