Since everything seems to be fixed with the (beta/RC)-Version in the mid of February now all the viewable Scheduled Tasks/Cron-Jobs (for Geoip update etc ) have stopped working again (and are in the past) please see attachment
current version: 2.1RC9 (no update shown)
## details of last fix:
finally fixed by fixing: #4612
see also: #4652
## now everything works fine!
=> hopefully we can say this again soon :-)
still not working in 2.1 final
Please see new attachment.
I cannot really reproduce it at the moment and need your help...
Can you check the local (might be not present there) and global config value of
and can you check the value of the option "lastTrackerCronRun" in the database "option" table?
There have been tracking visits since mid february right?
urgghhh you are ask-ing (its identified as spam..) the right thing: "There have been tracking visits since mid february right?"
I would say: "Yes of course!"
Thinking a little longer: We have got a multisite testing setup. On 2 of 3 sites there were many many visits.
On the first site (the one with the lowest site ID) there were no visits (because in the moment the development happens on the other sites..)
After visiting this site, there were immediately new tasks with a future date in the tasktime table plugin :-)
=> Maybe one should look on all sites for triggering the task/cron start. Or find any other suitable way for starting. -because we have really spent plenty of time on this topic and no one else should have to do this again...
Sorry for having to spent so much time on this. You're right, it should be triggered on all sites. Without testing but having a look at the code it should work for all sites as long as the tracking request is not authenticated.
Is there the possibility you are setting the token_auth parameter when tracking the other sites?
I also just noticed there is a setting named "tracking_requests_require_authentication" and if disabled it would not start the ScheduledTasks via Tracker. But this should be irrelevant for your case as it would not work for any site then.
thanks for your answer.
the is token_auth parameter is not set. The only think we are doing is forwarding the piwik subdomain: but tracking is working fine so everything should be ok on this place...
the problem is reproduceable. See new screenshots.
I do not think it is directly related to the "lowest idsite" but to a difference in how the tracking is done.
Do you think it is possible for you to change the following line: https://github.com/piwik/piwik/blob/master/piwik.php#L15 from
$GLOBALS['PIWIK_TRACKER_DEBUG'] = false;
$GLOBALS['PIWIK_TRACKER_DEBUG'] = true;
and then perform a regular tracking request and capture the response of that tracking request? Preferably first with the site that does not trigger the scheduled tasks and afterwards with the site that triggers the scheduled tasks (the site with the lowest id).
For instance in my case the output of a tracking request looks like this: http://pastebin.com/VZwDaAzx . You could post the responses either on pastebin and post a link here or if the responses contain sensitive data like IP or anything else you can send us an email to hello @ piwik.org .
It would help me as I cannot reproduce it so far.
Hi many thanks for your advise - sure I can do that and have already done this. => Where can I find debug messages? are they written to a special file? or do I have to activate something else to see them directly? sorry I'm no programmer...
following the link in the doc https://piwik.org/docs/tracking-api/#toc-debugging-the-tracking-calls I could find no solution...
In dbe8a799d7e7fc8417b13ac8838f963d6187a5dc: refs #4780 added possibility to enable tracker debug via config, use logger for printing debug messages which allows users to log to screen, file or db
I understand. It is not easy indeed, especially for non developers. I just made a change which makes it maybe at least a bit easier. It is already available if you use the version from Git, or will be available with the next beta / public release.
To enable Tracker debugging you no longer have to edit a PHP file but you can enable it in your "config/config.ini.php" as follows:
Maybe have a look whether the Tracker section in your config already exists. In this case you only have to add the line
debug = 1 ``` The next step is to enable logging to a file within your config.ini.php:
[log] log_writers = "screen" log_writers = "file"
Same here, if a line with "[log]" already exists you only have to add the two lines containing log_writers to this section. Once you enable logging to file and once there is actually something to log, a file will be created in "tmp/logs/piwik.log" within your Piwik directory. So the actual steps are: * Enable Tracker debugging * Enable log to file * Trigger the tracking (for instance by opening a page) of the website which does not trigger the scheduled tasks * Trigger the tracking (for instance by opening a page) of the website which does trigger the scheduled tasks * Copy the content of the log file (Let us know if you don't know how) * Send it to us per email * Disable logging to file and disable tracker debugging again by removing the previously added lines in the config
In 09031def185c572b0b9e88ba93d841a0a8d11e0c: refs #4780 preserve line breaks
In 92256d5b2752b85430dfe70a30dabc2afa03022e: refs #4780 forgot to commit this file
many thanks! I'll follow these great detailed instructions by the end of the week and will post the result!
@tsteur I created: #4908 so we don't forget to update doc
Cool! Please also comment here in case you are sending us an email so we can have a look in the spam folder just in case. Unfortunately, this happens sometimes...
just send you the email: it contains data from our testing environment: - 2 visits from a domain which do not trigger the cron updated - 2 visits from a domain which do trigger the cron updated
on both domains visits were tracked fine! The only problem keeps not triggering the cron update on domain 1.
Many thanks for your work!
uuurrg i messed it up: I first visited the domain which trigger the update -> you need a new log?
Yeah it would be great if you run it again for the website not triggering it. It might not trigger it as it ran before. Please wait a day if possible to make sure there are scheduled tasks
hmm just started to make the steps again, switched the debuging+logging on and wanted to make it good so I looked again in the task timetable before visiting and after visiting the first domain.
What happens? The cron/task were triggered also from the domain which do never trigger it for the last piwik (beta) versions. Do not know exactly how this could happen: there must be a change within the last 2-4 beta versions (beta 9 is installed) which "repairs" this - hmm or can it be a result because of having the debug+log activated? I'll try this again tomorrow..
checked it again - do not know why but it is working fine again now: crons /tasks are triggered by all sites => ticket can be closed (for the moment :-)
That's what I wanted to hear :) Feel free to comment in case it stops working again.
BTW: Don't forget to disable debug+log again.
I'm running v2.14.3. I've tried enabling Tracker debugging and log to file. After visiting domains to trigger the cron I don't see a generated log file + I still see negative values for tasks via the Scheduled Tasks plugin. I've looked through the related issues in here but didn't find anything that helped.
Any ideas on what else I can do to resolve this?
Ok. So i found issue #8092 just after my comment and running
./console core:run-scheduled-tasks seems to have updated the values on Scheduled Tasks page.
I'll wait and see if tasks run as scheduled now.