@swsharp opened this issue on June 11th 2015

In version 2.10, the scheduled email reports are not being sent. This is a pretty recent installation from the beginning of the year and is not an upgraded environment. I am able to send reports manually. I have seen a couple issues opened regarding this same problem but I was not able to find an instance where the issue was reproduced or a definite cause was found.

I created a test report and scheduled it to be sent daily at 12 o’clock local time (CDT). It displays as Tasks.myTask in the Scheduled Tasks plugin list.

After the 12 o’clock hour came and went, the report had not been sent and the Scheduled Task had not updated. Here is the task just a couple minutes after 12 o’clock.

After setting the report to run at 10 o’clock, the scheduled time does not update in the Scheduled Tasks plugin list. It is still showing the scheduled time as 9 o’clock.

After running ./console core:run-scheduled-tasks the entry is updated to the correct time of 10 o’clock.

This is the same for all of the scheduled tasks. Until I ran the command for the first time yesterday, all of the scheduled tasks had dates that were more than two months old. Running the command updated all of the scheduled tasks but I cannot tell that any of them are running.

With the scheduled time set to 10 o'clock, once again the scheduled time came and went without the report being sent and without the scheduled task being rescheduled for the next day.

In testing yesterday, with the reports scheduled for 12 o’clock, I set the log_level to DEBUG for a few minutes but did not find any debug statements that seemed related to scheduled tasks. Today, with the report scheduled for 10 o’clock and the log_level set to INFO there was not output at all around that time (15:00).

WARNING LoginLdap[2015-06-11 14:43:29] [d10f4] authenticateByPassword: empty login encountered. WARNING LoginLdap[2015-06-11 14:50:59] [fa6ed] authenticateByPassword: empty login encountered. WARNING LoginLdap[2015-06-11 14:50:59] [238a1] authenticateByPassword: empty login encountered. INFO Piwik\Tracker\ScheduledTasksRunner[2015-06-11 15:20:39] [20d7e] --------------------------- INFO Piwik\Tracker\ScheduledTasksRunner[2015-06-11 15:20:39] [20d7e] INIT INFO Piwik\Tracker\ScheduledTasksRunner[2015-06-11 15:20:39] [20d7e] Piwik is installed at: https://hostname/piwik/index.php INFO Piwik\Tracker\ScheduledTasksRunner[2015-06-11 15:20:39] [20d7e] Running Piwik 2.10.0 as Super User

Also, browser archiving is enabled and the “System Check” does not report any issues.

Thanks

@swsharp commented on June 17th 2015

I have had a Cron entry running core:run-scheduled-tasks yesterday and today and it seems that the scheduled reports are now being sent at 1 hour and 5 minutes past the hour they are scheduled.

This coincides with the Cron entry: 5 * * * * /usr/bin/php /var/www/html/piwik/console core:run-scheduled-tasks

Should it really be necessary to execute this command manually in order to use scheduled reports? Also, it seems that when you set the time, for a Daily report at least, it does not get sent on the same day. I do not receive the report for the first time until the following day, despite the fact that I have core:run-scheduled-tasks running every hour now.

@mattab commented on July 15th 2015

Hi @swsharp do you still experience this issue with Piwik 2.14.0?

Should it really be necessary to execute this command manually in order to use scheduled reports?

No it shouldn't be necessary. Do you also have a cron running for the core:archive command? http://piwik.org/docs/setup-auto-archiving/

@swsharp commented on July 17th 2015

Hi @mattab sorry for the delay.

I had tried the core:archive command at one time but that didn't seem to have any effect on the scheduled reports. And looking at the logs I did not see any indication that the archiving is failing. I eventually arrived at the core:run-scheduled-tasks command as a temporary solution.

I do have the default option to allow archiving to be triggered by the browser, though I probably shouldn't since the site has more than 10,000 visits/day. I will disable the browser archiving and begin to use the hourly cron.

Also, I finished building a test 2.10.0 server using the production data yesterday and upgraded it to 2.14.1. The users are wanting an upgrade to 2.14.1 anyway so I will let you know if we continue to see any issue there.

