Thread subscriptions not being mailed...

[jeremycs]

Thread subscriptions are not being mailed,

but sending mail through diagnostics works.

Sending mail to users directly "Send Users Email" works.

New users are getting their confirmation emails.

We are not using SMTP.


This seems to have broken after a network move.

Any ideas?

[Steve Machol]

Please see this page for help troubleshooting email problems:

http://www.vbulletin.com/docs/html/troubleshoot_email

[jeremycs]

Steve,

I have followed suggestions on that page.

As I stated in my first post... sending mail through diagnostic mode works.

Sending mail through the mass mailer to users also works.

Registration emails work.


Thread subscriptions do not get emailed, and they used to without fail.

I've tried via SMTP, using the -f flag (but we've always used qmail)... it all works for everything EXCEPT thread subscriptions.


This happened after a server move & upgrading



FWIW, we're also having a problem with private messages being sent, but not delivered.



Maybe I need to fix a database or some tables or something?

Is there somewhere other than the web log that I could view errors within the vBulletin system?


Thanks

[Steve Machol]

If you followed all the instructions on that page, what did the server and vB email logs show?

[jeremycs]

If you followed all the instructions on that page, what did the server and vB email logs show?

All other emails seem to be working... so the logs that I have look ok.


We're using 3.5.x right now (and upgrading to 3.6.x isn't an option for us yet) so we don't have the option to

Admin CP -> vBulletin Options -> Error Handling & Logging -> Log sent eMails to a File

yet since that is part of 3.6


Other than that... it's a hard for me to log/test the thread subscriptions emailing routine in real time because I need to somehow force the thread subscription email to trigger.

I guess I could turn the session timeout time down really low and update a thread I'm subscribed to (instant updates) with another user from another browser.

[jeremycs]

FWIW, we're also having a problem with private messages being sent, but not delivered.

(the PM's actually were being delivered, but the status isn't updating)




So here's a thought....

Since basic on-demand emails from the VB system work (ie registration email, mass emails, diagnostic test email), BUT thread notifcation emails do NOT work, AND (see link above) private messages are being sent, but the "unread" status is not changing....

are those two functions controlled by a cron?

Perhaps our scheduled task crons are no longer working?

I've confirmed that $cronimage is in the footer, but I did edit the footer file around the same time this started happening.


Are thread notification emails (even when set to immediate notification) AND private message "unread" status updated by scheduled tasks?


Is there a quick way to test if the $cronimage is executing the scheduled tasks?

[jeremycs]

Aha! I've just confirmed that crons have not been executed since us changing servers (but they have executed since the last footer modification that was made).... so it has something to do with the server move.

[jeremycs]

UPDATE:

As described in this thread


We've traced this to being caused by us running PHP5 on the new server.

In PHP5, when "START MAIN SCRIPT" section of cron.php is ran, for some reason $vbulletin->options['crontab'] is null or 0....

While running PHP5, we got the crons to run again by inserting this line:

// #######################################################################
// ######################## START MAIN SCRIPT ############################
// #######################################################################

header('Location: ' . $vbulletin->options['cleargifurl']);

($hook = vBulletinHook::fetch_hook('cron_start')) ? eval($hook) : false;

$vbulletin->options['crontab']=1; // THIS LINE WAS ADDED TO MAKE CRONS WORK ON PHP5
if (!defined('NOSHUTDOWNFUNC') AND !$vbulletin->options['crontab'])
{
      vB_Shutdown::add('exec_cron');
} 

But since there are other annoying glitches as well, (like private messages no longer alerting people of new messages) we've just opted to drop back down to the PHP 4.x branch for now.


Dropping to PHP 4.x seems to have solved all of our move related problems.



(We are running 3.5.1 with security patches up to 3.5.5)