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

sd-network: ignore missing directory if networkd is disabled #62

Conversation

michaelolbrich
Copy link
Contributor

sd_network_monitor is used by timesyncd and resolved. Both can be enabled
while networkd is disabled. /run/systemd/netif/links/ only exists if
networkd is enabled at build-time, so ignore the corresponding error if it
is disabled.
The user that owns /run/systemd/netif/links/ may not exist if networkd is
disabled, so always creating this directory is not possible.

sd_network_monitor is used by timesyncd and resolved. Both can be enabled
while networkd is disabled. /run/systemd/netif/links/ only exists if
networkd is enabled at build-time, so ignore the corresponding error if it
is disabled.
The user that owns /run/systemd/netif/links/ may not exist if networkd is
disabled, so always creating this directory is not possible.
@poettering
Copy link
Member

Hmm, I think i'd relly prefer a more complex patch:

if we cannot add /run/systemd/netif/links/ to the inotify watch, then add /run/systemd/netif instead looking for new subdirs being created for that, If we cannot add this either, then add /run/systemd instead, looking for new subdirs.

Then, in sd_network_monitor_flush() actually iterate through the inotify events using the FOREACH_INOTIFY_EVENT() (which makes this very easy), and when we get events for /run/systemd or /run/systemd/netif try to readd /run/systemd/netif, and drop the other watches if that worked.

That way we can run networkd and its clients completely racefreely in parallel without any specific ordering or reduction in functionality.

@poettering poettering closed this Jun 8, 2015
@poettering
Copy link
Member

Hmm, sorry for closing the PR. That only means i think the patch needs more love, i do believe the issue should be fixed in general.

@poettering
Copy link
Member

github workflow is really weird, sorry.

@poettering
Copy link
Member

I created a new issue to track this as #107. Please make sure to reference that when posting a new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet

4 participants