Page 1 of 1

Unable to send Confirmation Emails

Posted: Tue Jan 25, 2011 9:32 am
by pace
I'm able to send test emails, but my confirmation emails are not going out. Here's what I've found out so far:
  • Test emails work properly.
  • Files are created in spool/META, including the xml.gz, .stamp, and .final. These files appear to be properly formated and the xml.gz is created with the information about the user that I'm trying to confirm.
  • pickdist.py is running.
  • python-mysql is loaded. Executing "import MySQLdb" in python returns fine. There are no error messages in pickdist.log files. When the test emails are created, pickdist properly parses the file from META.
  • I'm able to both connect and execute queries on the openemm and openemm_cms databases using the user/password combination in the agn.py file.
  • There are no error messages in any of the log files.
  • OpenEMM startup looks normal:

    Code: Select all

    Starting OpenEMMStart /home/openemm/bin/scripts/bav-update.py .. done.
    Start /home/openemm/bin/scripts/bav-trigger.py .. done.
    Start /home/openemm/bin/scripts/bavd.py .. done.
    Start /home/openemm/bin/bav -L INFO .. done.
    Start python /home/openemm/bin/scripts/recovery.py .. done.
    Start /home/openemm/bin/scripts/update.py bounce account .. done.
    Start /home/openemm/bin/scripts/pickdist.py .. done.
    Stopping obsolete sendmail processes:   done.
    Starting sendmails:   listener  client queue clientmqueue  admin queue  mail queue  done.
    Start /home/openemm/bin/scripts/slrtscn.py .. done.
    Resin httpd start at Tue Jan 25 00:25:43 PST 2011
  • xmlback log file does not have any entries for "mail-creation" when the confirmation META files are created.
  • User to be confirmed is created in database and correctly flagged as waiting for confirmation.
I'm really at a loss at this point. I've spent hours digging through the forums here looking at every problem people have had with this. Each time I find a new piece of wisdom I find that it doesn't apply to me.


Any help is greatly appreciated...
pace

Re: Unable to send Confirmation Emails

Posted: Tue Jan 25, 2011 6:33 pm
by pace
Update:

About 10 hours later the emails that had piled up over the course of my evening of testing started slowly going out. I've just gone and requested another confirmation email and it is sitting in the META directory again (probably waiting for 10 hours). So I guess my problem is more around why my emails would be so delayed? Any hints on that?


pace

Re: Unable to send Confirmation Emails

Posted: Tue Jan 25, 2011 7:40 pm
by pace
And survey says I've been busted by the Timezone (others have noted this in posts). I had my server in the Pacific Time Zone, but somewhere in the mix it was queuing the META files for the current GMT time (+8 hours) and then pickdist.py was waiting then until Pacific Time caught up with the time GMT time that it was stamped with. It seems like there is a bug somewhere or that OpenEMM needs a timezone setting of its own.

Right now my workaround is putting my server in GMT. The timezone being set properly (it was at the beginning of this whole process) does not seem to fix it up and the suggestion in a different post of editing /etc/sysconfig/clock didn't do the trick either.


pace

Re: Unable to send Confirmation Emails

Posted: Tue Jan 25, 2011 9:55 pm
by maschoff
Which version of OpenEMM do you use?

Re: Unable to send Confirmation Emails

Posted: Tue Jan 25, 2011 10:03 pm
by pace
maschoff wrote:Which version of OpenEMM do you use?
6.2


pace

Re: Unable to send Confirmation Emails

Posted: Mon Jan 31, 2011 10:33 pm
by pace
Some extra information that may help track down the issue:
  • I'm on a virtual server (openVz).
  • Timezone on the virtual was initially set to US/Pacific (it is now set to UTC and it is working)
  • Timezone on the host machine is set to US/Pacific.
  • Hardware clock of the server is in UTC.
pace

Re: Unable to send Confirmation Emails

Posted: Fri Feb 04, 2011 2:14 pm
by maschoff
There was a bug with the send time of time zones <> GMT which was fixed with release 6.1. Which OS do you use? And do you have a specific example for us we can replicate to reproduce this behaviour?

Re: Unable to send Confirmation Emails

Posted: Fri Feb 04, 2011 11:05 pm
by pace
maschoff wrote:Which OS do you use? And do you have a specific example for us we can replicate to reproduce this behaviour?
CentOS 5.5

My best recommendation to replicate the problem would be to use a setup like I described above, but I imagine getting yourself one of those isn't easy. I can facilitate a test machine and/or a shared session if you'd like to see the problem first hand.

When you are having the issue, it is easy to recreate, simply create yourself a double-opt-in mailing list, go sign up for it and it takes however many hours you are offset from GMT for the confirmation mail to show up. You can see the mail waiting to go out in the META directory, it hangs out there until it is processed when your local time catches up with the GMT (so you need to be behind GMT to witness the problem).


pace

Re: Unable to send Confirmation Emails

Posted: Mon Feb 07, 2011 1:19 pm
by maschoff
Ok, I we will try it.

Re: Unable to send Confirmation Emails

Posted: Thu Feb 10, 2011 9:37 am
by maschoff
I was able to confirm a problem with the time of the mail generation which can lead to a wrong send time. We will develop a bugfix and announce its availability via our Twitter channel.

Re: Unable to send Confirmation Emails

Posted: Wed Feb 23, 2011 10:37 am
by maschoff
I was able to save the problem with the time of the mail generation which can lead to a wrong send time. Actually, a reboot makes the difference.

This is what I did:

1. Change time zone of server (either with GNOME's system-config-date or through "cp /usr/share/zoneinfo/US/Pacific /etc/localtime" and setting parameter ZONE in file /etc/sysconfig/clock to "US/Pacific"
2. Change time zone of OpenEMM user
3. Stop OpenEMM
4. Reboot server
5. Start OpenEMM

Step 4 made the difference for me. Now the generation time is displayed correctly and the send time is correct as well.