systemd scripts completely ignoring /etc/default/{{package-name}}

[timcharper]

The package is including the file, and SystemV scripts properly reference it, but the SystemD template is completely ignoring it.

Perhaps it should set the EnvironmentFile EnvironmentFile directive?

Similar to Environment= but reads the environment variables from a text file. The text file should contain new-line-separated variable assignments. Empty lines, lines without an "=" separator, or lines starting with ; or # will be ignored, which may be used for commenting. A line ending with a backslash will be concatenated with the following one, allowing multiline variable definitions. The parser strips leading and trailing whitespace from the values of assignments, unless you use double quotes (").

The argument passed should be an absolute filename or wildcard expression, optionally prefixed with "-", which indicates that if the file does not exist, it will not be read and no error or warning message is logged. This option may be specified more than once in which case all specified files are read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments have no effect.

The files listed with this directive will be read shortly before the process is executed (more specifically, after all processes from a previous unit state terminated. This means you can generate these files in one unit state, and read it with this option in the next).

Settings from these files override settings made with Environment=. If the same variable is set twice from these files, the files will be read in the order they are specified and the later setting will override the earlier setting.

I'm not sure what the drawbacks are. Seems like some people prefer /etc/sysconfig, and others prefer just adding service.d files.

¯_(ツ)_/¯

[muuki88]

Thanks for the good research. First you are right SystemV does properly reference it. That's because the SystemV script is provided by native-packager and we added the environment configuration there. So it has nothing to do with the location of your service.conf file ( or at least I think so ).

Which brings me to Systemds Environment setting. We should integrate this setting into our systemd config as we did for SystemV. Adding the ${{env_config}} setting to the SystemD definition should be pretty simple. Would you like to make a PR for this?

[timcharper]

@muuki88 you bet! Thanks for this plugin!

I'd be happy to make a PR, too. I just wanted to discuss the right solution before laying down some code.

I was trying to read the differences between /etc/sysconfig and /etc/default, and get the impression that there's no necessary difference between the two. So, keeping /etc/default for SystemD seems as fine as any.

However, if we do want to source environment variables from /etc/default when using SystemD, then I think we should use a different template, as the environment variable file is interpreted differently. (for example, namely, you cannot embed values of other environment variables inside of strings as you can with SystemV / bourne interpreted configuration files.

Maybe something like this (although we would create a new template, not modify the existing)

diff --git a/src/main/resources/com/typesafe/sbt/packager/archetypes/etc-default-template b/src/main/resources/com/typesafe/sbt/packager/archetypes/etc-default-template
index 4239217..659b06f 100644
--- a/src/main/resources/com/typesafe/sbt/packager/archetypes/etc-default-template
+++ b/src/main/resources/com/typesafe/sbt/packager/archetypes/etc-default-template-systemd
@@ -18,15 +18,13 @@
 # ${{daemon_user}}     daemon user
 # -------------------------------------------------

+# This file is source by SystemD, and is not interpretted by the Bourne Shell
+# Interpretter.
+
 # Setting JAVA_OPTS
 # -----------------
-# JAVA_OPTS="-Dpidfile.path=/var/run/${{app_name}}/play.pid $JAVA_OPTS"
+# JAVA_OPTS="-Dpidfile.path=/var/run/${{app_name}}/play.pid"

 # Setting PIDFILE
 # ---------------
 # PIDFILE="/var/run/${{app_name}}/play.pid"
-
-# export env vars for 3rd party libs
-# ----------------------------------
-# COMPANY_API_KEY=123abc
-# export COMPANY_API_KEY

[muuki88]

the environment variable file is interpreted differently

Oh, that's interesting. This would indeed require a new template. In your diff I see that you also removed the example to export variables. Do you have a good documentation where all these differences are listed up?

I was trying to read the differences between /etc/sysconfig and /etc/default, and get the impression that there's no necessary difference between the two

It seems there are a few difference depending on the OS where SystemD files should be put. However until now we didn't get any feedback that some hasn't actually not worked. Only that "it's not best practice to put x in y on OS z"

[timcharper]

My original comment quotes the section from the man page in which the EnvironmentFile directive is described, the first paragraph of which describes the format the referenced config file should follow. Perhaps we can direct users to reference the appropriate man page if they've any questions; specifically, man systemd.exec.

[muuki88]

Yes, I found it. From my side everything is clear on how things should work. Do you have any questions?

[timcharper]

I think it's clear for me, too. Plan is to create a SystemD specific environment file template, modify the comments to make it appropriate for SystemD (with instructions to see man systemd.exec for instructions on what's valid syntax), and then have the service refer to that file. I'll get it put together!

[timcharper]

starting work on this now

[el-dom]

@timcharper I've just seen your contribution to this project. Awesome work! It"s exactly what i need right now.
One question though. Did you really mean to comment every single line in etc-default-systemd-template? Currently the file gets included by the systemd unit, but everything in it will be ignored.

[timcharper]

Yes, that is the intention