'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 <[email protected]> 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/ _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
