I have migrated an 220.127.116.11 ojs to a new server and upgraded it to 18.104.22.168.
Now we are testing that all works as expected and we found that the system started to send revision reminders to actual users from this test installation which caused some confusion.
Looking at the configuration, I can see that in config.inc.php the option scheduled_tasks as been always in OFF, the cron of this machine is blank, so I cannot understand who triggered this reminders.
Reading about scheduled tasks I have seen that acron plugin is supposed to substitute the traditional cron procedure. I’ve checked and after the database upgrade the acron plugin is activated by default! why? and also in my case the revision remainder email was deactivated, so, acron plugin shouldn’t be the one who triggered that emails.
Also, this note in the revision email reminder configurations confuses me:
Note: To activate these options, the site administrator must enable the scheduled_tasks
option in the OJS configuration file. Additional server configuration
may be required to support this functionality (which may not be possible
on all servers), as indicated in the OJS documentation.
So… who have triggered the emails?
Why the acron plugin activation/deactivation is system wide? Can not have a journal with scheduled task and other without?
I don’t understand but seems to me that if the new plugin is the way to go for, why not delete all the cron way from documentation, notes, config, etc…?
Hi, @pir. I think your analysis of your situation is accurate. The acron plugin is the new (and sometimes surprising) default, and the documentation hasn’t fully caught up.
In our institution, we prefer a more fine grained approach to the scheduled tasks, so the first thing we do it disable acron and setup our crons. It’s good to have both options. We certainly welcome contributions if you have specific suggestions for improving the documentation.
Unfortunately I don’t have knowledge to correct the documentation about cron/Acron now.
So Acron it’s supposed to be system wide and with traditional cron you can go more in detail for every journal?
Correct. Acron is a site plugin, but with the traditional cron, you have more control on a journal-by-journal basis.
So @ctgraham, the idea behind Acron is basically activate Acron always (system wide for all journals) and set scheduled options correctly in every journal, so the administrator of every journal must revise every scheduled task option in order to set them appropriately for it’s journal. That’s seems logic but there isn’t an ojs system-wide-plugins administrator, so any administrator can disable/enable the Acron for all the system which is very dangerous.
At the same time, the status of email reminders for revision cannot be modified via web if you don’t have scheduled_tasks = On in config.inc.php so crash with the idea of get rid of the traditional scheduled tasks system.
So… my hypothesis of why the emails has been sent with a blank cron and the scheduled_tasks = Off is that Acron comes enabled by default, my migrated database had scheduled tasks enabled so the Acron saw this and processed them, this is correct? if yes shouldn’t Acron come disabled by default?
How can I trigger a scheduled task now in order to test things?
Note that Acron can only be enabled by a Site Administrator. The Site Admin needs to go through one of the Journals to do so, but the plugin is a Site plugin, and requires the Site Administrator for access. A Journal Manager will not be able to enable/disable the plugin.
I would tend to agree that Acron should be delivered off by default, but I also see how it can be helpful to default to on so that “it just works” out-of-the-box.
To “trigger” a scheduled task on demand via Acron, you’ll need to edit the database directly. Check the
scheduled_tasks database table. The
last_run column will be the key. Acron looks at the scheduled task’s
frequency setting in the XML, and looks at the
last_run to see if the task is due.
Can you describe step-by-step the workflow where “the status of email reminders for revision cannot be modified via web if you don’t have scheduled_tasks = On in config.inc.php”? We may want to list that as an issue, if reproducible.
Now I understand that there are two roles, Site Administrator and Journal Manager, so it has sense that journal managers can’t touch acron status and site administrator can (typical only one account), anyway will test this to confirm that all is ok.
So what would be the best procedure to import a production database in a test environment in order to test scheduled tasks? I would need to delete the current scheduled tasks and create new test ones, how?
About the last problem, if you login as site administrator and go to:
my journals > site administrator > hosted journals > choose one > setup > policies
in Reviewer Reminders you can see 2 check boxes, “If reviewer has not responded to a review request within X days” and “If reviewer has not submitted a recommendation within X days after review’s due date”, this check boxes are not editable until you have scheduled_tasks = On, which I think is optional if you are going with the Acron setup.
I wonder if the
scheduled_tasks should be On, even if just using Acron. I bet @beghelli would know.
To test the scheduled tasks in development, I would copy the OJS files and database to a new server, then either turn off smtp/postfix to disable email, or replace the email addresses in the database with mailinator or similar disposable addresses. You can then set the
scheduled_tasks.last_run date to an arbitrary testing date.
I have disabled postfix when I had this issue, the problem is that to test the scheduled tasks I have to enable postfix in order to see if all is working correctly, so this is not a good workaround for us.
Setting last_run date to an arbitrary one don’t think also work for us, because probably it wouldn’t be triggered but I only need to stop sending email to the old reminders, not the new ones I will create for testing.
Replace email addresses should work.
Another question, about the logs placed in files/scheduledTaskLogs/, for example the reminder email ones should log only something like this??
[2016-03-03 10:39:20] [Notificació] S’ha iniciat la tasca.
[2016-03-03 10:39:20] [Notificació] S’ha aturat la tasca.
Sorry, is not english, but only says start and end? doesn’t log who has sent the email?
The scheduled_tasks setting was never a trigger to really enable the tasks. It was always a place where the admin should tell the system that it had scheduled tasks running, so the system could show to the users functionalities that are scheduled tasks dependent.
So even with acron plugin, scheduled tasks should be on. This is definitely something I should fix (since acron is enabled by default, the scheduled tasks are always on, so this setting should be on by default).
I created an issue to improve this part of the system: Make scheduled tasks settings clearer · Issue #1219 · pkp/pkp-lib · GitHub
Thanks for your report @pir.
The log was initially implemented for debugging purpose only, and specially for the usage stats plugin. I didn’t worked much on the other scheduled tasks and we didn’t had any situation where we needed more information, so that’s why the log info is so low.
But that’s an easy thing to implement. I am only concerned about implementing something like that as default because for some installations this log can be really large, and as I said, I don’t see any benefit of logging this information every time the task runs.
We have 4 instances of OJS on one server - on different ojs sites. Acron plugin is enabled for all of them. For one of them (journal2) we receive notifications emails of the tasks being run every midnight at 12:05am. But not for the others. Crontabs are set for all of them as below in the server:
0 0 * * * php /www/journal1/tools/runScheduledTasks.php
5 0 * * * php /www/journal2/tools/runScheduledTasks.php
10 0 * * * php /www/journal3/tools/runScheduledTasks.php
15 0 * * * php /www/journal4/tools/runScheduledTasks.php
I have also checked the scheduled_tasks.last_run for each journal. It’s being updated for each journal to:
(for last night for example)
I have also tried running:
php /www/journal[n]/webroot/tools/runScheduledTasks.php /www/journal[n]/plugins/generic/usageStats/scheduledTasks.xml
However still no email is sent for three of the journals. Have you got any idea why this is happening?
I think I know what had caused the difference:
scheduled_tasks_report_error_only in config file needs to be set to Off in order to receive all email notifications.
For anyone else who stumbles on this topic, I want to note that we had trouble calling the crontabs via an absolute pathname (for example,
0 0 * * * php /www/journal1/tools/runScheduledTasks.php). In particular, scheduled tasks which depend on calculating a journal base_url (like the PLN) were unable to accurately do so. A more reliable method (but maybe not perfect) is to
cd to the OJS root directory and to run the command from there with a relative path (for example,
0 0 * * * cd /www/journal1/; php tools/runScheduledTasks.php).