[lug] Environment variable expansion in systemd service files
riddochc at gmail.com
Tue Feb 28 17:16:09 MST 2017
Yeah, it seems like the simplest thing to do is just to generate a file.
Brennan's idea seems appropriate if some of the variables weren't known
until the service is about to start. Modifying an EnvironmentFile would
hopefully not require a daemon-reload.
Zan, I had kind of expected that variables would be defined in the order
they're seen in the file, and would be available for use in future
definitions of other variables. But you're certainly right that expecting
any other kind of dependency resolution might be way more complicated than
it's worth. ...on the other hand, systemd already has functions for
dependency resolution, since there's Before and After and Wants and things
of that sort to decide what order to start services in.
I settled on just accepting the duplication anyway.
Thanks, you all.
On Mon, Feb 27, 2017 at 9:59 AM, Zan Lynx <zlynx at acm.org> wrote:
> On February 27, 2017 9:46:37 AM MST, Brennen Bearnes <bbearnes at gmail.com>
> >On Sun, Feb 26, 2017 at 8:15 PM, Chris Riddoch <riddochc at gmail.com>
> >> I've been trying to figure out how to accomplish something in systemd
> >> service configuration files, I hope maybe someone else has tried to
> >> something similar before and recognizes this.
> >I suspect that you may need to do something like described here:
> >...and define a separate unit file to dynamically create something you
> >feed to EnvironmentFile.
> >This seems silly, so hopefully someone will tell me I'm wrong.
> When you consider how many ways there are to write unit file fragments you
> realize that variable processing wouldn't work. What order would it run in?
> So embrace the duplication or use the variable in an exec string, or write
> a generator unit to build an environment for you.
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LUG