Debian run_dir should be in /var/run/nginx

[anarcat]

I am not sure if it's correct anywhere else, but at the very least on
Debian, the "run dir" is not /var/nginx, but /var/run/nginx. That
seems like a better default everywhere, but I'm just going to scratch
that itch for now.

Ideally, this would actually be in /run/nginx since that's the new
standard (and the default in the Debian package), but I suspect this
will not work properly in older Debian releases (e.g. 7) still marked
as supported here.

This is important because /var is a real, on-disk, filesystem while /var/run points to /run which is a tmpfs, and therefore much faster.

This is a WIP because I suspect tests will fail with just this naive commit, but gotta start the conversation somewhere.

[puppet-community-rangefinder]

nginx::params is a class

The enclosing module is declared in 11 of 577 indexed public Puppetfiles.

Breaking changes to this file MAY impact these modules (near match):

• braiins-wordpressnginx

---

These results were generated with Rangefinder, a tool that helps predict the downstream impact of breaking changes to elements used in Puppet modules. You can run this on the command line to get a full report.

Exact matches are those that we can positively identify via namespace and the declaring modules' metadata. Non-namespaced items, such as Puppet 3.x functions, will always be reported as near matches only.

[ekohl]

I also considered /run. If Debian 7 is still listed then we should drop it.

[anarcat]

I also considered /run. If Debian 7 is still listed then we should drop it.

agreed, but that seems like another ballgame completely.

[anarcat]

i've squashed this into a single commit, and this is ready for merge/review/etc. tests should pass now.

[anarcat]

i made #1359 to keep track of the other divergences remaining such as this one. there are three "critical" ones that might affect performance, and two needless changes that should probably be fixed as well. but the diff is pretty big even after those...

[anarcat]

note that this might make nginx servers stumble upon a bug where the server does not reboot correctly because /run/nginx doesn't exist on boot. this can be fixed with the following override file in etc/systemd/system/nginx.service.d/runtime.conf:

[Service]
RuntimeDirectory=nginx

I have filed this against the Debian package (#945551), but maybe it would be worth fixing in this module as well?

[smortex]

@anarcat the systemd override indeed helps, but the sub-directories are created with 0700 permissions by nginx, and the module change them to 0755 which notifies the service. When the service restart, the directories get removed and everything starts again: the configuration never converge to a stable state.

1. I feel like nginx is right and 0700 is more suitable than 0755 for these directories, I'd like to propose a fix.
2. Yet, with the default configuration, the web server is unable to start on Debian after a reboot and before Puppet is run, which looks really bad. @bastelfreak shouldn't we revert to use Debian's default directories?

[jonemo]

the web server is unable to start on Debian after a reboot and before Puppet is run

@anarcat @smortex I observed this behavior after upgrading to puppet-nginx 1.1.0 and after a few hours of investigation ended up here. I understand the conundrum of wanting to follow the Debian convention for paths and Nginx not being quite cooperative. Is there a suggested workaround, for the time being?

[anarcat]

@jonemo i did suggest a workaround in #1352 (comment)

i suggest someone motivated by this issue open at least a bug report describing the issue in the short term.

[mgurjanov-cti]

Hi, I faced this problem on Ubuntu bionic with Vagrant. First time Vagrant is run or provisioned puppet creates "/run/nginx/client_body_temp" folders, but when I halt vagrant and run it without provision option this folder is then missing as /run folder is tmpfs and therefore nginx fails to start.

[jonemo]

i suggest someone motivated by this issue open at least a bug report describing the issue in the short term.

@anarcat: The issue already exists in #1372. In order to have the entire conversation in one place, I added a lengthy comment to #1372 to summarize the discussion from this thread, show workarounds, and review paths forward I am aware of: #1372 (comment)