[systemd-devel] Best way of configuring service

[Daniel Tihelka]

On 9/24/12, Lennart Poettering <lennart at poettering.net> wrote:
> 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!
>

OK, thanks. I will try to change cruisecontrol in this way.

But still, there are java-specific options which must be set (and may
be required to be customized) as well - for example the -Xmx or -Xms
settings. And I am most likely not able to change it in java :-)

So, how to handle those? Yes, it can (rather simply) be done through
shell wrapper, but my intention was to try to avoid it (well, it was
motivated by the aim of systemd anyway - to get rid off shell scripts
from boot sequence). On the other hand, I understand that you don't
want to create a mega-features-everything-capable-shell-replacement
...

Anyway, one more ask - I have filled feature request at
https://bugs.freedesktop.org/show_bug.cgi?id=55163

Do you think that it is doable or completely useless? Where to look in
systemd code to implement this?

Thank you,
Dan

>> 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.
>
> --
> Lennart Poettering - Red Hat, Inc.
>