Updated to the beta version this afternoon. On a windows environment, apache though.

Nice improvments - setup presets and all that, I did a test page with this call:
print theme('imagecache', 'profile-mini', '/sites/default/files/pictures/picture-1.jpg');

The page looked good the first time. Then went to view/edit again, and started getting this error with no images:

Imagecache already generating: sites/default/files/imagecache/profile-mini/pictures/picture-1.jpg, Lock file: sites/default/files/tmp/profile-minipicture-1.jpg

Looks like you were expecting it, what's the solution? Tried dumping image cache / flushing.


Greg Bear’s picture

Quick bit of more info. So the picture-1.jpg is sitting in the /tmp folder. Removing it & hitting refresh was able to see the sized image. Hitting refresh again, got the error message above and the picture sitting in the tmp file.

dopry’s picture

Status: Active » Postponed (maintainer needs more info)

Did you install image api? which image toolkit are you using?

Greg Bear’s picture

API installed, using GD.

I have gotten this to work though.

If I do this in a theme.tpl page (as documented) it works fine - with the user loaded of course:
print theme('imagecache', 'profile-main', $profuser->picture, $profuser->name, $profuser->name );

But if I drop that same line straight into a CMS edit view, and save it as PHP then the experience above happens. Where it loads the first time, and then doesn't clear out tmp.

So no crisis, but strange behavior I guess

dopry’s picture

delete the locks from tmp... It seems like php may be crashing and not running the shutdown functions which should be cleaning out tmp for you...

Greg Bear’s picture

Hi - just a quick follow-up on this. I checked tmp again after a couple weeks, and there is a folder full of uploaded images. I removed the .htaccess from this folder, is that what you mean by deleting the locks from tmp?

More info on how to make sure tmp gets cleaned out.


dopry’s picture

are there files in tmp with imagecache in their name?.... or php*

almich’s picture


I am experiencing the same problems. When I visit a page with a scaled image the first time everything works fine. After pressing reloading the images are gone and replaced by the alt-text. Trying to access the image directly results in an empty html-document.

In the error-logs I get the "Imagecache already generating" error mentioned in the originally posting.

When I look into the files/tmp directory there can be found files named like thumbfoto1.jpg with filesize 0 (thumb is the name of my imagecache preset, foto1.jpg the name of the uploaded image). When I delete these files, go back to the browser and reload the page, images are showing up again. But also the files in files/tmp are recreated and a new reload will make the fotos disappear again...

So for me it seams to be clear that the shutdown functions don't clean out tmp but I have no idea why.

Here is some information about my installation:

Drupal 5.7
ImageAPI 5.x-1.0-rc1
ImageCache 5.x-2.0-beta
ImageField 5.x-2.0-rc6

image-toolkit: GD
download-method: private
clean-urls: activated and working fine


almich’s picture

Hi again

It seems like the $path variable in the imagecache_shutdown_clear_lockfile function needs to bo an absolute reference (/path/to/drupaldir/files/tmp/lockfile.jpg). See http://www.php.net/manual/en/function.register-shutdown-function.php#59300


Nexotap’s picture


Just was fiddling around with imagechache and encountered same problem.
Here's a simple solution/hint:

Correct me if I'm wrong, but Drupal by default uses a relative path for the temporary directory.
Just go to http://localhost/admin/settings/file-system (Where localhost will be your domain) and put in an absolute path for the temporary directory. That should do the job.

In hope that helped.



dopry’s picture

Status: Postponed (maintainer needs more info) » Fixed

a fix has been committed to head rev 1.61

Anonymous’s picture

Status: Fixed » Closed (fixed)

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

doublejosh’s picture

I'm having the ImageCache already generating: sites/default/files/imagecache/NAMESPACE/FILENAME, Lock file: /tmp/NAMESPACEFILENAME problem with 6.x-2.0-beta8

I'm assuming imagecache puts the filename and namespace together like that when generating the temporary file.

woodbutcher’s picture

Same problem here with 6.x-2.0-beta9. Some images appear, others don't, a file with a mashup of the original preset filename appears in /tmp, size 0 bytes. Deleting these lock files and reloading the page restores missing images.

s3n04k’s picture

Version: 5.x-2.0-beta » 5.x-2.3

Hi, I'm also experiencing the same issue on 5.x-2.3, managed to get rid of the "Imagecache already generating error" by making the temporary folder path absolute (no lock files anymore in temp folder - wohooo!).

Unfortunately my celebration was premature, the issue still persists, particularly on pages with a large number of imagecache images (mine has 12 images, all 130x95). Smaller pages are OK, but the images seem to reload on every refresh (not getting served from cache), even though from observation the headers were "304 Not Modified".

I'm not sure if it is a module or hosting issue. Any help on this issue would be greatly appreciated.


manatwo’s picture

Just in case someone comes along this post like I did, the fix in post #9 worked for me. Thanks!

Sagar Ramgade’s picture

I tried the solution suggested on post # 9, it didn't work error still coming, however when i deleted the file from tmp directory error goes and again arises.
Any help?

