imagecache already generating...

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

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...

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

Hi

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

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

almich

Hello

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.

Cheers

Nexo

a fix has been committed to head rev 1.61

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.

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.

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.

Cheers,
s3n04k

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

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?

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

Hi,
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 ?

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

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.

Switching to imagemagick solved this for me.

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?

Subscribe.

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.

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?

Same problem.

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

[Update]
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.

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

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)

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!

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:

....
gd.so
pdf.so

and everything is now working fine.

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?

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

thanks

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.

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.

Hello All,

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

Thanks,
Kuldip

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

Shawn

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