First install + configure is not possible in one step for a daemon-containing snap

snapd
1

I’d like to do the initial snap install and snap set of a bunch of arguments at the same time, so that the configuration file is in place and reflects the configuration changes prior to starting the daemon for the first time.

Right now the following would happen for me:

$ snap set mysnap key=value
error: snap "mysnap" not found
$ snap install mysnap
(daemon start repeatedly fails because the default configuration needs modification)
(OR the use of default configuration doxes the service to the outside world)
$ snap set mysnap key=value
(configure hook generates the config file)
(daemon is restarted)
(daemon runs the way it was intended)

I think the install command should take optionally some name=value arguments to specify the initial configuration. It is not reasonable to expect every snap to work out of the box with a default configuration.

Consider my use case where I want bitcoind to run in onion-only mode, and the proxy port is not the standard port. I need to override quite a few parameters, and i don’t want the bitcoind daemon to be started even once with the default (empty) configuration, since doing so would expose my node as a bitcoind node through the network traffic it generates.

I envision something like

snap install bitcoind \
  dns=0 \
  dnsseed=0 \
  onlynet=onion \
  proxy=127.0.0.1:xyz

Thoughts?

2

Your install hook can snapctl stop --disable <servicename>, and then your configure hook can snapctl start --enable it if the right bits are set.
Or your configure hook can do both things (as the configure hook is also run on install).
Which is simpler to do depends on exactly what it is you need to check, and when it needs to be enabled and disabled.

HTH! HAND.

3

I’ll try the first option (–disable in install, --enable in configure), because from what I’ve seen so far,
snap install starts the daemon immediately, so you end up with a configure script and a daemon running simultaneously.

Thanks

4

Note that daemons are started after the install hook, but before the configure hook currently, so my recommendation would be to put the disable in the install and the re-enable in the configure.

1 Like