Answers.Body: <p>I was having this issue (w/ PHP 5.6, Craft 2.6.x, on WebFaction hosting) because it seemed like PHP had no memory limit and single processes were handling huge image transform queues, bombing when it got over 1.5gb or so.</p>
  
  <p>Making sure Imagick has a memory cap seems to do the trick to avoid the queue getting stuck as PHP runs out of memory, which is discussed here: </p>
  
  <p><a href="https://craftcms.stackexchange.com/questions/12472/possible-memory-leak-generatependingtransforms-imagemagick/18947#18947">Possible memory leak - GeneratePendingTransforms/ImageMagick</a></p>
  
  <p>Relevant code:</p>
  
  <pre><code>// From http://stackoverflow.com/a/12835966
  // Pixel cache max size
  $this-&gt;setResourceLimit(\Imagick::RESOURCETYPE_MEMORY, 256);
  // Maximum amount of memory map to allocate for the pixel cache
  $this-&gt;setResourceLimit(\Imagick::RESOURCETYPE_MAP, 256);
  </code></pre>
  
  <p>in <code>craft/app/vendor/pixelandtonic/imagine/lib/Imagine/Imagick/Imagick.php</code> at line 33, at top of smartResize() function.</p>
  
  <p>Update:</p>
  
  <p>If you are not on shared hosting but on a VPS (or otherwise have sudo access on your server, OR are able install ImageMagick + php-imagick from source), you can set memory caps for ImageMagick directly using a <a href="https://www.imagemagick.org/script/security-policy.php" rel="nofollow noreferrer">policy.xml</a> file, e.g.:</p>
  
  <pre><code>&lt;policy domain="resource" name="memory" value="1GiB"/&gt;
  &lt;policy domain="resource" name="map" value="1GiB"/&gt;
  &lt;policy domain="resource" name="area" value="1GB"/&gt;
  &lt;policy domain="resource" name="file" value="768"/&gt;
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-13T18:34:24.833Z
Answers.Text: Thanks for your answer! I actually managed to fix this in the meantime but I forgot to post the results. Your way does work but I'd recommend changing these values globally for ImageMagick since your changes could be overwritten by a craft update. You can do so in `/etc/ImageMagick-6/policy.xml`. [I've made a pastebin](http://pastebin.com/XVaLKQwY) with the needed additions. If you could add this to your answer I will mark it as accepted.
Answers.UserDisplayName: Sören Kampschroer
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-14T19:07:08.990Z
Answers.Text: Ok, done! I'm assuming a lot of people are running Craft on shared hosting, so this wouldn't help them. But it's obviously a better solution (and a good thing to do in general) if you have access to `/etc/ImageMagick/policy.xml` or `/etc/ImageMagick-6/policy.xml` or wherever else your distro might place that file. Thanks for the update.
Answers.UserDisplayName: Nate Beaty
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-11T23:54:35.627Z
Answers.LastActivityDate: 2017-02-22T17:04:57.343Z
Answers.LastEditDate: 2017-04-13T12:50:59.930Z
Answers.UserDisplayName: Nate Beaty
Body: <p>My image transform task always gets stuck halfway through so that I have to "repair" the task as per <a href="https://craftcms.com/support/stuck-tasks" rel="nofollow">this guide</a>. Im trying to convert about 150 images (amounts to ~300 steps). Resetting the task within the database does work but it's not a permanent solution.</p>
  
  <p>I've upped the php memory limit to 1024M, execution time is 0 and Apaches timeout is set to a ridiculously high number. Disk space is available and it's happening with imagemagick as well as gd. It also happens both on my local dev VM running Ubuntu 14.04 as well as on my Debian server. PHP and Apache error logs are empty on both machines. I'm running the Personal edition and the latest version of Craft.</p>
  
  <p>I also tried to set <code>ini_set('max_execution_time', 0);</code> in <code>craft/app/services/AssetTransformsService.php</code> but it didn't change anything.</p>
  
  <p>Some more info:</p>
  
  <ul>
  <li>Some image transforms are missing after restarting the task until it's complete. That renders the workaround by resetting the task in the db basically useless because not all images are transformed by the time it's complete.</li>
  <li>It's not a specific image that is preventing the task from completing, as it's always a different image that it's stuck on. </li>
  <li>There are usually 75-85 images converted until it's stuck.</li>
  <li><code>Update Asset Indexes</code> doesn't help.</li>
  <li>Clearing all caches makes Craft convert all images again. It doesn't delete the old files, it just overwrites them (and gets stuck, as usual).</li>
  </ul>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-15T22:47:14.403Z
Comments.Text: Any chances some (or all) of these 150 images you're transforming are animated GIFs?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-15T23:18:31.780Z
Comments.Text: Nope, they are all JPGs. Between 0.4 and 2.5MB in size.
Comments.UserDisplayName: Sören Kampschroer
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-15T23:19:41.380Z
Comments.Text: Have you bumped https://craftcms.com/docs/config-settings#phpMaxMemoryLimit from its default 256M as well?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-16T17:20:12.770Z
Comments.Text: Hey Brad, just tried that but it didn't help. I've set it to 1024M and it now gets to 110-120 before it stops. I tried to set the max exectution time to 0 in `AssetTransformsService.php` but that didn't change anything. Logs are still empty as well. Last entry in craft log is `[Forced] Starting step 116 of 310 total steps.` and then nothing.
Comments.UserDisplayName: Sören Kampschroer
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-16T17:33:02.677Z
Comments.Text: I just tried using completely different images, in case something was wrong with them, but it still gets stuck at step 120.
Comments.UserDisplayName: Sören Kampschroer
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-16T22:23:57.497Z
Comments.Text: Made some transform changes in https://craftcms.com/changelog#build2911 (mostly around animated GIFs, but wouldn't hurt to update and test). If not, do you get any related errors in `craft/storage/runtime/logs`?  Any chance you're running older versions of Imagick/GD that could be updated?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-17T02:25:55.913Z
Comments.Text: I updated Craft but it didn't help. I tried using GD again and it did get to 223/310 but then it stopped. GD version is 2.1.1, Freetype 2.5.2. Imagemagick was on 6.7. I installed Imagemagick/imagick from source but that doesn't work at all. Images are not resized and getUrl() gives me the url of the original image. There were no errors when compiling/installing imagemagick though and phperrors.log is still empty.
Comments.UserDisplayName: Sören Kampschroer
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-17T02:37:09.303Z
Comments.Text: It could be that GD is choking on an image/format is doesn't recognize. Imagick supports a much wider range of images and formats. I think I'd focus on getting Imagick installed and working and try the test with that.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-17T02:42:16.513Z
Comments.Text: Yeah thats why I wanted to use imagick in the first place. The reports from above are all on Imagemagick 6.7. Is there some kind of minimum required version? Have you tried ImageMagick v7.0.2 with imagick v3.4.3RC1? I'm using vagrant, so I could give you my config and you could see for yourself. Should be easily reproducible.
Comments.UserDisplayName: Sören Kampschroer
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-17T12:17:45.617Z
Comments.Text: Okay I think I found the problem now. Despite setting my php memory limit to 1024M in both my php.ini and Crafts general config, memory usage gets crazy high when converting images. By the time the task reaches step 100, php is using 85% of available memory. Once memory and swap is completely full it returns so 1.5% memory usage and thats when the task gets stuck. We are talking about 212MB worth of images, how can that fill up 2GB+ of memory? I can't be the only one experiencing this. The exact same thing happens in my Ubuntu VM and Debian server with different versions of Imagemagick and GD.
Comments.UserDisplayName: Sören Kampschroer
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-20T12:40:44.600Z
Comments.Text: @SörenKampschroer, unfortunately you're not alone... I've also some serious issues for images generations that get stuck again and again, despite a server configuration higher than the minimum requirements. Like I'm currently experimenting, perhaps you could look for cloud-based solutions like imgix.com or cloudinary.com to externalize these tasks.
Comments.UserDisplayName: Romain P.
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-13T18:42:26.607Z
Comments.Text: @Romainpoirier It was an ImageMagick issue actually. Have a look at natebeaty's answer below. ImageMagick's memory limit is independent from PHP's but it looks like PHP is using up all that memory in htop. I'd rather not use external image hosting since I have a server that is able to handle it.
Comments.UserDisplayName: Sören Kampschroer
Tags: <image-transforms><tasks>
Title: Generating pending image transforms stuck
ThreadText: # Generating pending image transforms stuck
  
  (Asked by: username_0 on 2016-08-14)
  
  My image transform task always gets stuck halfway through so that I have to "repair" the task as per [this guide](https://craftcms.com/support/stuck-tasks). Im trying to convert about 150 images (amounts to ~300 steps). Resetting the task within the database does work but it's not a permanent solution.
  
  I've upped the php memory limit to 1024M, execution time is 0 and Apaches timeout is set to a ridiculously high number. Disk space is available and it's happening with imagemagick as well as gd. It also happens both on my local dev VM running Ubuntu 14.04 as well as on my Debian server. PHP and Apache error logs are empty on both machines. I'm running the Personal edition and the latest version of Craft.
  
  I also tried to set `ini_set('max_execution_time', 0);` in `craft/app/services/AssetTransformsService.php` but it didn't change anything.
  
  Some more info:
  
  * Some image transforms are missing after restarting the task until it's complete. That renders the workaround by resetting the task in the db basically useless because not all images are transformed by the time it's complete.
  * It's not a specific image that is preventing the task from completing, as it's always a different image that it's stuck on.
  * There are usually 75-85 images converted until it's stuck.
  * `Update Asset Indexes` doesn't help.
  * Clearing all caches makes Craft convert all images again. It doesn't delete the old files, it just overwrites them (and gets stuck, as usual).
  
  **Tags:** image-transforms, tasks
  
  > **Comments:**
  > **username_1**: Any chances some (or all) of these 150 images you're transforming are animated GIFs?  
  > **username_0**: Nope, they are all JPGs. Between 0.4 and 2.5MB in size.  
  > **username_1**: Have you bumped https://craftcms.com/docs/config-settings#phpMaxMemoryLimit from its default 256M as well?  
  > **username_0**: Hey username_1, just tried that but it didn't help. I've set it to 1024M and it now gets to 110-120 before it stops. I tried to set the max exectution time to 0 in `AssetTransformsService.php` but that didn't change anything. Logs are still empty as well. Last entry in craft log is `[Forced] Starting step 116 of 310 total steps.` and then nothing.  
  > **username_0**: I just tried using completely different images, in case something was wrong with them, but it still gets stuck at step 120.  
  > **username_1**: Made some transform changes in https://craftcms.com/changelog#build2911 (mostly around animated GIFs, but wouldn't hurt to update and test). If not, do you get any related errors in `craft/storage/runtime/logs`?  Any chance you're running older versions of Imagick/GD that could be updated?  
  > **username_0**: I updated Craft but it didn't help. I tried using GD again and it did get to 223/310 but then it stopped. GD version is 2.1.1, Freetype 2.5.2. Imagemagick was on 6.7. I installed Imagemagick/imagick from source but that doesn't work at all. Images are not resized and getUrl() gives me the url of the original image. There were no errors when compiling/installing imagemagick though and phperrors.log is still empty.  
  > **username_1**: It could be that GD is choking on an image/format is doesn't recognize. Imagick supports a much wider range of images and formats. I think I'd focus on getting Imagick installed and working and try the test with that.  
  > **username_0**: Yeah thats why I wanted to use imagick in the first place. The reports from above are all on Imagemagick 6.7. Is there some kind of minimum required version? Have you tried ImageMagick v7.0.2 with imagick v3.4.3RC1? I'm using vagrant, so I could give you my config and you could see for yourself. Should be easily reproducible.  
  > **username_0**: Okay I think I found the problem now. Despite setting my php memory limit to 1024M in both my php.ini and Crafts general config, memory usage gets crazy high when converting images. By the time the task reaches step 100, php is using 85% of available memory. Once memory and swap is completely full it returns so 1.5% memory usage and thats when the task gets stuck. We are talking about 212MB worth of images, how can that fill up 2GB+ of memory? I can't be the only one experiencing this. The exact same thing happens in my Ubuntu VM and Debian server with different versions of Imagemagick and GD.  
  > **username_2**: @username_0, unfortunately you're not alone... I've also some serious issues for images generations that get stuck again and again, despite a server configuration higher than the minimum requirements. Like I'm currently experimenting, perhaps you could look for cloud-based solutions like imgix.com or cloudinary.com to externalize these tasks.  
  > **username_0**: @Romainpoirier It was an ImageMagick issue actually. Have a look at username_3's answer below. ImageMagick's memory limit is independent from PHP's but it looks like PHP is using up all that memory in htop. I'd rather not use external image hosting since I have a server that is able to handle it.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2017-02-11. Score: 2 | Accepted answer
  
  I was having this issue (w/ PHP 5.6, Craft 2.6.x, on WebFaction hosting) because it seemed like PHP had no memory limit and single processes were handling huge image transform queues, bombing when it got over 1.5gb or so.
  
  Making sure Imagick has a memory cap seems to do the trick to avoid the queue getting stuck as PHP runs out of memory, which is discussed here:
  
  [Possible memory leak - GeneratePendingTransforms/ImageMagick](https://craftcms.stackexchange.com/questions/12472/possible-memory-leak-generatependingtransforms-imagemagick/18947#18947)
  
  Relevant code:
  
  ```
  // From http://stackoverflow.com/a/12835966
  // Pixel cache max size
  $this->setResourceLimit(\Imagick::RESOURCETYPE_MEMORY, 256);
  // Maximum amount of memory map to allocate for the pixel cache
  $this->setResourceLimit(\Imagick::RESOURCETYPE_MAP, 256);
  
  ```
  
  in `craft/app/vendor/pixelandtonic/imagine/lib/Imagine/Imagick/Imagick.php` at line 33, at top of smartResize() function.
  
  Update:
  
  If you are not on shared hosting but on a VPS (or otherwise have sudo access on your server, OR are able install ImageMagick + php-imagick from source), you can set memory caps for ImageMagick directly using a [policy.xml](https://www.imagemagick.org/script/security-policy.php) file, e.g.:
  
  ```
  <policy domain="resource" name="memory" value="1GiB"/>
  <policy domain="resource" name="map" value="1GiB"/>
  <policy domain="resource" name="area" value="1GB"/>
  <policy domain="resource" name="file" value="768"/>
  
  ```
  
  > **Comments:**
  > **username_0**: Thanks for your answer! I actually managed to fix this in the meantime but I forgot to post the results. Your way does work but I'd recommend changing these values globally for ImageMagick since your changes could be overwritten by a craft update. You can do so in `/etc/ImageMagick-6/policy.xml`. [I've made a pastebin](http://pastebin.com/XVaLKQwY) with the needed additions. If you could add this to your answer I will mark it as accepted.  
  > **username_3**: Ok, done! I'm assuming a lot of people are running Craft on shared hosting, so this wouldn't help them. But it's obviously a better solution (and a good thing to do in general) if you have access to `/etc/ImageMagick/policy.xml` or `/etc/ImageMagick-6/policy.xml` or wherever else your distro might place that file. Thanks for the update.  
  
  ---
  
  