@mnapoli commented on July 20th 2015

Hi @swsharp, to help us debug you could try enabling logging at DEBUG level (watch out it will log a lot of things!) into the log file (requires Piwik 2.11 or greater):

[log]
log_writers[] = "file"
log_level = "DEBUG"

Then you should be able to find logs by searching for Scheduler (cat tmp/logs/piwik.log | grep Scheduler).

Remember to change from DEBUG level to WARN level once you have finished (e.g. let it run for a day maybe). Watch out for the log file size if you have a lot of traffic.

@swsharp commented on July 30th 2015

On the Piwik 2.10.0 server the only redirected output from the core:archive task is the following:

INFO CoreConsole[2015-07-30 12:20:01] ---------------------------
INFO CoreConsole[2015-07-30 12:20:01] INIT
INFO CoreConsole[2015-07-30 12:20:01] Piwik is installed at: https://hostname/piwik/index.php
INFO CoreConsole[2015-07-30 12:20:01] Running Piwik 2.10.0 as Super User

In the piwik.log file, with log_level = "DEBUG", this is the output (I only removed lines pertaining to the LoginLdap plugin):

DEBUG Piwik\Db[2015-07-30 12:20:02] Db::fetchAll() executing SQL: SELECT DATABASE()
DEBUG Piwik\Db[2015-07-30 12:20:02] Db::fetchAll() executing SQL: SELECT option_value, option_name FROM `piwik_option` WHERE autoload = 1
DEBUG Piwik\Db[2015-07-30 12:20:02] Db::fetchOne() executing SQL: SELECT option_value FROM `piwik_option` WHERE option_name = ?
DEBUG Piwik\Plugin\Manager[2015-07-30 12:20:02] Loaded plugins: CorePluginsAdmin, CoreAdminHome, CoreHome, CoreVisualizations, Proxy, API, ExamplePlugin, Widgetize, Transitions, LanguagesManager, Actions, Dashboard, MultiSites, Referrers, UserSettings, DevicesDetection, Goals, SEO, Events, UserCountry, VisitsSummary, VisitFrequency, VisitTime, VisitorInterest, ExampleAPI, ExampleRssWidget, Provider, Feedback, UsersManager, SitesManager, Installation, CoreUpdater, CoreConsole, ScheduledReports, UserCountryMap, Live, CustomVariables, PrivacyManager, ImageGraph, Annotations, MobileMessaging, Overlay, SegmentEditor, Insights, ZenMode, Morpheus, Contents, BulkTracking, Resolution, DevicePlugins, IntranetGeoIP, LdapVisitorInfo, LoginLdap, TasksTimetable
DEBUG SitesManager[2015-07-30 12:20:02] Db::fetchAll() executing SQL: SELECT idsite FROM piwik_site
DEBUG LanguagesManager[2015-07-30 12:20:02] Db::fetchOne() executing SQL: SELECT language FROM piwik_user_language WHERE login = ?
DEBUG SitesManager[2015-07-30 12:20:02] Db::fetchAll() executing SQL: SELECT idsite FROM piwik_site

By comparison, on the 2.14.1 server I am seeing a lot more output from core:archive and the task actually appears to be running. I am also receiving a test report without having to run core:run-scheduled-tasks on the 2.14.1 server.

@mattab commented on August 14th 2015

@swsharp do you still experience the missing reports issue, or are all reports now correctly sent?

@mattab commented on September 11th 2015

It may be worth trying again in 2.15.0-b7 where we fixed an issue which may help with this. If you still have the issue (or anyone else!) please leave a comment

@swsharp commented on September 11th 2015

@mattab we still had the problem with 2.10.0 but I updated the server to 2.14.3 last weekend and the problem seems to be gone.

I am now only running the core:archive command every hour in Cron, and not the core:run-scheduled-tasks command, and the scheduled reports are being sent.

Whatever the problem was seems to be fixed in the new releases. Thanks for your help with this issue.

This issue was closed on September 11th 2015
Powered by GitHub Issue Mirror