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

Easier handling for disabled qvm-services #9609

Open
3 tasks
marmarek opened this issue Nov 27, 2024 · 0 comments
Open
3 tasks

Easier handling for disabled qvm-services #9609

marmarek opened this issue Nov 27, 2024 · 0 comments
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.

Comments

@marmarek
Copy link
Member

How to file a helpful issue

The problem you're addressing (if any)

Right now, enabling qvm-service creates a /run/qubes-service/(service-name) file, which then can be used for ConditionPathExists=... in a systemd unit file. Disabling a service that is normally enabled prevents creating such file (or rather - removes the file that was created for default-enabled services). But explicitly disabled service is not easily distinguishable from not set service. This means services that each service that should be enabled by default, but can be disabled via qvm-service needs the file first to be created (for example in qubes-sysinit.sh) and then removed. The need to modify qubes-sysinit.sh makes it harder to use this method in other packages, and also doesn't scale well.

The solution you'd like

For disabled services, not only remove relevant /run/qubes-service file, but also create negated one. For example /run/qubes-service/no-(service-name), or maybe /run/qubes-service-disable/(service-name). Then, a systemd unit can have a ConditionPathExists=!/run/... and no qubes-sysinit.sh modification is needed.

The value to a user, and who that user might be

More flexible qvm-service framework.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

@marmarek marmarek added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Development

No branches or pull requests

2 participants