SystemD Unit file customization for a snap

Stuart Bishop stuart.bishop at
Thu Jan 12 04:36:13 UTC 2017

On 12 January 2017 at 11:33, Stuart Bishop <stuart.bishop at>

> On 12 January 2017 at 02:31, Charles Butler <charles.butler at>
> wrote:
> You don't have much control over the generated systemd service file. Its
> an open issue. So while you could have your snap accept configuration
> options, the snap can't rewrite its own systemd service file (or it could
> escape its containment). What you would need to do is write a wrapper for
> bin/etcd that sets the environment variables (pulled from snap
> configuration, or from a .ini file or similar stored in $SNAP_DATA or
> $SNAP_COMMON) before os.exec'ing the real bin/etcd

(and if you choose this approach, you of course need your charm to restart
the service when you change the config. snapd can't do that for you, yet.
Well, maybe the config handler is able to restart the service but I suspect
confinement would block that attempt)

Since you are driving this from a charm though, you don't need it. systemd
> supports '.d' style directories, allowing you to extend a .service file
> owned by some other process. This is how the snap layer adds support for
> downloading snaps via proxies, so see
> layer-snap/tree/reactive/ for an example.
Stuart Bishop <stuart.bishop at>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Snapcraft mailing list