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

support for "before milestones" #279

Open
q66 opened this issue Jan 22, 2024 · 2 comments
Open

support for "before milestones" #279

q66 opened this issue Jan 22, 2024 · 2 comments
Assignees
Labels
C-dinit-service Things about dinit-service Feature Request Request a feature to be added to dinit

Comments

@q66
Copy link
Sponsor Contributor

q66 commented Jan 22, 2024

Let's say we have a service, foo.target and a service foo that is set as before = foo.target, and another service bar that has depends-on = foo.target. The order of startup will be foo => foo.target => bar in this case.

However, there is no way to control what happens when foo fails to come up. I'd like to be able to make sure that if foo fails to come up, foo.target also fails. This can currently only be done by having the startup sequence of foo manually add a regular or milestone dependency from foo.target to foo.

The intended use of this is for firewall services, so their failure can abort the startup of further network services, but without the network services depending on a particular firewall. Currently we have a pre-network.target internal service which things that expect firewall to be up depend on. By having firewalls specify something like before-ms = pre-network.target instead of the current before = pre-network.target, we could achieve this more cleanly.

@mobin-2008 mobin-2008 added C-dinit-service Things about dinit-service Feature Request Request a feature to be added to dinit labels Jan 22, 2024
@davmac314 davmac314 self-assigned this Jan 30, 2024
@davmac314
Copy link
Owner

For clarity on what is wanted here: supposing that your firewall fails and causes network.target to fail as a result. Then the user (sysadmin) issues:

dinitctl start network.target

What is the expected outcome? I think you're probably going to want this to either fail immediately, or at least to try and re-start the firewall before allowing network.target to start? In that case this is less like a "before" and more like an actual (reverse) dependency. This could still be implemented, but I'd probably lean away from before-ms as a setting name in that case.

@q66
Copy link
Sponsor Contributor Author

q66 commented Feb 24, 2024

i was thinking the network.target could just come up regardless of the status of firewall in this case, but i'm fine with any behavior here (the user is not meant to start targets manually, and if they do, they're aware of the consequences)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-dinit-service Things about dinit-service Feature Request Request a feature to be added to dinit
Projects
None yet
Development

No branches or pull requests

3 participants