@ibPeter The event log page, under the System menu. You really should have been looking at that every time that you sent a campaign.
@duncanc I agree, I had no idea. Silly really, of course there would be logging …
4107272016-12-16 17:40:04Failed sending message 141 to shouldbounce@shouldbounce123shouldbounce.com
page: processqueue
4107262016-12-16 17:40:04Failed sending to shouldbounce@shouldbounce123shouldbounce.com
page: processqueue
4107252016-12-16 17:40:04It took 0.0069960000 seconds to send
page: processqueue
4107242016-12-16 17:40:04Error sending email to shouldbounce@shouldbounce123shouldbounce.com Could not instantiate mail function.
page: processqueue
4107232016-12-16 17:40:04Sending 141 to shouldbounce@shouldbounce123shouldbounce.com
Am I correct to assume that ‘the source of all evil’ is:
Could not instantiate mail function.
? Any idea what to look at now to fix this ?
PS. don’t get fixated on the bad email address. I get the exact same logging for all the good email addresses as well !
Yes, every time a mail gets blocked by your host or errors, it is placed back in the queue for further processing. This is how you sometimes see 3500 emails sent w/ only 2000 subscribers
Things are becoming clearer. Any idea what is blocking the outgoing emails ?
Sending a test email, during the campaign’s editing phase, is never a problem ?
Yet from the first email onwards, during the actual processing of the campaign, all emails appear to fail sending.
I am not aware of a block from my server host. They would have informed me. I’m on a virtual server with a unique IP.
I can ask, but I assume to know the answer. So what else could be wrong ?
I now strongly suspect it has to do with the software / OS upgrade on the server.
Where should I look to try and fix this ?
Perhaps I should loop in the server folk.
The friendly hosting service support guy triggered the script manually (the one normally done via a cron job) and it executed properly (as far as I can tell). Emails actually went through this time. All test mails to myself.
So … why not when executed via cron ?
The Cpanel emails on every cron clearly reported output from the script ?
@ibPeter That message “Could not instantiate mail function.” means that the call to the php mail() function failed.
Two possible reasons are
-
you are sending at too fast a rate (hourly, daily or however they calculate the limit)
-
or you are using an invalid From address, either does not exist or is not on the same domain
I have no limit as far as I know and I’m certainly not sending fast at the moment anyway.
The From address does exist but is not on the same domain I suppose !? It’s a domain hosted on the same server but the server itself has a .biz extension.
But … again … this always worked ?
And the server tech just executed the script manually successfully ?
On the command line no issue … via cron all the earlier shown symptoms ?
@ibPeter You will have to ask the hosting company to investigate why the mail() call is failing. They should be able to find something in the web server or php logs. The failure reason doesn’t seem to get passed back to phplist.
I have the feeling that on server side, the person handling this has given up after a lot of back and forth emailing.
Manually executing the script worked. He also installed another php script and tested that and it worked.
I argued:
"And the path the cron is executed from ?
Could that have an influence somehow ?
I don’t know enough about this server stuff, but you also were able to start the phplist script manually.
So perhaps you started it from a certain path that is different from the cron ?
Or is it a user permissions thing ?"
His last response.
“Cron is just executing a
script, so unless the script itself is not logging anything then, there
is no way to get the logs. Actually there is no server error named
"Could not instantiate mail function”, that is coming from the script
itself. Google search shows all the links related to PHPMailer. I
suggest to enable the script debugging to find what is the exact error
PHP or server is returning."
Any feedback or ammunition to get it looked at again appreciated.
@ibPeter The text “cannot instantiate …” is produced by the phpmailer code, so any error reported in the server log or php log will be different. But if you give him the exact time of a couple of errors from the phplist event log then that might help. Also, it is probably the mail server process that would be logging an error not the web server.
Otherwise try sending through an smtp server.
Thank you @duncanc and all, I was able to send out emails overnight. I woke up to the positive result, as a result from the last action last night before I turned the lights off 
Copied from the Hosting co conversation (after I respectfully asked to escalate the issue to a superior) :
The PHPList software
seems to support SMTP as an alternative to the PHP mail API, so I
suggest using that as a workaround. You can can use localhost as the
SMTP server, without authentication. This should allow you to bypass
whatever problem is occurring when PHPList calls the mail() function.
This is the first solution I would recommend, and it’s also been
suggested in your forum thread.Another possible
troubleshooting step would be to enable normal shell access for user_x.
This would result in cronjobs running under a normal bash shell,
similarly to the environment where Unni successfully ran the script.
Please let me know if you’d like me to enable normal shell access.
I asked for the latter before turning in ( enable normal shell access ) and that did the job.
It seems the crons were running in a ‘jailshell’ ?
I don’t know the first thing about this, but it was my hunch that it had to do with permissions.
I’ll keep monitoring this when I start sending out the real email load Monday and the days after.
For now, knowing about jailshell vs normal shell may help others as well.
Thanks Duncan, I have got logging on and can’t see anything untoward in there…logs the emails it sends to actual people on the list but not the other activity it seems to be doing ‘behind the scenes’.
The hosting tech guy came back with this:
"While investigating I found that the script is resetting the password due to high number of dovecot logins to email : 314 dovecot_login:enquiries@theloaf.co.uk
Not sure if the mailing list is causing a separate login attempt to send the emails. Can you please confirm if you are using email client like outlook to send the emails."
I have no idea what ‘dovecot login’ would be, or if phplist does this. Though I use gmail to transact all my personal emails, I assume phplist operates independently of whatever email engine one uses?
This screenshot shows the live logging. It only seems to show the emails one by one and doesn’t indicate any extra activity going on in the background that might be causing an issue.
Thanks again for your help…sorry @ibPeter for hijacking your thread, but it seemed to be the same issue. Though I don’t know what a cron is, so perhaps we aren’t quite doing the same thing.
Andrew
@aulda from what you have shown phplist is sending at quite a slow rate, 3 emails in 72s, so that is not the cause of your problem.
Dovecot is the mail server software that handles POP3 and IMAP access to email accounts on your domain. phplist would not use that for sending, only when retrieving bounces from the bounce email address.
The response from the hosting company that you quoted was a bit garbled but refers to the email address enquiries@theloaf.co.uk
I suggest that you ask them to explain more clearly exactly what is happening for that email address. It sounds like too high a frequency of logins, so ask whether they can identify the source of the logins, say the IP address, and also the times of the logins so that you can see if they match when phplist is processing the message queue.
That’s Ok @aulda
Looking at your extra information there is little I can help you with.
This is clearly not my cup of tea either.
Hi everybody,
it is an very old thread, but it seems that this topic is not solved.
Since two weeks I have the same problem:
PhpList stopped sending email and keeps cycling through selected lists again and again (never-ending?) during sending of a campaign
I find out that all subscriber addresses don’t exist anymore and most of them were in one old list.
I use the latest phplist version, talked to my hoster (1&1), who told me that nothing is wrong. E-mails are send to 1500-2000 subscribers.
Everything worked fine, but as I wrote, since two weeks I get this error
Could not instantiate mail function.
Do you have any idea what the problem coudl be?
Thanx in advance
Could not instantiate mail function means that phpList cannot connect to the mail server. The mail server is either not running, or the settings in the config.php file are wrong. It could also be that your hosting company has blocked the connection somehow.
I would start by rebooting your server, and see if that starts the mail server.
Hi @danwaterloo
thank you for your reply.
That would mean that no e-mails will be send out, right?. It’s only 3-5 from over 1500 addresses which make problems.
I haven’t changed anything and as I described above, two weeks ago everything workd properly.
Which setting do you mean? SMTP settings?
I contacted my hosting company and they told me that nothing is wrong…
Thanx
Still having the same problem.
But I have noticed, that the
Could not instantiate mail function.
error only comes when I send the same newsletter to an expanded list.
Any ideas to solve this problem would be very nice.
Thank you
I was getting the same error (when sending to more than 247 subscribers in one pass) after I moved to a new hosting provider on a server that was 5 to 10 times faster than my old hosting provider. My new provider has a limit on how many resources I can use simultaneously. It turns out I was exceeding one of those parameters (I believe it was number of processes or IOPS, I can’t recall which one) so my ability to send email from PHP was suspended for a few seconds. That is when I received the errors. I fixed it by using define(‘MAILQUEUE_THROTTLE’, 1.00); in config.php. All my lists are less than 500 subscribers, so a one second delay between messages is not a problem for me.
There are, of course, many other items that can cause the “Could not instantiate mail function.” error. I’m just letting you know what I did to solve my problem.
1 Like
Without reading too much of this already big thread. You need to make your session timeout longer and the intervals between the mails should be small so you don’t get out of session. For example send every 10 minutes 3 messages, so you don’t get out of session.
Second. Please shut up this provider, because this embarrassing. 75 mails per hour in 2017