Mass Edit Plugin Spawns php5.cgi Processes

NickC

I realise mass edit plugin isn't supported, I'm hoping someone using it can help.

Using mass edit causes continuous respawning of about 20 php5.cgi processes. I can't kill them off since they respawn. It overloads my cpu quota on my hosted server and my site becomes unavailable.

I've confirmed it is the plugin causing it by monitoring my site with the unix command `top`. Everything is fine until I click mass-edit, immediately a bunch of php5.cgi processes fire up.

Does anyone else see this, and is there a fix? I will have to remove the plugin if I can't fix it.

(I am guessing the approx 20 processes is something to do with the number of items the plugin is editing. The edit page lists roughly 20 items at a time.)

Thanks,
Nick

sbillard

I believe what you are seeing is the i.php processes which are spawned for each image that zenphoto needs to process. Mass-edit will naturally spawn these processes for any image in the album that does not currently have a thumbnail.

Unfortunately that is how image processing works. Perhaps you can place thread limits on the php tasks. Zenphoto does not actually have any control over how many processes it uses (other than by not spawning so many images--the reason why mass-edit is not the normal image page.)

Really, this problem should go away over time as the thumbnails are created. If not, then something else is going on. You can check your page source. Once an image has been cached the img src should be something like `src="/cache/Clocks/A%20Lashmore_100_cw85_ch85_thumb.jpg"`. When it has not been cached it will have a img src that contains an `i.php` link. Try viewing the normal image tab and checking its HTML. If after a refresh of the page the `i.php` link is still there, something is going wrong.

NickC

My apologies, although zenphoto was creating a fairly high number of processes, it wasn't responsible for the continuous spawning, which was the real problem. The issue was a typo in .htaccess that caused a loop.

Thanks for the reply, explains it neatly. I take your point about how image processing works.

sbillard

Juist curious--what was the typo?

NickC

The loop was a redirection to /index.php if the user typed an unknown URI. Problem was, /index.php itself had an unknown URI (the typo, an incorrectly spelled css file) within it. So index.php calls for a file, apache can't find it so redirects to index.php, which calls for a file which apache can't find, etc.

I think the mass-edit plugin triggered it because I had manually (in a shell) deleted an image from the album while at the same time editing the album in the web interface. Perhaps. I don't really know. I wasn't going to test it again because I have to get my host's support to kill all the processes. It takes hours to get them involved and meanwhile uses up my cpu quota.

At the time, I was sure that using `top` was a good indicator of where the problem lay, but really it was misleading. Sure, hitting the mass-edit button triggered it off, but so would have a user manually typing an invalid URI unrelated to zenphoto. It's just that, during the 30 minutes or so while I was investigating, no one did do that, so I got a false lead from `top`.

NickC

BTW, delete this thread if you like. The subject is misleading to a casual viewer of the forum, since mass-edit doesn't cause continuous respawning.

sbillard

We will leave the thread. If someone just reads the thread title without looking at the messages they will get what they deserve.

Thanks for the explaination.