Help with starting systemd service in appvm only

User Support General
1

I don’t understand the doc’s here: Qubes service | Qubes OS

The only way I can start services is via /rw/config/rc.local

What I tried to do (samba):
add smb in the qubes-settings ( /var/run/qubes-service files appears here)

created /etc/systemd/system/smb.service.d/30_qubes.conf
with the content:

[Unit]
ConditionPathExists=/var/run/qubes-service/smb

but smb.service never starts up. What am I missing?

Obviously the service dir needs to be persistent, but even if I enable the service and make the symlink persistent in bindirs it does not start up ( /etc/systemd/system/multi-user.target.wants/smbd.service) .

As far as I remember adding the service in the qubes settings menu should be enough and adding a service under /etc/systemd/system/servicename/ is for custom ones?

2

You need to enable the systemd service in the TemplateVM (not in the AppVM through bind-dirs).

3

Yeah obviously that works, but thats precisely what I don’t want todo

I thought this method is an equivalent to adding ‘systemctl start smb’ in rc.local

4

To be clear, your 30_qubes.conf should also be created in the TemplateVM (not in the AppVM). If you then enable the systemd service only in the TemplateVM and the qube service only for the AppVM, the systemd condition will be fulfilled only for the AppVM, allowing the systemd service to start there but not in the TemplateVM.

5

that clears things up. Will try it

6

does still not startup:

currently on debian-12

[I] user@samba-test ~> sudo systemctl status smbd
○ smbd.service - Samba SMB Daemon
     Loaded: loaded (/lib/systemd/system/smbd.service; disabled; preset: enabled)
    Drop-In: /etc/systemd/system/smbd.service.d
             └─30_qubes.conf
     Active: inactive (dead)
       Docs: man:smbd(8)
             man:samba(7)
             man:smb.conf(5)

[I] user@samba-test ~> ls -lah /var/run/qubes-service/
total 0
drwxr-xr-x  2 root root 160 Apr 28 17:08 ./
drwxr-xr-x 31 root root 820 Apr 28 17:08 ../
-rw-r--r--  1 root root   0 Apr 28 17:08 evolution-data-server
-rw-r--r--  1 root root   0 Apr 28 17:08 meminfo-writer
-rw-r--r--  1 root root   0 Apr 28 17:08 qubes-update-check
-rw-r--r--  1 root root   0 Apr 28 17:08 smbd
-rw-r--r--  1 root root   0 Apr 28 17:08 software-rendering
-rw-r--r--  1 root root   0 Apr 28 17:08 tracker
7

It doesn’t look like the systemd service was enabled in the TemplateVM. (Did you shut down the latter before starting the AppVM?)

This may be intentional but you’ve enabled the smbd qube service, not the smb qube service like in your original 30_qubes.conf file.

8

Yeah on debian installing samba enables smbd by default, so I disabled it in the TemplateVM

And in the original I indeed used smb (tried on fedora first) but on debian smb and smbd are equivalent. ( swiched everything to smbd tho)

[I] root@samba-test /h/user# cat /etc/systemd/system/smbd.service.d/30_qubes.conf 
[Unit]
ConditionPathExists=/var/run/qubes-service/smbd
9

Well the systemd service really does need to be enabled in the TemplateVM (and only there).

10

So I need to enable the service in the templateVM and when I create
/etc/systemd/system/smbd.service.d/

A condition gets applied that disables the service in the all appvms?

11

The systemd service is still “enabled” in the TemplateVM and in AppVMs based on it, but the condition prevents it from actually being started in any qube that doesn’t also have the qube service enabled.

1 Like
12

Thanks I understand now. this appears to be exactly how it works

[I] user@dvm-debian ~> sudo systemctl status smbd
○ smbd.service - Samba SMB Daemon
     Loaded: loaded (/lib/systemd/system/smbd.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/smbd.service.d
             └─30_qubes.conf
     Active: inactive (dead)
       Docs: man:smbd(8)
             man:samba(7)
             man:smb.conf(5)

Thank you very much!

13

The whole thing is pretty weird. Basically systemd evaluates enabled/disabled status of all services at the very beginning of the boot process (before AppVM specific configuration is loaded), but conditions are evaluated at the last minute so they’re used as a workaround.

1 Like
14

An alternative approach is to disable and mask the service in the
template, and then unmask and start it from rc.local.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.