[systemd-devel] Best way of configuring service

[Colin Guthrie]

'Twas brillig, and Malte Starostik at 24/09/12 22:52 did gyre and gimble:
> Hi Dan,
> 
> Am Montag, 24. September 2012, 21:58:17 schrieb Daniel Tihelka:
>> On 9/24/12, Lennart Poettering <lennart at poettering.net> wrote:
> 
>>> 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
>> ...
> 
> True, true...but a shell script doesn't *have* to be as ugly as what comes 
> with some widely used java frameworks and contain like 2k LOC of the most 
> abominable shell code history has seen just to collect what ends up in a bunch 
> of env vars and options to the java binary - of which the location is first 
> determined via large parts of this wrapper...
> 
> Actually I think it's a bug in the JRE if things can only be configured on the 
> command line and not via a (possibly JAR-specific) config file...
> anyway, this seems like be one of the few cases where EnvironmentFile= might 
> be the best solution.  As opposed to Environment= this makes it very easy for 
> the user to override some settings.
> You could e.g. run java ... $JAVA_OPTS together with EnvironmentFile=-... (not 
> teh minus) so the file doesn't even have to exist, but iff the user wants/needs 
> to tweak memory options, it's only a matter of adding e.g. JAVA_OPTS="-Xms... 
> -Xmx..." to the env file.  With Environment=... you require the user to 
> overwrite the whole unit instead.

Well, you can use Environment= and EnvironmentFile=- in combination
here. Set the default JAVA_OPTS with Environment= (assuming the values
really are specific to this service) and then allow the user to
optionally override them via the EnvironmentFile all without having to
copy/edit the unit itself.

I'm not really a java guru, but is it common that some JAVA_OPTS might
be valid for multiple, different services? If so, then it would be worth
defining a "central" (i.e. not service specific) EnvironmentFile that is
sourced for all java services (e.g. /etc/sysconfig/java) but still allow
a service specific env file to override it (e.g.
/etc/sysconfig/myservice). In this case you'd just specificy two
EnvironmentFile=- lines in the unit. This might or might not make sense
as I said, so feel free to come to your own conclusions here.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/