Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm running nginx on a MacOS X machine, installed with brew, and when I launch nginx, even with sudo, I get the following warning in my log file over and over again:

4/21/11 2:03:42 AM  org.nginx[3788] nginx: [warn] the "user" directive
makes sense only if the master process runs with super-user privileges,
ignored in /usr/local/etc/nginx/conf/nginx.conf:2

From nginx.conf:

user  jschuur staff;

I'm already launching nginx with sudo, since I want the thing to listen on port 80. Shouldn't that be enough to give it the proper super user privileges?

The nginx binary as it's installed:

jschuur@Glenna:sbin → master ls -la
total 4544
drwxr-xr-x   3 jschuur  staff      102 Apr 12 20:53 .
drwxrwxr-x  15 jschuur  staff      510 Apr 12 15:25 ..
-rwxr-xr-x   1 jschuur  staff  2325648 Apr 12 20:39 nginx

FWIW, I recompiled the binary to set passenger up and moved it around from it's original location into /usr/local/sbin.

Update: As it turns out MacOS X was restarting nginx after I'd stopped it, because the launchd plist in ~/Library/LaunchAgents had set it to 'KeepAlive'. However, because I installed this plist into my local user's LaunchAgents folder as opposed to /Library/LaunchAgents (or better yet /Library/LaunchDaemons, which run before you even log on), it wasn't executed as root. Because of an error about not having permissions to use port 80, it actually exited right away, but still wrote to the same log file as the nginx process I started with sudo. I had thought the errors stemming from the automatic restart were actually coming from my manual restart via sudo.

So, bottom line, problem solved. The real problem here was the homebrew instructions specifically asking you to install the plist file into an area that wouldn't allow a local site to use port 80.

share|improve this question

1 Answer 1

You should check wherever sudo id command shows uid = 0

share|improve this answer
    
'sudo id' definitely returns a UID of 0 for me. Are there cases where it wouldn't? Or were you referring to looking at the source? I see a 'if (geteuid() != 0)' call before the warning in question, but the effective user ID should be 0 here. –  Joost Schuur Apr 21 '11 at 17:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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