I have this service defined in
[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:
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
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.