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

Optimize BlueChi's systemd units on boot #864

Closed
engelmi opened this issue Apr 2, 2024 · 4 comments
Closed

Optimize BlueChi's systemd units on boot #864

engelmi opened this issue Apr 2, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request jira Issues that are synced to Jira
Milestone

Comments

@engelmi
Copy link
Member

engelmi commented Apr 2, 2024

Please describe what you would like to see

Currently, the bluechi-agent and bluechi-controller are started After=network.target. This special target is only weakly defined and there is

no guarantee that hardware-based devices have shown up by the time this target is reached, or even acquired complete IP configuration

As an alternative, network-online.target is mentioned. However, it states there:

What precisely this requires is left to the implementation of the network managing service.

As well as:

Note that networking daemons that simply provide functionality to other hosts (as opposed to consume functionality of other hosts) generally do not need to pull this in.

Since both BlueChi components, controller and agent, require only the DBus to be up and running locally, the ordering on boot can be optimized to After=dbus.service.

Please describe the solution you'd like

The systemd units of bluechi-agent and bluechi-controller are changed to:

[Unit]
# ...
DefaultDependencies=no
Before=basic.target shutdown.target
After=dbus.service
Conflicts=shutdown.target
# ...
@engelmi engelmi added enhancement New feature or request jira Issues that are synced to Jira labels Apr 2, 2024
@engelmi engelmi added this to the v0.9 milestone Apr 8, 2024
@ArtiomDivak ArtiomDivak self-assigned this Oct 7, 2024
ArtiomDivak added a commit to ArtiomDivak/BlueChi that referenced this issue Oct 8, 2024
To optimize the bluechi-controller and bluechi-agent boot the After
parameter was vhange to dbus.service

Solves: eclipse-bluechi#864
Signed-off-by: Artiom Divak <[email protected]>
ArtiomDivak added a commit to ArtiomDivak/BlueChi that referenced this issue Oct 8, 2024
To optimize the bluechi-controller and bluechi-agent boot the After
parameter was change to dbus.service

Solves: eclipse-bluechi#864
Signed-off-by: Artiom Divak <[email protected]>
ArtiomDivak added a commit to ArtiomDivak/BlueChi that referenced this issue Oct 8, 2024
To optimize the bluechi-controller and bluechi-agent boot the After
parameter was change to dbus.service

Solves: eclipse-bluechi#864
Signed-off-by: Artiom Divak <[email protected]>
@engelmi engelmi modified the milestones: v0.9, v0.10 Nov 5, 2024
@alexlarsson
Copy link
Contributor

I don't think you even need dbus.service. All it needs dbus.socket, but i believe that is a dependency of basic.target via sockets.target, and basic.target is a default dependency for all services.

@alexlarsson
Copy link
Contributor

Ah, I see you drop the default deps, but still you only need dbus.socket to be able to start bluechi. It will then block startup until dbus-broker accepts the connection.

@alexlarsson
Copy link
Contributor

Honestly though, I'm not sure starting before basic.target is right. I wouldn't recommend disabling the default dependencies, as you will basically have a half-configured system at that point.

@engelmi
Copy link
Member Author

engelmi commented Jan 15, 2025

I agree and think we shouldn't implement this. If such optimizations are needed, these optimizations can be done outside of BlueChi itself. Lets close this.

@engelmi engelmi closed this as completed Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request jira Issues that are synced to Jira
Projects
None yet
Development

No branches or pull requests

3 participants