Run multiple service instances

snapd
#1

I need to run a snap app as a multi-instance service. Each instance will be run with a separate config.

Option 1. Add a daemon to snapcraft.yml. It looks like multi-instance daemons aren’t supported.

Option 2. Create my own systemd service:

[Unit]
Description=My Service %I
After=network-online.target

[Service]
ExecStart=snap run app --config %i.conf
Restart=always

[Install]
WantedBy=multi-user.target

But it this case, I don’t see logs, when I run journalctl -u myservice.service. The same issue is described here.

So I had to stick with Option 2, but I cannot view logs, which is unfortunate.

#2

Just create multiple daemon entries with slightly different names in your snapcraft.yaml…

#3

The problem in my case is that it’s a snap user to decide which config to provide to a daemon instance.

I probably can create multiple (let’s say 10) daemon entries , that will run different configs which a user will edit. But the user might need to run 11 instances, all with different configs.

#4

Sounds like that you need to script these things. For example:

One “main” service that will spin up multiple “daemons” and monitor them with the seperate configs (like a watchdog or something),

While having one or more command(s) fed with arguments to control those services independently (such as restarting one service from the others), instead of having to modify the snapcraft.yaml for 10 or more seperate services, which cannot be modified after building the snap.

Since the scripts and service(s) will run inside the snap container, you will just need to point the user to a configuration file or folder that they can modify and add/remove the configurations, and have the snap start/control the “daemon” with a command.

That’s how I would have done it.

1 Like
#5

Thanks for the suggested solution. But it looks like reinventing the wheel. I would expect the snapd to do all the dirty job of daemonizing for me.

Also I cannot figure out why when running as a systemd-unit (Option 2), I cannot see logs with journalctl (when running in a terminal, I do see the logs). I guess it might be due to strict confinement, but then it’s not obvious for me which interface I should connect.

#6

Right, this would have been my suggestion too… use a script to spawn them dynamically and use daemon: forking to have systemd handle all the children (and proper logging too)…

@fertkir your “Option 2” is really not an option at all, snaps can not ship random systemd units, they are generated during install time…

Indeed you can add wild hacks outside of the snap itself, but that would be at most a local thing, nothing other users would be able to use…

#7

Usually, your service will be running as snap.[yoursnapname].[snapservicenameyoudefinedinsnapcraftyaml].service, or something along these lines.

You could also list all the snap services running on the host with snap services or sudo snap services.