woodbutcher’s picture

Try this thread: http://drupal.org/node/461014 message #4

Sagar Ramgade’s picture

I have installed Imagemagick, after all resolving all the errors pre and post installation i was able to make it work.
However after using imagemagick also i am facing the same issue.
Could anyone suggest, whats the solution ?

robray’s picture

For those troubleshooting this issue, I had this same problem and got around it by boosting the memory_limit in php.ini.

plasticlax’s picture

i get this error in relation to a large image i try to upload with the latetest imagefield. i used gd and imagemagick. usually the upload itself crashes, but if eventually it succeeds and then the image is there on the node in VIEW mode but when i go to edit the node, i get the white screen of death forever after on that node.

chrismoylan’s picture

Switching to imagemagick solved this for me.

DaniG2k’s picture

Version: 5.x-2.3 » 6.x-2.0-beta10
Component: Code » imagecache_image module
Status: Closed (fixed) » Needs work

I'm on Drupal 6 using the latest 2.0 beta of imagecache and I'm getting the same problem:

ImageCache already generating: sites/default/files/imagecache/blahblah

the image only gets scaled properly once, then stops loading.
Does anyone know if this has been resolved?

DaniG2k’s picture

Priority: Normal » Critical


Many many people seem to be having this same problem, and it seems to have been going on for several years now. I am getting the same message:
ImageCache already generating: sites/default/files/imagecache/full_size/image.jpg, Lock file: /tmp/full_sizeimage.jpg.

sovarn’s picture

Is there a way of fixing this?

I have tried deleting the image from the node, saving the node and then viewing the node. Then reediting the node and adding the picture back in but the problem still persists.

Is there a temporary manual solution that can be used?

amaisano’s picture

Same problem.

mattcasey’s picture

Same problem, I tried raising my PHP limit to 350MB, tried flushing all caches. It turned out I don't have a tmp folder in my root drive, although I was able to create one, so I couldn't find any temporary imagecache files... and my temporary folder is set to /tmp. I am using
ImageCache 6.x-2.0-beta10
ImageAPI 6.x-1.9, GD Toollkit
Drupal 6.2
PHP 5.2.15

I was able to fix this by boosting my memory limit to 1000MB (crazy, I usually have it about 128) and restarting the server. Actually, changing the memory limit didn't seem to have any effect until I restarted the server.

WildBill’s picture

Status: Needs work » Active

Yep, I'm having this problem too. Some presets aren't getting generated, same error log as mentioned above (Imagecache already generating...).

mattcasey’s picture

Deleting images from the tmp folder and reloading the page works sometimes, is there a way to write a cron hook to delete all tmp files every so often? (I'm a n00b to cron tasks)

WildBill’s picture

I have fixed my problem. I checked my Apache error logs (in my hosting CPanel) and I saw tons of errors about not being able to find magickwand.so. Turns out BlueHost (my hosting provider) upgraded PHP and a new version of php.ini was needed. The one I was using was vastly outdated. So I followed the instructions at http://www.bluehostforum.com/showthread.php?22237-error-Unable-to-load-d... (created a new php.ini). Then I turned Drupal's caching off, and then back on again. Problem solved!

MatthewDodwell’s picture

For me the error was the order of gd.so and pdf.so in php/extensions.ini. gd.so must come first

I just moved them to the end of the list:


and everything is now working fine.

alexverb’s picture

I had exactly the same problem. My fix was to change the file system tmp folder from outside the root to the sites/default/files folder. Now all imagecache files were generated.

I'm thinking it's a path issue. Can anyone confirm changing directory to sites/default/files/tmp fixes it?

tahamohkawy’s picture

changing directory to sites/default/files/tmp fixed the problem for me


fizk’s picture

Priority: Critical » Normal
Status: Active » Closed (fixed)
mattgilbert’s picture

Version: 6.x-2.0-beta10 » 6.x-2.0-rc1
Status: Closed (fixed) » Active

I still see this problem in 6.x-2.0-rc1. Defining the tmp directory to be sites/default/files/tmp seems to improve performance slightly (more thumbnails were generated, but still not all). Even after flushing the preset and raising the php memory limit to 1000MB, it seems that once it fails to generate a thumbnail, it is stuck, and will continue to fail.

I can make it create the thumbnails one by one if I flush the new tmp directory and then ask for each thumbnail image individually. It's not reasonable to ask the client to do this though.

german.villacreces’s picture

I had the same issue, the problem was that the image being resized was too big and ImageCache didn't finish creating the tmp file, so it was just sitting there in my /tmp folder. I fixed the issue by simply deleting the tmp file and making my size smaller so the ImageCache process didn't crash.

Hope it helps.

kuldip zala’s picture

Hello All,

Do not create tmp folder under files folder. Just create under sites/all/default/tmp and give 777 permission to it.


sdsheridan’s picture

Issue summary: View changes

I think this is the same problem as #461014: fails to create presets sometimes. I've proposed a solution in that issue.


vasike’s picture

the same as #37.
i also think it's duplicate of #461014: fails to create presets sometimes.