Change:
"--enable-add-ons" "--sysconfdir=/etc" "--localedir=/var/run/current-system/sw/lib/locale" <ins> "libc_cv_ssp=no" </ins> (if kernelHeaders != null then "--with-headers=${kernelHeaders}/include" else "--without-headers")

Discussion:
causes an error Consider this flake: Build the system closure with A new slice-unit is created. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
This issue can be closed now

PR broke -- first discovered in Before that PR, the systemd service ran as , so the nginx master process ran as root, and then the worker processes ran as an unprivileged user ( , or by default if thta line is not given). Now the systemd service runs as , including the master process. When you change the default back to root (e.g. because your setup needs the master process to be root, or for replicate the setup as it was in 19.09) using , it does not work out of the box. That is because the module now assumes that nginx will run only as 1 user, and it sets file system permissions that way. But nginx running as root makes nginx drop privileges to or the configured , and the file system permissions are not set up correctly for that as shown in
FYI this is how I'm handling the situation with : The sysadmin should override and to set the master process user and group, while the and options set the effective user and group.
The way the tmpfile rules are currently written is that the group doesn't have write, only read access to . So it doesn't really work well with running the nginx master process as root, and then drop permissions to a regular user. I assume you also don't want to run worker processes as root either :laughing:… I'm not sure how to properly approach this problem. Can you elaborate a bit on what's your usecase as running the master process as root?
are you able to test this configuration out and report back: Please take special consideration to look over your directory (under ) and the permissions there. I'm not familiar on what user/group permissions the process assigns to log files when it runs with as the master process... possibly a minor tweak to the will be required, but let me know what happens with your test. If this works we need to simply add documentation on how to run with as the master process, as I have explained above.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Just from the go/no-go meeting, I approved of changes being backported to 20.03
I've gone ahead and tested the above configuration snippet.

I had to make a few tweaks and ended up with this as the required configuration to get to run with as the master process but as the child processes: can you please describe your requirement to run the master process as ? I'm not familiar with so I have a hard time judging whether your case is an edge case or not. depending on the answer from we need to make a decision about whether we need to simply improve documentation, or improve documentation and modify the module code to make this use case better supported. I'm currently leaning toward this being a documentation only thing, but let's wait to hear what has to say.
I think your suggestion is good, I will try it today for our setup and report back. If it works, then I agree that it is sufficient to document your approach in the release notes (and perhaps as a description in one of the config options (probably the one for is best). On my use case, it is: being able to configure nginx the same way it was running on 19.09 for smoother migration, also so that one can upgrade to 20.03 already before fixing all the other things one's nginx uses that may rely on the master running as root
NixOS does not complain when options on non-existent systemd services are set (should it?) -- that took a while to figure out :grin:
I have checked your approach now on my staging deployment; it works (with the typo removed). What we should add to the changelog:
glad to hear. Thanks! :tada:
PR: We should cherry-pick it on after merge.
Thanks for finding the best solution!

In NixOS VM tests, service sometimes fails to start. This breaks e.g. GlusterFS tests. Steps to reproduce the behavior: Building — GlusterFS service fails due to dependency on RPC Bind service. See also Some result related to GlusterFS. Have not yet had time to bisect and determine what's going on.
Hey, I started down this path looking for an updated Glusterfs package, then found the paused PR, which linked here. Fortunately, I think I know the root cause. As you noted, the failure is due to a dependency failure on - the error message in journald is: This was sort of confusing, but I found that led me to . The NixOS config includes: L /var/run - - - - ../run So my suspicion is that starts before and can't check for the lockfile. Since there's no unit, which was my first guess, I've instead been adding and tied to , which makes the tests pass. The diff that makes this work is: Obviously we should probably make this fix in NixOS proper, but I want to double-check with you that such a wider-impact change is safe to make. The proposed global_ fix for NixOS would be: thoughts/feedback? I can PR the fix if this all sounds right.
The real problem is that I am competent about neither rpcbind nor systemd-tmpfiles (otherwise I would try to write a more sensible complaint). Maybe PR the change (if it indeed fixes rpcbind judging from logs + fixes GlusterFS tests + doesn't break any NixOS tests that passed right before) and see if more competent people show up? It does feel to me that ideally tmpfiles should not depend on rpcbind and if they do (dunno, because we have /tmp on GlusterFS???) we are doomed anyway…
You and I are in the same boat, friend :joy: I'm only rpcbind-aware as it applies to GlusterFS, so I don't count myself as an expert, either. The only reason I feel confident enough to PR a fix is that all the pieces line up here and the passing tests make me think that this does indeed strike at the root cause.

If NixOS is shipping with that tmpfiles configuration to bootstrap , then I think it makes sense for the downstream NixOS module to accomodate how NixOS is handling . So my initial instinct of patching upstream probably doesn't apply since distros are probably handling differently. I'll PR the change and we can see about additional feedback for us.
I'm feeling pretty confident that fixed the rpcbind problem - are there any nixosTests that should be re-enabled now that rpcbind reliably runs? I looked around for disabled tests but am not sure where those might live, if any are still disabled. Otherwise, I think we can close this :crossed_fingers:
(looked at the tests, doesn't look like there is a ton of disabled ones)

, CVSSv3=7.5 (nixos-unstable) Scanned versions: nixos-unstable: . Cc

In and it is described that to get working on a Linux kernel build, you should do: Inside that shell though, to build the kernel breaks with . Removing from the list fixes the issue. Why is that happening? If we can't fix it, we should at least update the wiki and manual. Full repro with and nixpkgs commit :
Seems to be caused by this change in the kernel: With this recent change, the kernel tries to use to find include and library flags for libelf, and fails back to the old behavior of assuming it's available in the default include/library directories. Running within shows something like: . These are flags so the compiler does not treat them like system includes and does not inhibit warnings from these headers. Making available makes the kernel use those flags, so libelf is included normally, leading to the warning and error, presumably because some kernel makefile adds to compiler flags. Without available, the libelf headers are found through include paths automatically by which are flags so warnings from those headers are ignored. I see different ways to fix this: Patch the libelf file to use instead of . Patch libelf headers to not produce those warnings. Patch the kernel to disable those warnings before including libelf (and re-enable). Any opinions?
is it normal for libelf headers to generate these warnings ? isn't that an upstream issue in some way ? I would vote for 2 ("fix libelf headers") since other approaches have their downsides: patching libelf's .pc may hide warnings for normal packages as I sometimes develop on the kernel, the more we patch its sourcecode, the more annoyed I get (pollutes git status etc.)
I'd agree that it's an upstream bug. Ran into this on my Gentoo system earlier, noticed something about those headers, and figured I'd chime in: they should be using instead of Relatively simple change, should fix the problem entirely. Edit: I'll try to send a patch upstream tomorrow or Friday. Uh, that is, today or Friday. It's past midnight. Oops.