3

I have this service defined in /etc/systemd/system/gunicorn-production.service:

[Unit]
Description=gunicorn production daemon
After=network.target

[Service]
PIDFile=/run/gunicorn_production/pid
User=www-data
Group=www-data
RuntimeDirectory=gunicorn_production
WorkingDirectory=/home/production/current
Environment=WORKERS='2'
ExecStart=/home/production/.virtualenvs/production/bin/gunicorn \
-w $WORKERS \
...
# rest of gunicorn configuration parameters

The service starts/reloads/stops etc. with the specified 2 workers.

I was going to move all of the hardcoded paths into a configuration file so I can reuse this service definition and I started with defining WORKERS in a file in the "drop in" directory: /etc/systemd/system/gunicorn-production.d/gunicorn-production.conf:

[Service]
Environment=WORKERS='4'

If I systemctl daemon-reload and then systemctl restart gunicorn-production the configuration for 4 workers doesn't take affect. I've tried various configuration/filename permutations but can't seem to override the environment setting via the .conf file.

According to the man page systemd.units it looks like a "drop in" directory should do the trick:

Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Each drop-in file must have appropriate section headers. Note that for instantiated units, this logic will first look for the instance ".d/" subdirectory and read its ".conf" files, followed by the template ".d/" subdirectory and the ".conf" files there. Also note that settings from the "[Install]" section are not honoured in drop-in unit files, and have no effect.

2

I named the drop-in directory incorrectly. I named it: /etc/systemd/system/gunicorn-production.d when it should have been: /etc/systemd/system/gunicorn-production.service.d. Once I fixed that the new Environment value was used.

1

Set the environment to empty first (In theory this should reset the variable) and then set it to 4.

[Service]
Environment=
Environment=WORKERS='4'

I am not sure if it will work but this is the way to go to reset a systemd unit file token with a drop-in file.

1
  • Thanks @Umut for looking in to this. It turns out that isn't necessary. I named the drop-in directory incorrectly. I named it: /etc/systemd/system/gunicorn-production.d when it should have been: /etc/systemd/system/gunicorn-production.service.d. Once I fixed that the new Environment value was used and I didn't have to reset the variable. – saschwarz Sep 12 '16 at 11:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.