accesslog set to /dev/null broken in 19.4 #1157

Closed
jstasiak opened this Issue Dec 2, 2015 · 9 comments

Projects

None yet

3 participants

@jstasiak
jstasiak commented Dec 2, 2015

Why do I have accesslog file set to /dev/null? This seems to be the only sane way to get gunicorn to not print access log to stdout/stderr yet still send it to syslog (with accesslog file not set at all accesslog doesn't go to syslog, tested on 19.3 and 19.4).

This used to work in 19.3, d922df3 changed it.

Please let me know if it's expected for /dev/null to not work as accesslog file.

Edit:

The actual error:

Traceback (most recent call last):
  File "/env/bin/gunicorn", line 11, in <module>
    sys.exit(run())
  File "/env/lib/python2.7/site-packages/gunicorn/app/wsgiapp.py", line 74, in run
    WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run()
  File "/env/lib/python2.7/site-packages/gunicorn/app/base.py", line 192, in run
    super(Application, self).run()
  File "/env/lib/python2.7/site-packages/gunicorn/app/base.py", line 72, in run
    Arbiter(self).run()
  File "/env/lib/python2.7/site-packages/gunicorn/arbiter.py", line 61, in __init__
    self.setup(app)
  File "/env/lib/python2.7/site-packages/gunicorn/arbiter.py", line 94, in setup
    self.log = self.cfg.logger_class(app.cfg)
  File "/env/lib/python2.7/site-packages/gunicorn/glogging.py", line 178, in __init__
    self.setup(cfg)
  File "/env/lib/python2.7/site-packages/gunicorn/glogging.py", line 192, in setup
    fmt=logging.Formatter(self.access_fmt))
  File "/env/lib/python2.7/site-packages/gunicorn/glogging.py", line 341, in _set_handler
    os.chown(h.baseFilename, self.cfg.user, self.cfg.group)
OSError: [Errno 1] Operation not permitted: '/dev/null'

Edit 2: this is running as non-root user

@benoitc
Owner
benoitc commented Dec 4, 2015

but what are the permissions of /dev/null ? Normally anyone should have access to it...

[~] ls -fla /dev/null                                                                                           11:49:21
crw-rw-rw- 1 root 3, 2 Dec  4 11:49 /dev/null
@jstasiak
jstasiak commented Dec 4, 2015

Writing is fine, it's trying to chown it while running as a non-root user that's the issue.

@benoitc benoitc added the Bug label Dec 4, 2015
@benoitc
Owner
benoitc commented Dec 4, 2015

oh right. Actually I am thinking we should check if the user has enough permission to write on an existing file. I will make such changes tomorrow.

@benoitc benoitc modified the milestone: 19.4.2 Dec 6, 2015
@tilgovi tilgovi self-assigned this Dec 26, 2015
@tilgovi
Collaborator
tilgovi commented Dec 26, 2015

Okay, there are actually two issues described here:

  • gunicorn chokes if --access-logfile is set and the user doesn't have permission
  • the --access-logfile option is needed to get access logs into syslog

While the title describes the first of these, I think that's not actually an issue. I believe should fail to start if it cannot open the access log.

If we fix the second issue, then there is no need to pass /dev/null to enable the access logging in syslog. I have placed this fix on a branch for review: https://github.com/benoitc/gunicorn/compare/1157-access-syslog?expand=1

@benoitc
Owner
benoitc commented Dec 27, 2015

@tilgovi just commented your fix. Let's merge it, then check if we still need some action there.

@tilgovi
Collaborator
tilgovi commented Dec 27, 2015

Done in 2f8e750

@jstasiak

Thank you @tilgovi and @benoitc, this does indeed fix the "the --access-logfile option is needed to get access logs into syslog" issue.

I'm still somewhat of an opinion that setting a log file to /dev/null (or any other file that an application can write to but can't chown) should work regardless but I'll leave it to you to decide whether to close this issue.

@benoitc benoitc added a commit that referenced this issue Dec 28, 2015
@benoitc check auth before trying to own a file
fix #1157
a2e9310
@benoitc benoitc added a commit that referenced this issue Dec 28, 2015
@benoitc check auth before trying to own a file
fix #1157
c805bd2
@benoitc
Owner
benoitc commented Dec 28, 2015

@jstasiak check #1167 it should fix this issue. Let me know

@benoitc benoitc closed this in #1167 Dec 28, 2015
@jstasiak
jstasiak commented Jan 6, 2016

Thank you @tilgovi and @benoitc, the issue is resolved!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment