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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel