every VM/qube has a "services" tab in its settings window. It seems like
Qubes is designed in a manner that requires two switches for a service:
it needs to be enabled in the template *and* requires an entry in
"services" tab.
My expectation was that when selected in the "services" tab, qubesrc (or
any other instance) will just start the corresponding service in the VM.
During troubleshooting I found out that it is designed as above, but I
could not find the reason for this design decision.
At least the "services tab" should have a red text warning that it is
required to enable the service in the template as well in order to not
confuse users the way it confused myself.
that was the reference in qubes-doc that I found before and that I could
not find today when I was writing this email. However, it does not
explain what the advantage of this two-switch-model is compared to just
run the services defined in the per-qube services tab/setting without
the dependence on being enabled in the template.
That approach would render adding support for [any generic] systemd
service not only "pretty simple" but would make every systemd service
compatible "by design".
I think that a generic systemd service is already compatible by design:if
you install such a service and enable it in the template it will be
enabled in the qubes using that template. Is that not so?
The current system provides a simple condition that gives granular
control over services on a per qube basis.
The same control can be achieved by *disabling* the service in the template,
and having a switch that enables the service and starts it in the qube.
I do this myself in some cases. (From dom0 with qvm-run, or with entries
in rc.local, e.g.)
Both approaches require some action in the template as well as action in
the qube. So both are "two-switch".
The current mechanism provides a dead mans handle but allows services to
start at an early stage. You are not obliged to use it for other
services.