nginx.service specs differ from apt-get install

[fabianegli]

While preparing to compile nginx from source with this build script, I realized that there are some differences in the nginx.service file produced by it and the one I have from an installation with apt-get.

Since I am not quite familiar with these kind of files and the instruction they convey, I thought I ask. What is the rationale behind these differences?

From apt-get:

# Stop dance for nginx
# =======================
#
# ExecStop sends SIGSTOP (graceful stop) to the nginx process.
# If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control
# and sends SIGTERM (fast shutdown) to the main process.
# After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends
# SIGKILL to all the remaining processes in the process group (KillMode=mixed).
#
# nginx signals reference doc:
# http://nginx.org/en/docs/control.html
#
[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
TimeoutStopSec=5
KillMode=mixed

[Install]
WantedBy=multi-user.target

From nginx-build:

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/var/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

I guess that the -g part is created/modified by systemctl, but am not sure at all. I am especially wary about the ExecReload and ExecStop, since they seem to be radically different.

[MatthewVance]

Thanks for asking. These files are what systemd reads to understand how to manage the nginx process (start, stop, reload, etc.). So things related to syatemctl. The files do not impact how nginx is compiled. In fact, nginx can be built and manually run without these files and systemd. This script includes these service files for convenience. Feel free to remove or replace them with the apt-get version (a few changes would likely be necessary since where this build script puts some things is different for example). Systemd is quite complex and I'm certainly not an expert on it so I don't want to attempt explaining the differences in detail. Hopefully the above information is enough to ease your concern and give you sufficient background to research further.

…

On Wed, Feb 27, 2019, 1:54 PM Fabian Egli ***@***.***> wrote: While preparing to compile nginx from source with this build script, I realized that there are some differences in the nginx.service file produced by it and the one I have from an installation with apt-get. Since I am not quite familiar with these kind of files and the instruction they convey, I thought I ask. What is the rationale behind these differences? From apt-get: # Stop dance for nginx # ======================= # # ExecStop sends SIGSTOP (graceful stop) to the nginx process. # If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control # and sends SIGTERM (fast shutdown) to the main process. # After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends # SIGKILL to all the remaining processes in the process group (KillMode=mixed). # # nginx signals reference doc: # http://nginx.org/en/docs/control.html # [Unit] Description=A high performance web server and a reverse proxy server Documentation=man:nginx(8) After=network.target [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;' ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;' ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid TimeoutStopSec=5 KillMode=mixed [Install] WantedBy=multi-user.target From nginx-build: [Unit] Description=The NGINX HTTP and reverse proxy server After=syslog.target network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/var/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t ExecStart=/usr/sbin/nginx ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID PrivateTmp=true [Install] WantedBy=multi-user.target I guess that the -g part is created/modified by systemctl, but am not sure at all. I am especially wary about the ExecReload and ExecStop, since they seem to be radically different. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#71>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACjDupNm7_OcDhASB7Btk02Ap1jukxI_ks5vRuJ_gaJpZM4bVU7a> .

[MatthewVance]

Also, this article night help: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files

…

On Wed, Feb 27, 2019, 1:54 PM Fabian Egli ***@***.***> wrote: While preparing to compile nginx from source with this build script, I realized that there are some differences in the nginx.service file produced by it and the one I have from an installation with apt-get. Since I am not quite familiar with these kind of files and the instruction they convey, I thought I ask. What is the rationale behind these differences? From apt-get: # Stop dance for nginx # ======================= # # ExecStop sends SIGSTOP (graceful stop) to the nginx process. # If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control # and sends SIGTERM (fast shutdown) to the main process. # After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends # SIGKILL to all the remaining processes in the process group (KillMode=mixed). # # nginx signals reference doc: # http://nginx.org/en/docs/control.html # [Unit] Description=A high performance web server and a reverse proxy server Documentation=man:nginx(8) After=network.target [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;' ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;' ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid TimeoutStopSec=5 KillMode=mixed [Install] WantedBy=multi-user.target From nginx-build: [Unit] Description=The NGINX HTTP and reverse proxy server After=syslog.target network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/var/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t ExecStart=/usr/sbin/nginx ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID PrivateTmp=true [Install] WantedBy=multi-user.target I guess that the -g part is created/modified by systemctl, but am not sure at all. I am especially wary about the ExecReload and ExecStop, since they seem to be radically different. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#71>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACjDupNm7_OcDhASB7Btk02Ap1jukxI_ks5vRuJ_gaJpZM4bVU7a> .

[fabianegli]

Thank you for this response and the additional resources on the systemd. An interesting read, indeed!

However, my immediate question remains: Why do you use the kill command instead of the nginx -s reload in the ExecReload directive?

The use of kill in the systemd for ExecReload causes an unexpected behavior for nginx users. See: https://stackoverflow.com/a/13527535/6018688 (reload only if config checks out) and https://serverfault.com/a/378585/511536 (graceful hot replacement of nginx instance).

[fabianegli]

I was mistaken and my worries were of no substance. Sending signals to nginx seems to be one of the ways to trigger a reconfiguration: http://nginx.org/en/docs/control.html#reconfiguration (sig HUP for reload and sig QUIT for a graceful shutdown). I am sorry for the confusion I caused. This issue may be closed.

[MatthewVance]

No worries. Apologies for not fully understanding your main question. I'm certainly open to better ways of doing things when folks like you have good suggestions. Unfortunately, I don't even remember my rational for using one method over another. I likely just followed an example I came across because I'm no expert on unit files and would have stuck with what worked and made sense at the time. For what it's worth, I came across this earlier this morning: https://www.nginx.com/resources/wiki/start/topics/examples/systemd/ Based on this and some info you provided, it might be worth updating this script. What do you think?

…

On Fri, Mar 1, 2019, 10:07 AM Fabian Egli ***@***.***> wrote: I seems my worries were of no substance. Sending signals to nginx seems to be one of the ways to trigger a reconfiguration: http://nginx.org/en/docs/control.html#reconfiguration (sig HUP for reload and sig QUIT for a graceful shutdown). I am sorry for the confusion I caused. This issue may be closed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACjDumFD2csMiE4wWysYsokjL_wj_UDnks5vSVBYgaJpZM4bVU7a> .

[fabianegli]

I think it would be nice to update the reload part in the next iteration of this build script.

The use of the reload flag instead of the HUP signal is more descriptive and my guess is, that more people understand the reload syntax than the HUP (Just because it is used in all tutorials I came across and from the documentation page I had to click through two pages explaining reload and the other named signals before arriving at the command line description linked above that introduces HUP.) - even if it results in the same behavior.

[MatthewVance]

Good point.

I'm tempted to revise it further to be closer to this Caddy service file. However, I'm concerned the extra security hardening would make it less general purpose.

[fabianegli]

There are many options how to include that additional security information in the script. As you already mentioned, changing some of these parameters probably restrict some use cases out there. I see multiple ways to add this:

1. Add all the security possible: for (quite) sure not user friendly.
2. Add a link to the resource: probably most will ignore it.
3. Add an additional complete version of the service file that adds all the security and allow to switch between them.
4. Add all the security but comment it out by default and tell users to uncomment what they need (explicitly mention the comment character - it is not one that I see a lot in other places...).

I believe the last is the most streamlined and I favor it over the others. I think 2. in general is not a bad idea for people interested in further reading.

[MatthewVance]

Thanks for this. These are all valid options. I wanted to briefly write here to let you know I have not forgotten about this—I just have not made time to properly research and implement.

I am leaning towards number four. Number three is appealing also, but I am hesitant about it due to the its complexity.

[jellemdekker]

I am leaning towards number four. Number three is appealing also, but I am hesitant about it due to the its complexity.

This would be my reasoning too. Normally, I lean more towards making something secure by default and telling users when and how to lower that in case of problems, but in the Caddy service file you linked to I already noticed two options that can affect a lot of people negatively because they depend on the hardware, OS or user's preference: line 34 and 41.