SystemD Unit file customization for a snap

[Stuart Bishop]

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

>
> On 12 January 2017 at 02:31, Charles Butler <charles.butler at canonical.com>
> 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 https://git.launchpad.net/
> layer-snap/tree/reactive/snap.py#n62 for an example.
>
>
-- 
Stuart Bishop <stuart.bishop at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170112/b1aad13e/attachment.html>