It looks like you're new here. If you want to get involved, click one of these buttons!
We recently upgraded our sendy version to 22.214.171.124 and setup our email like normal and sent out the email to our 2 "lists" like normal. These 2 lists each contain about 65,000 different emails for a total send of about 135k emails going out. Weird thing is when I checked the email details later in the evening Sendy said it sent out 222,880 emails and Amazon SES says the same. When I view the campaign stats, it shows emails only went to the 2 different lists so where did the extra 90,000 emails come from? The sad part is our "spam count" and unsubscribe rate also doubled for this campaign since people were getting 2 emails -- thankfully our "numbers" of those are still very low.
What can I look at to dig and see what happened? I have another email to send out and don't want to double up on emails again.
FYI our server is a AWS C1.medium running debian (PHP Version 5.3.3-7+squeeze15). As for Sendy patches we send out subscriber emails about once ever 10-12 days and have religiously upgraded each time prior to sending when their was a new patch/upgrade available.
Sorry to hear that. I'm about as puzzled as you when it comes to this as I can never reproduce the same issue during my tests before rolling out each update. The sending code for 126.96.36.199 hasn't been changed as well.
If all is well, it could be something to do with Debian and PHP squeeze. I've always tested on regular Linux and Apache on Amazon EC2 server and never had a duplicate sent though.
Thanks for the response - here are the details:
Here is our cron job:
*/5 * * * * wget -q -O /dev/null http://[ourdomain].com/scheduled.php
FYI, this is running a different box other than the one that Sendy is installed on -- not sure if this will matter or not.
The queue table does have records in it:
total records in there with the query_str as null - 154,910
280 records in the queue table in which the query_str is NOT null
We can't really run the "remove duplicates" since we have had to "segment" our overall subscriber list since we have different campaigns that get sent to different segments of it. So yes, if we ran it, our lists would be unique but would make it more difficult to send out to different "campaigns". We do have 2 core "lists" though which are unique that we have been using and haven't modified in past couple of months and have sent about 6ish emails to these 2 lists with no problems.
No we didn't get our "campaign sent" email like we normally do with them -- normally it takes a couple of hours to sent out the 130k emails and after 4ish hours I started to wonder.
As for Debian we used to run CentOS but were having challenges with running our application on it and getting too many "blank pages" from apache through our elastic load balancer -- issue was related to how CentOS (others were having challenges too with it) was doing what it was doing and Debian hasn't had any challenges at all. FYI, only debian issue I have found and I am sure it has to do with our "directory permissions" is we can't upload a file in php presently (for imports) but this hasn't in the past affected emails going out to be candid for the past 8ish campaigns (just over 1.5 million emails).
Let me know any other thoughts, questions or actions.
Thanks for clarifying.
There was one other user who had the same problem as well. And he was also using wget instead of php to execute the scheduled.php script. It was specified in Sendy's cron job instructions to use php to execute the scheduled.php script. Both of you seem to use wget and getting the same issue.
I suggest removing that cron job from the external box and adding a cron job on the same server where Sendy is running. use php to execute the scheduled.php script instead. Your cron job command will look something like:
*/5 * * * * php /path/to/scheduled.php > /dev/null 2>&1
Lastly, empty your queue table by going to http://your_sendy_installation_url/clear-queue.