Subscription Expiry Emails Not Working

[rarbelo]

Hello,

We cannot get our subscription expiry email notifications to work via the runScheduledTask.php cron job. Email is working on the server as we can check the box that will send the user an email with their username and subscription details. That works. However, we set up a couple of users and set their subscriptions to expire in a month (which we have checked in Subscription Policies), but no notification is sent. We do have scheduled tasks on in config.inc.php:

scheduled_tasks = On

Here's the cronjob that we have set up:
*/5 * * * * /usr/local/bin/php /usr/local/apache2/htdocs/ojstest/tools/runScheduledTasks.php > /usr/local/apache2/logs/ojs_task.txt 2>&1

I have it running every five minutes just for testing purposes. There is no output in the log. When I run it manually, I get nothing returned, so I assume that it's running correctly and not producing any errors.

We're on version 2.3.3.2, which I know is a little old (we're going to upgrade this summer, hopefully).

Any help would be greatly appreciated!

Thanks,
Ralph

[JasonNugent]

Hi Ralph,

Can you see in your mail logs (for your server) if the emails are being sent out? Maybe they are being dropped or deferred for some reason (like a missing header). Is there still a tasks.SubscriptionExpiryReminder entry in the registry/scheduledTasks.xml file?

You may also want to try removing the 2>&1 from your crontab, just to see if error messages aren't being redirected somewhere else (which is what that does). Although, it looks like that should go into your tasks log file. I assume that the permissions are correct on that file for whoever the crontab runs as?

Regards,
Jason

[rarbelo]

Hi Jason,

There is a task class tasks.SubscriptionExpiryReminder in scheduledTasks.xml:
<task class="tasks.SubscriptionExpiryReminder">
<descr>Send automated reminders to subscribers regarding their expired/about to expire subs
criptions.</descr>
<frequency hour="0"/>
</task>

Do I need to set the frequency? It looks like it's set to go at midnight, though my cronjob is set to run every five minutes.

I removed the standard error redirection from the cronjob, though I'm still not seeing anything. Root runs that job, BTW, and it can write to the log file I set up.

Root doesn't have any messages in its mail spool. The mail log doesn't show any errors. It only shows activity when I send the subscription email.

Thanks!
Ralph

[JasonNugent]

Hi Ralph,

What hour="0" means in the scheduledTasks.xml file is that the task does run when the hour is 0 (so, midnight), but it doesn't necessarily run every time you run the crontab -- it will do a comparison between the current time and the time the task was last actually run, based on a timestamp stored in the database. What you may want to do is have a look at the values in the scheduled_tasks table to see when your subscription reminder task has actually run last. You might also want to clear the set value for that task in that table and try running the cron again.

Regards,
Jason

[rarbelo]

Hi Jason,

I clear out the values in the table:
mysql> select last_run from scheduled_tasks;
+---------------------+
| last_run |
+---------------------+
| 2012-04-30 00:55:02 |
| 2012-04-30 00:55:02 |
| 2012-04-30 00:55:02 |
+---------------------+
3 rows in set (0.00 sec)

And it appears to be running:
mysql> select last_run from scheduled_tasks;
+---------------------+
| last_run |
+---------------------+
| 2012-04-30 11:10:02 |
| 2012-04-30 11:10:02 |
| 2012-04-30 11:10:02 |
+---------------------+
3 rows in set (0.00 sec)

But still no notifications have been sent.

Ralph

[JasonNugent]

Hi Ralph,

Can you confirm that the checkboxes next to the various subscription policy reminders are also checked off?

If those checkboxes are checked, the class file in classes/tasks/SubscriptionExpiryReminder.inc.php has a function called sendJournalReminders() that has a few if() statements with some tests to make sure that subscription reminders are turned on. There are four of them (one for each of the options on the subscription reminder policy page). You might want to put some debug statements in there, maybe with error_log('in here') type things, to confirm that those are being set.

