back to

Send process zombie after campaign successfully sent


My searches in the forum have not come up with an answer for this problem. If I’ve missed something, I would appreciate a link to an existing discussion.

I’m using version 3.3.1 in a BSD environment. I’m not using cron, I just trigger queue processing via the Web UI and wait for it to finish (but it never does).

When a campaign is done (i.e., everything in the queue is successfully), the updating log of actions in the queue processing window shows the “nothing more to do” message but the process never stops, even if I leave that browser tab open for hours. I can manually “cancel” the (already-finished) process using the button provided for that purpose, but this typically hangs my phpList session. Whether I manually stop it or not, the lock in the database remains, so every time I want to send a campaign, I have to open the database and make sure I manually removed the lock before or do so at that time.

Am I misunderstanding something, or is this a bug? It seems to me that when the queue is empty and everything is done, processing should end, the lock should be removed, and I should be able to continue using phpList (i.e., navigating to other pages) without opening a new browser window.


Correction/update: I did find another thread discussing the leftover lock in the database but no resolution was given.


The attached screen clip shows an instance of what I’m talking about. I sent a campaign to my test list (to test something unrelated to this issue) and now I must – as always – modify the database directly to remove the lock. As can be seen in this clip, there is “Nothing to do” but there is still the “Stop processing” button. I always end up “stopping” the already-complete process, but the lock in the “sendprocess” table remains.

I wish I’d had a chance to test this with the current Release Candidate but I just haven’t had time.


I had some thin hope that 3.3.2 might (accidentally?) fix this, but the problem remains.

I assume this problem prevents me from fully automating things because I can’t set up a cron job as long as I have to manually delete a record from the phplist_sendprocess table after every send action. As I understand phpList and this problem, the first cron job would run fine (instead of me clicking the “cancel” button after everything is finished, I think the cron process would time out(?)), but after that nothing would work until I manually deleted that record. Rinse and repeat.

I don’t see anything in the log that shows any error happened. The following screen clip shows what I see after sending a test campaign, waiting a short while, and then clicking the button to manually cancel the (already-finished) processing.

I spent some time (over an hour) trying to trace through the code and find a way to debug this but there’s no way I can jump into that in a reasonable amount of time given the circumstances – my unfamiliarity with the code, the state of the code (lots of cruft from what I could see), my need to be productive on other things, etc.



Well, apparently this is not true, because command line and in-browser queue processing work differently. When I was perusing the code I saw something that hinted this might be the case, and today I finally took the time to try it. Sure enough, the send process ends cleanly and the lock is removed.

So while the browser interface for queue processing is apparently broken (at least in my production environment), I actually can set up a cron job to process the queue. I prefer processing the queue manually when I want the message to start sending, but if it keeps me from constantly using phpMyAdmin to delete a leftover record, I guess I’ll switch to cron processing. Not sure how frequently I’ll have it run, though. Hmm.


Ha… nope. When the command line process processes the queue and there’s nothing to send, the lock is left behind, making future queue processing abort immediately.

I’m having a conversation with myself here, but I know at least one other person ran into this, per that earlier thread that also did not get resolved. This is frustrating in the truest sense of the word. Sending campaigns should not involve accessing the database manually every single time.