I'm getting this error in my blog pages. I think it's new, though I'm not sure. How can I debug this? Or does anyone know why it's happening?

Comments

mr.baileys’s picture

StatusFileSize
new787 bytes

We are seeing similar behavior on one of our sites, albeit on a D7 site and only with Image Style derivatives. We changed some of the image style definitions, which caused the pre-generated (obsolete) images to be removed. The new versions of images for these image styles are not being generated, and the CDN links all contain "/cdn/farfuture/mtime:/*" (note the empty mtime UFI) .

The site is behind a reverse proxy (Squid), and CDN uses drupal_http_request() to trigger recreation of the images. While the drupal_http_request is successful, it is actually ending up with a cached version of the file. Here's an example:

'code' => '200', 
'status_message' => 'OK', 
'headers' => array( 
  <some headers snipped for brevity>
  'date' => 'Fri, 27 Jan 2012 15:36:41 GMT', 
  'last-modified' => 'Wed, 12 Oct 2011 08:46:35 GMT', 
  'cache-control' => 'max-age=2678400',
  'expires' => 'Mon, 27 Feb 2012 15:36:41 GMT',
  'x-cache' => 'HIT from <squid1>',
  'age' => '272167',
  'via' => '1.1 <squid2>:80 (squid), 1.0 <squid1>:80 (squid)',
), 
)

This means that the file is not actually created and CDN cannot get a filemtime, resulting in a warning and an empty mtime UFI.

We are currently testing with the patch attached (against 7.x-dev) to try and avoid getting a cached item. I'll provide feedback once I know whether or not this works.

mr.baileys’s picture

StatusFileSize
new844 bytes

Previous patch was mixing D6- and D7-style drupal_http_request parameters...

mr.baileys’s picture

Version: 6.x-2.2 » 7.x-2.x-dev
Status: Active » Needs review
StatusFileSize
new781 bytes

Patch in #2 resolved our issues, here is a D6 version of the patch (contrary to the D7 patch, this one is untested).

wim leers’s picture

wim leers’s picture

Status: Needs review » Fixed
StatusFileSize
new900 bytes

With minor changes (comment wrapped at col 80, s/$uri/$path/ in the D6 patch), committed! Thanks :)

D7: http://drupalcode.org/project/cdn.git/commit/3860d89
D6: http://drupalcode.org/project/cdn.git/commit/2c92ade

If you get this for blog/feed however, this patch won't solve your problem. This probably only happens when you haven't applied the Drupal core patch.
I've rolled a patch that fixes this problem (tested and verified that it works). The problem is that it's impossible to discern between menu system items that do generate files and that don't. So this patch will fail when a URL that uses page arguments (which ImageCache uses, but "blog/feed" does not) and does not generate files.

jaypan’s picture

I've applied the core patch, but am getting the error for blog/feed (I'm the OP).

The problem is that it's impossible to discern between menu system items that do generate files and that don't. So this patch will fail when a URL that uses page arguments (which ImageCache uses, but "blog/feed" does not) and does not generate files.

Soo... is this patch safe to apply even if I've patched core? Is it going to cause me problems? What do you mean it will fail? Is there some way for me to fix this?

Thanks for your prompt reply by the way, much appreciated.

wim leers’s picture

Status: Fixed » Active

I'd guess it'll work fine for 95% of all sites. But there are cases where it may fail.

However, if you can reproduce the "blog/feed" problem even when you *do* have the core patch enabled (did you just apply it, or did you already have it applied in the OP?), something strange must be happening on your site. Could you add the following just before the line that's throwing the error:

var_dump(debug_backtrace());
exit;

Could you then post the output here? Thanks :)

jaypan’s picture

Apologies - I didn't have the core patch applied. I had applied it to a different Drupal installation a few days ago, not the installation I was getting this message from. I've applied it, and the error is gone. Thanks for the assistance!

jaypan’s picture

Status: Active » Fixed
wim leers’s picture

That makes much more sense :) Glad to hear it's solved now!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

philsward’s picture

I'm getting the same thing on 6.x-2.3-dev+1 but for Ubercarts /catalog URL's...

warning: filemtime() [function.filemtime]: stat failed for catalog/sealcoating-systems in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.
warning: filemtime() [function.filemtime]: stat failed for catalog/parking-lot-striping-equipment in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.
warning: filemtime() [function.filemtime]: stat failed for catalog/crack-cleaning-equipment in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.
warning: filemtime() [function.filemtime]: stat failed for catalog/sealcoating-systems/polyskid-transfer-systems in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.
warning: filemtime() [function.filemtime]: stat failed for catalog/crack-filling-equipment/melter-applicator in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.
warning: filemtime() [function.filemtime]: stat failed for company/financing in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.
warning: filemtime() [function.filemtime]: stat failed for catalog/parking-lot-striping-equipment in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.
warning: filemtime() [function.filemtime]: stat failed for catalog/asphalt-compactors in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.
warning: filemtime() [function.filemtime]: stat failed for info/how-to-asphalt-seal-coat-spray-guide in /home/(userfolder)/public_html/sites/all/modules/cdn/cdn.basic.farfuture.inc on line 237.

Is this related and in need of backporting? If so, should I create a new issue for it?

I tried to block the catalog* in the CDN Drupal Path blacklist, but this didn't seem to help... From what I can tell, it's only on the homepage of the site too...??

broncomania’s picture

#5 fixes for me also this bug in d7

indigoblue’s picture

I am also seeing this issue.

I am runing d7.12 and CDN 7.x-2.3.

In addition to the patch in #5, there was mention of a "core" patch - is this something I need to do ( if so, where is it? ).

tx