There is also a method in that class called sendReminder() that does the actual sending of mail. That'd be another candidate for a few echo or error debug statements.

I am curious, because on my test installation here, those methods get called and subscription notifications go out.

Regards,
Jason

[rarbelo]

Hi Jason,

I verified that the checkboxes are checked for the Subscription Expiry Reminders.

It appears that nothing in SubscriptionExpiryReminder.inc.php is getting run as far as I can see. I have a bunch of error_log statements, but nothing is getting written in the log. However, I know that various functions in lib/pkp/classes/cliTool/ScheduledTaskTool.inc.php are being run, as I added a bunch of error_log statements and they are writing to the log. Here's the sequence of events:

1) I run from the command line: php /usr/local/apache2/htdocs/ojstest/tools/runScheduledTasks.php
2) ScheduledTaskTool.inc.php runs this;
function ScheduledTaskTool($argv = array()) {
parent::CommandLineTool($argv);

if (isset($this->argv[0])) {
$this->file = $this->argv[0];
} else {
$this->file = TASKS_REGISTRY_FILE;
}

if (!file_exists($this->file) || !is_readable($this->file)) {
printf("Tasks file \"%s\" does not exist or is not readable!\n", $this->file);
exit(1);
}

$this->taskDao =& DAORegistry::getDAO('ScheduledTaskDAO');
error_log('one');

3) tools/runScheduledTasks.php runs this:
function runScheduledTasks($argv = array()) {
parent::ScheduledTaskTool($argv);
error_log('runScheduled_task');

4) ScheduledTaskTool.inc.php runs the rest of these-
function parseTasks($file) {
$xmlParser = new XMLParser();
$tree = $xmlParser->parse($file);
error_log('done_parsing');

5) foreach ($tree->getChildren() as $task) {
$className = $task->getAttribute('class');
error_log('className');

6) $frequency = $task->getChildByName('frequency');
error_log('frequency');

7) function checkFrequency($className, $frequency) {
$isValid = true;
error_log('is_vaild');

$lastRunTime = $this->taskDao->getLastRunTime($className);
error_log('last_run_time');

9) $dayOfWeek = $frequency->getAttribute('dayofweek');
error_log('day_of_week');

10) We added an else statement in the function below to check the funciton below:
if (isset($dayOfWeek)) {
$isValid = $this->isInRange($dayOfWeek, (int)date('w'), $lastRunTime, 'day', strtotime('-1 week'));
error_log('dw1',$dayOfWeek);
} else {
error_log('not_set');
Not set show up in the log

11) $month = $frequency->getAttribute('month');
error_log('month');

12) $day = $frequency->getAttribute('day');
error_log('day');

13) if (isset($frequency)) {
$canExecute = $this->checkFrequency($className, $frequency);
error_log('can_execute');

14) $xmlParser->destroy();
error_log('three');

15) function execute() {
$this->parseTasks($this->file);
error_log('two');

That's it. I don't have error_logs for every function, so it's possible more is going on.

Thanks, again, for all your help. I think we're getting closer to figuring this out.

Ralph

[joboco]

Hello Ralph (&Jason)

Thanks for your posts that deal EXACTLY with the problem we are currently facing. We will walk all your steps, but it could be nice if you could post what you actually found to be the cause of the problem. I suspect something simple, but there is no shame!

Thank you very much for your contribution through this post!

Best,

J.

[joboco]

Indeed, this was a non issue: the emails are automatically sent on the EXACT day of the reminder that is set. So clearly, if you do not run the CRON daily, some email reminders will not be send out! And if you missed some email reminder (we had the CRON weekly), they will not automagically be sent out the next time you invoke the php script.

The trick we used to send all the backlog of email reminders we had in the system was just to play with the expiration date of the subscription and the reminder date. Then just manually invoke the php script, as describe above in Ralph post... and you should catch-up with the backlog of unsent emails.

Hope that helped.

J.