Adv CSS/JS Agg - Asynchronous Mode Set to FALSE [#1384062]

I get this in the status report:

"Adv CSS/JS Agg - Asynchronous Mode Set to FALSE.
Check to see if you have fast 404s, if so create an exception for this module. The readme file explains what needs to be changed. You can try flushing the menu cache as well. If you are still having issues you can go to the AdvAgg information tab and select Asynchronous debug info. If creating an issue on d.o be sure to include this information ."

And this in "Asynchronous debug info":
http://75.126.157.208/sites/default/files/advagg_css/css_missing18617909...
stdClass Object (
[request] => GET /sites/default/files/advagg_css/css_missing18617909461324777587_0.css HTTP/1.0
Host: menaspecialneeds.com
User-Agent: Drupal (+http://drupal.org/)
Connection: close

[data] => "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Authentication required | MENA Special Needs

Enter your user name and password:

User name:

Password:

Password reset

Enter your user name or e-mail address:

User name or e-mail address:

[protocol] => HTTP/1.1
[status_message] => OK
[headers] => Array (
[Date] => Sun, 25 Dec 2011 01:46:27 GMT
[Server] => Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_jk/1.2.30
[Set-Cookie] => SESScbeae40b5992a077bf79d386a5756a19=b677699d917e7b19adcf27882f03ede1; expires=Tue, 17-Jan-2012 05:19:47 GMT; path=/; domain=.menaspecialneeds.com
[Vary] => Accept-Encoding
[Connection] => close
[Content-Type] => text/html; charset=utf-8
)

Comment	File	Size	Author
#16	status.png	57.77 KB	tangent

Comments

Comment #1

mikeytown2 commented 29 December 2011 at 20:04

Component:	CSS Compression	» Code
Assigned:	Ahyari	» Unassigned

Something is intercepting calls to the CSS/JS missing file generator. Looks like you have a module that requires one to be logged in to access anything. Is there an exception list?

Does imagecache work on your setup?

Comment #2

asb commented 12 January 2012 at 01:16

I have a similar issue - on one site, the setting "Generate CSS/JS files on request (async mode)" shows no "Current State". Running advagg-6.x-1.x-dev

On the "Asynchronous debug info" I'm getting this snippet:

stdClass Object (
    [request] => GET /sites/default/files/advagg_css/css_missing7416261421326329872_0.css HTTP/1.0
...
Connection: close

    [data] => <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /sites/default/files/advagg_css/css_missing7416261421326329872_0.css
on this server.</p>
...
    [error] => Forbidden
    [code] => 403
    [timer] => Array (
            [count] => 1
            [time] => 1.68
        )
)

I can not make sense out of this since this folde is as readable as it gets:

drwxrwxrwx  2 www-data www-data 4,0K 12. Jan 01:51 advagg_css
drwxrwxrwx  2 www-data www-data 4,0K 12. Jan 01:59 advagg_js

Any ideas what it means if "Generate CSS/JS files on request (async mode)" does not show any state?

Currently I have enabled:

AdvAgg CDN Javascript
AdvAgg Compress Javascript
Advanced CSS/JS Aggregation

As soon as I enable "AdvAgg Bundler" and "AdvAgg Compress CSS", the site's CSS crashes completely, including admin pages. To get CSS on normal pages, I have to disable advagg completely.

Thanks!

Comment #3

mikeytown2 commented 12 January 2012 at 01:21

@asb
In your case it looks like something above Drupal (Apache) is restricting access to that directory. Also if you enable the bundler, it should work. CSS compression takes a long time and if ASYNC is not working it will slow down that page's render time until that CSS file has been generated; slowing it down so much that PHP might time out.

Comment #4

asb commented 12 January 2012 at 15:24

Title:

Adv CSS/JS Agg - Asynchronous Mode Set to FALSE

» Adv CSS/JS Agg - Asynchronous Mode Set to FALSE

"Generate CSS/JS files on request (async mode)" can not show a state because something else thinks not to be be able to access a "files" directory? OK, this "something" can write stuff into the "advagg_css" directory:

# ls sites/default/files/advagg_css
css_038b8dd2efa98cbe3b92ec04c6bf2054_0.css
...

If I load this file into the browser, I'm getting an "access denied":

# wget http://mysite.org/sites/default/files/advagg_css/css_038b8dd2efa98cbe3b92ec04c6bf2054_0.css
...
HTTP-Anforderung gesendet, warte auf Antwort... 403 Forbidden
2012-01-12 15:44:15 ERROR 403: Forbidden.
...
You don't have permission to access /sites/default/files/advagg_css/css_038b8dd2efa98cbe3b92ec04c6bf2054_0.css on this server.

So "something" - Apache, PHP, operating system, whatever - successfully prevents access to a directory that is supposed to be fully readable for the webserver user & group (www-data:www-data).

This is bloody awesome as I don't have the faintest idea what this access blocker might be. Neither the Apache host configuration nor the .htaccess file in Drupal's root folder of this site differs in a significant way from the other configurations I'm running on this server :-(

And it gets even better, from Apache's error log:

[Thu Jan 12 16:00:09 2012] [error] [client 176.31.224.179] Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden: /var/www/.../sites/default/files/advagg_css/css_038b8dd2efa98cbe3b92ec04c6bf2054_0.css

I'm getting these errors on one host only, but all Indexes/FollowSymLinks/MultiViews directives I can find are identical on all 15 (Drupal) sites running on this server :-(

Looks like advagg has hidden capabilities to expose borked server setups ;)

Comment #5

asb commented 16 January 2012 at 16:17

@mikeytown2 (#3):

Also if you enable the bundler, it should work.

I retried this and had the same effect. "AdvAgg Bundler" can't be enabled separately, it depends on "Advanced CSS/JS Aggregation". As soon as those two are enabled, the CSS breaks completely (with "AdvAgg CDN Javascript", "AdvAgg Compress CSS", and "AdvAgg Compress Javascript" disabled). Actually, to break the CSS it suffices to just enable "Advanced CSS/JS Aggregation" (without any sub-modules).

Pretty weird; I deployed Advagg on a good a dozend sites, and only one makes this kind of trouble :-(

Comment #6

mrfelton commented 20 January 2012 at 00:35

I'm getting this on a (slightly customized) Barracuda system.

stdClass Object (
    [request] => GET /sites/stage.example.net/files/advagg_css/css_missing12217440311327019402_0.css HTTP/1.0
Host: stage.example.net
User-Agent: Drupal (+http://drupal.org/)
Connection: close

    [data] => 
    [protocol] => 
    [status_message] => 
    [headers] => Array (
        )
    [error] => 
    [code] => 0
    [timer] => Array (
            [count] => 1
            [time] => 60015.8
        )
)

If I access the css file directly in my browser, I get:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html><head><title>404 Not Found</title></head><body><h1>Not Found</h1><p>The requested URL was not found on this server.</p><p><a href="/">Home</a></p><!-- advagg_missing_fast404 --></body></html>

Comment #7

mikeytown2 commented 20 January 2012 at 00:37

Thats a Timeout
[time] => 60015.8

Comment #8

mrfelton commented 20 January 2012 at 00:39

Any ideas what could be causing it to time out? Works fine ((within milliseconds) from te browser. Any suggestions as to how to test? Been staring at this for a looong time now! :(

Comment #9

mrfelton commented 20 January 2012 at 01:36

If I comment out Aegir/Barracuda's 'advagg support':

###
### Advagg_css and Advagg_js support.
###
#location ~* files/advagg_(?:css|js)/ {
#  access_log off;
#  expires    max;
#  limit_conn gulag 50;
#  rewrite    ^/files/advagg_(.*)/(.*)$ /sites/$host/files/advagg_$1/$2 last;
#  add_header ETag "";
#  add_header Cache-Control "max-age=290304000, no-transform, public";
#  add_header Last-Modified "Wed, 20 Jan 1988 04:20:42 GMT";
#  add_header X-Header "AdvAgg Generator 1.0";
#  try_files  $uri @drupal;
#}

It stops timing out:

stdClass Object (
    [request] => GET /sites/stage.example.net/files/advagg_css/css_missing5373043161327023233_0.css HTTP/1.0
Host: stage.example.net
User-Agent: Drupal (+http://drupal.org/)
Connection: close

    [data] => <html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>Barracuda/1.0.11</center>
</body>
</html>
    [protocol] => HTTP/1.1
    [status_message] => Not Found
    [headers] => Array (
            [Server] => Barracuda/1.0.11
            [Date] => Fri, 20 Jan 2012 01:33:53 GMT
            [Content-Type] => text/html
            [Content-Length] => 173
            [Connection] => close
            [Vary] => Accept-Encoding
        )
    [error] => Not Found
    [code] => 404
    [timer] => Array (
            [count] => 1
            [time] => 2.69
        )
)

Although the status report still shows "ADV CSS/JS AGG - ASYNCHRONOUS MODE Set to FALSE."

Comment #10

bartezz commented 5 February 2012 at 16:53

I've got this error as well, followed the steps and updated settings.php with the supplied code, flushed all caches, but this is the report;

stdClass Object (
    [request] => GET /sites/default/files/advagg_css/css_missing7602868451328397761_0.css HTTP/1.0
Host: local.example.com
User-Agent: Drupal (+http://drupal.org/)
Connection: close

    [data] => <html><head><title>404 Not Found</title></head><body><h1>Not Found</h1><p>The requested URL was not found on this server.</p></body></html>
    [protocol] => HTTP/1.0
    [status_message] => Not Found
    [headers] => Array (
            [Date] => Sat, 04 Feb 2012 23:22:41 GMT
            [Server] => Apache/2.2.17 (Win32) mod_ssl/2.2.17 OpenSSL/0.9.8o PHP/5.3.4 mod_perl/2.0.4 Perl/v5.10.1
            [X-Powered-By] => PHP/5.3.5
            [Content-Length] => 139
            [Connection] => close
            [Content-Type] => text/html
        )
    [error] => Not Found
    [code] => 404
    [timer] => Array (
            [count] => 1
            [time] => 15.56
        )
)

Any pointers?

Cheers

Update: removed the htaccess from /sites/default/files/advagg_css/ and flushed caches, all seems fine and dandy now!

Don't know what happened there but have a 'Adv CSS/JS Agg - Asynchronous Mode Set to FALSE' again...

Comment #11

tangent commented 23 February 2012 at 14:22

I fought with this issue. I discovered that having a location block in the nginx vhost config that matches css/js files, in addition to the recommended advagg location block, would trigger this if the advagg location comes last. I moved the advagg location block higher in the configuration and the warning message disappeared.

However, enabling asynchronous mode (whatever that does is not clear) causes bundling to either behave unpredictably or not at all on my system so I suspect there are other issues. Leaving asynchronous disabled seems to work fine though.

Comment #12

mikeytown2 commented 23 February 2012 at 22:57

@tangent
Can you test something for me? Get the latest *dev* version of HTTPRL and check the status page once its been installed. Let me know the status for HTTPRL. HTTPRL is code from advagg that has been abstracted out to be generalized and in the process I fixed some issues. I think I've fixed the nginx issue in HTTPRL but I need to be sure. If so then that means I need to release a 2.x branch of advagg that uses HTTPRL.

Comment #13

tangent commented 24 February 2012 at 16:11

I've installed the httprl module dev branch and it reports that everything is correctly configured in the Drupal status page. I've also re-enabled synchronous mode in advagg. I've flushed Drupal cache and used the advagg master reset option. Neither CSS nor javascript is being aggregated or compressed. Disabling again causes them to bundle. Perhaps I still have an nginx issue?

UPDATE: note that I'm using -1 as the sync address because of virtual name based hosts in case that's a factor.

Comment #14

tangent commented 24 February 2012 at 16:28

It looks like the aggregation include mode setting is the cause of files not being aggregated with asynchronous mode enabled. It was set to "Only serve aggregated files if they are already built (only works if async is enabled)". Changing that to "Wait for locks" makes aggregation work. This sounds like a bug but perhaps I misunderstand the meaning of those options.

Comment #15

mikeytown2 commented 24 February 2012 at 20:31

@tangent
That mode means that generating the aggregates in the background isn't going to work currently in advagg. But it does mean that some of my improvements to HTTPRL can make async work. This is good info for me... but for you not a lot will happen till 7.x advagg is out the door. You can disable HTTPRL as it's not doing anything for advagg currently; just needed it to test out a theory.

Comment #16

tangent commented 14 August 2012 at 15:23

Status	File	Size
new	status.png	57.77 KB

It's unfortunate that the warning for asynchronous mode must seem so alarming in the status page. The module works fine without this feature.

Comment #17

mikeytown2 commented 22 August 2012 at 17:44

You are correct, advagg is still working, it's just not as fast as it could be.

Comment #18

mrP commented 1 November 2012 at 15:12

Version:

6.x-1.6

» 6.x-1.x-dev

duped the timeout in #6 using dev with async enabled

Comment #19

asb commented 14 February 2013 at 15:00

For some time, this issue vanished from my sites (#2, one year ago), now it's back; this time not only on one, but on multiple sites; running Pressflow 6.28 and advagg 6.x-1.9:

Adv CSS/JS Agg - Asynchronous Mode: Set to FALSE.

Check to see if you have fast 404s, […] - No.
You can try flushing the menu cache as well. - No effect.
[…] you can go to the AdvAgg information tab and select Asynchronous debug info.

That says:

http://{my IP address}/sites/default/files/advagg_css/css_missing1922060181360852493_0.css:

stdClass Object (
    [code] => -110
    [error] => Connection timed out
    [timer] => Array (
            [count] => 1
            [time] => 30029.58
        )
)

Also we have:

AdvAgg JS Compress - Callback: The callback for testing if a JS file is compressible is not working.

Description says: "As a result if jsmin+ encounters a file that it cannot compress, it will kill that PHP process."

"jsmin+"? That's weird because we're running "JSMin".

Sporadic/additional we get from Boost: "Boost crawler did not get a 200 response; -111 returned instead. Connection refused", and from core the ugly "HTTP request failure". Very weird on 6.x sites where the configuration is very rarely touched.

Comment #20

mikeytown2 commented 1 December 2015 at 22:44

Status:

Active

» Closed (cannot reproduce)

I can't reproduce this issue locally; no way to fix as a result. Reopen if you have a patch.