[systemd-devel] Best way of configuring service

[Lennart Poettering]

On Sun, 23.09.12 23:04, Dan Tihelka (dtihelka at gmail.com) wrote:

> Dear all,
> I porting the start scripts of cruisecontrol system to the native systemd 
> service configuration. It goes quiet well, the only "trouble" I have with the 
> options configuration.
> 
> Since cruisecontrol is written in Java, there are two ways of how to configure 
> the daemon (and CC use them both): -D java properties and "classic" command 
> line options passed to the main jar.
> 
> I want to have the whole service highly configurable, So I have decided to 
> define Environment= item for each particular option. The result looks like:
> 
> Environment=cc.prop.item1="-Dcc.XXX=value1"
> Environment=cc.prop.item2="-Dcc.XXX=value1"
> Environment=cc.prop.item3="-Dcc.XXX=value1"
> Environment=cc.prop.item4=
> Environment=cc.prop.item5=
> 
> Environment=cc.opt.item1=-opt1 val1
> Environment=cc.opt.item2=-opt2 val2
> Environment=cc.opt.item3=-opt3 val3
> Environment=cc.opt.item4=
> Environment=cc.opt.item4=
> 
> Environment=cc.install.dir=/usr/shared/cruisecontrol

Hmm, so systemd unit files are not really supposed to the place where
daemon-specific configuration bits are encoded. If a daemon requires
specific configuration my recommendation is always to introduce a proper
configuaration file for it, and not to encode this via env vars or in
the cmdline. Administrators will thank you for it!

> I have observed that the env must be used in form ${XXX} when it is the part 
> of larger string (despite the form ${XXX} having its "special"
> meaning).

Yes, please see the documentation for this in the section about
ExecStart= in systemd.service(5)

> 2)
> The second issue is that (if I understand it right) everything I define by 
> Environment= will appear in ENV variables of the process started. Is
> is true?

Yes, as the name suggests env vars specified in "Evironment=" actually
do change the environment.

> What If I don't want to export those variables to the service? I would guess 
> that it is the reason why -D properties are used instead of "raw" ENV 
> variables (which could simply be used as well)

systemd unit files are not supposed to be a macro engine, or a
programming language. My recommendation would be to fix the daemon to
read a normal configuration file natively and if that's ot possible just
wrap it in a normal shell script, rather then tryig to hammer unit files
into what you need here.

I mean, I do understand your needs, but we deliberately try to keep unit
files simple and devoid of any programming language antics. Because we
already have a pretty good one for these kinds of thigs, if that's what
you need, and that's shell.

I hope this is understandable,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.