New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Insufficient LogDir Permissions #539

Closed
nikolay opened this Issue Oct 14, 2013 · 10 comments

Comments

Projects
None yet
5 participants
@nikolay
Copy link
Contributor

nikolay commented Oct 14, 2013

When I navigate to the console at /pagespeed_console all you see is:

PageSpeed Console
Notable issues:

When I look into the JavaScript console, I see an error at line 211:

XHR request failed. pagespeed_console:211
V pagespeed_console:211
d.onreadystatechange pagespeed_console:214
@jeffkaufman

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Oct 14, 2013

/pagespeed_console depends on making an XHR to get /ngx_pagespeed_statistics. Do you have nginx set up to allow you access to /pagespeed_console but not /ngx_pagespeed_statistics?

@nikolay

This comment has been minimized.

Copy link
Contributor

nikolay commented Oct 14, 2013

Yes, both are allowed and work when I navigate to them in the browser.

@jeffkaufman

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Oct 21, 2013

This error came up a second time on the mailing list:

I have a server on amazon, with ngx_pagespeed enabled.  ngx_message_statistics works fine, but /pagespeed_console always gives me an error : XHR request failed. 

Here's my config file:       

server {
        listen       80;
        server_name  localhost;
pagespeed on;
        pagespeed RespectVary on;
        pagespeed Statistics on;
        pagespeed StatisticsLogging on;
        pagespeed LogDir /var/log/pagespeed;
        pagespeed LowercaseHtmlNames on;
        pagespeed EnableFilters rewrite_css,rewrite_javascript,extend_cache,extend_cache_pdfs,inline_preview_images,resize_mobile_images,rewrite_images,remove_quotes,insert_dns_prefetch,convert_meta_tags,canonicalize_javascript_libraries,add_instrumentation;

 location /ngx_pagespeed_statistics {
        # One may insert other "allow" lines to add hosts that are
        # allowed to look at generated statistics.  Another possibility is
        # to comment out the "allow" and "deny" options from the config
        # file, to allow any client that can reach the server to examine
        # statistics.  This might be appropriate in an experimental setup or
        # if the Nginx server is protected by a reverse proxy that will
        # filter URLs to avoid exposing these statistics, which may
        # reveal site metrics that should not be shared otherwise.
        allow 127.0.0.1;
        deny all;
    }
    # Recent log messages. Like statistics, these are generally not to be shown
    # to the public, so this has access controls as well.
    pagespeed MessageBufferSize 100000;
    location /ngx_pagespeed_message {
        allow 127.0.0.1;
        deny all;
    }

    # This page lets you view a graphical console displaying statistics about
    # the ngx_pagespeed module.  As with statistics and messages, you may
    # want access control.
    location /pagespeed_console {
               allow 127.0.0.1;
              deny all;
    }
}

I just can't figure out why the console won't work.
@jlporter

This comment has been minimized.

Copy link
Contributor

jlporter commented Oct 21, 2013

I'm seeing the same problem on my site. It looks like the stats are being updated, but not being written to the stats_log_global file in the directory specified by LogDir. I see the following errors in my nginx error_log when accessing /pagespeed_console:

2013/10/21 16:01:51 [error] 11096#0: [ngx_pagespeed 1.6.29.3-3270] /var/log/pagespeed/stats_log_global:0:opening input file: No such file or directory
2013/10/21 16:01:52 [alert] 16230#0: worker process 11096 exited on signal 11 (core dumped)
2013/10/21 16:01:52 [error] 11173#0: [ngx_pagespeed 1.6.29.3-3270] /var/log/pagespeed/stats_log_global:0:opening input file: No such file or directory
2013/10/21 16:01:52 [alert] 16230#0: worker process 11173 exited on signal 11 (core dumped)
2013/10/21 16:02:10 [error] 11176#0: [ngx_pagespeed 1.6.29.3-3270] /var/log/pagespeed/stats_log_global:0:opening output file: Permission denied
2013/10/21 16:02:10 [error] 11176#0: [ngx_pagespeed 1.6.29.3-3270] Error opening statistics log file /var/log/pagespeed/stats_log_global.
@oschaaf

This comment has been minimized.

Copy link
Member

oschaaf commented Oct 21, 2013

@jlporter @jeffkaufman
Looking closer, the files end up with ':' in their filenames, could that have something to do with it?
Also, ':' in a filename has a special meaning on Windows.
To be safe with filenames, I think it would be good to only use alphanumeric characters and '_'?

@jlporter

This comment has been minimized.

Copy link
Contributor

jlporter commented Oct 21, 2013

I think the ':' is just an artifact of the logging.

Debugging some with @jeffkaufman, it appears to be a permissions issue with the directory specified by LogDir. ngx_pagespeed is trying to read/write that directory with the permissions of the worker process, instead of the master process. You can work around this by making sure that the LogDir directory has read/write permissions for the worker process user (nobody by default, and ensuring that all the directories in the path also grant read and execute permissions), but what it looks like we should be doing is opening that directory in the master process and passing a file handle to the worker.

@mwq27

This comment has been minimized.

Copy link

mwq27 commented Oct 22, 2013

I will try changing the permissions of the LogDir and see if that helps.

Thanks jlporter

@jeffkaufman

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Oct 22, 2013

what it looks like we should be doing is opening that directory in the master process and passing a file handle to the worker.

I think we may also not be doing this with the FileCachePath. I'll write a change to do both.

@jeffkaufman

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Oct 22, 2013

In the Apache version there's an init_dir function that handles this.

@mwq27

This comment has been minimized.

Copy link

mwq27 commented Oct 22, 2013

Changing the file permissions on the LogDir worked. I set them to 777 (I'm not sure if that's the best option) and the graphs are finally showing up :)

On Oct 22, 2013, at 8:58 AM, Jeff Kaufman notifications@github.com wrote:

what it looks like we should be doing is opening that directory in the master process and passing a file handle to the worker.

I think we may also not be doing this with the FileCachePath. I'll write a change to do both.


Reply to this email directly or view it on GitHub.

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