[systemd-devel] Best way of configuring service

[Dan Tihelka]

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

Where those undefined are left for user to be able to override the 
configuration, since they MUST appear in the ExecStart= item which looks like:

ExecStart=/usr/bin/java -Dcc.install.dir=-Dcc.install.dir${cc.install.dir} -cp 
${cc.install.dir}/dist $cc.prop.item1 $cc.prop.item2 ... $cc.prop.item5
                        -jar cruisecontrol-launcher.jar  $cc.opt.item1 
$cc.opt.item2 ... $cc.opt.item5


In this way, the user should be able to customize everything in 
/etc/systemd/system/ configuration, simply re-defining the appropriate 
Environment definitions. 

However, there are two issues Iike to clarify:

1)
As you could see, one variable is used in two cases - particularly it is:

-Dcc.install.dir=-Dcc.install.dir${cc.install.dir} -cp ${cc.install.dir}/dist 

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).

So the question is: do I it right? Is the concept I have chosen correct?


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?

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)

Also, I have found the inability to resolve env definitions in other env 
definitions being quiet limiting (although I suppose that some others are 
complaining as well :-)) ).


So, I would like to ask you for your advice - what is the best way of handling 
those two issues? What do you recommend to daemon upstream developers?

It seems to me that the purpose of ENV variables is slightly bit different from 
using as constant definitions for ExecStart= command simplification (even shell 
does not export them unless explicitly told, doesn't it). Although I may be 
completely wrong.


Thank you and I wish you many happy system admins (anyway, I see systemd as 
the best init system with the highest potential). 

Best regards,
Dan