@hpvd opened this issue on February 28th 2014

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

@hpvd commented on February 28th 2014
@hpvd commented on March 4th 2014
@hpvd commented on March 14th 2014
@hpvd commented on March 14th 2014
@hpvd commented on February 28th 2014

current version: 2.1RC9 (no update shown)

## details of last fix:

#4263

finally fixed by fixing: #4612

see also: #4652

## now everything works fine!

=> hopefully we can say this again soon :-)

@hpvd commented on March 4th 2014

still not working in 2.1 final

Please see new attachment.

@tsteur commented on March 13th 2014

Hi there,

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

[Tracker]
scheduled_tasks_min_interval

and can you check the value of the option "lastTrackerCronRun" in the database "option" table?

There have been tracking visits since mid february right?

@hpvd commented on March 13th 2014

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...

Many thanks!!

@tsteur commented on March 13th 2014

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.

@hpvd commented on March 14th 2014

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...

@hpvd commented on March 14th 2014

the problem is reproduceable. See new screenshots.

@tsteur commented on March 17th 2014

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;

to

$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.

@hpvd commented on March 18th 2014

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...

@hpvd commented on March 18th 2014

following the link in the doc https://piwik.org/docs/tracking-api/#toc-debugging-the-tracking-calls I could find no solution...

@tsteur commented on March 24th 2014

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

@tsteur commented on March 24th 2014

Hi,

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:

[Tracker]
debug=1

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

@tsteur commented on March 24th 2014

In 09031def185c572b0b9e88ba93d841a0a8d11e0c: refs #4780 preserve line breaks

@tsteur commented on March 24th 2014

In 92256d5b2752b85430dfe70a30dabc2afa03022e: refs #4780 forgot to commit this file

@hpvd commented on March 25th 2014

many thanks! I'll follow these great detailed instructions by the end of the week and will post the result!

@mattab commented on March 26th 2014

@tsteur I created: #4908 so we don't forget to update doc

@tsteur commented on March 26th 2014

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...

@hpvd commented on March 27th 2014

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!

@hpvd commented on March 27th 2014

uuurrg i messed it up: I first visited the domain which trigger the update -> you need a new log?

@tsteur commented on March 27th 2014

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

@hpvd commented on March 29th 2014

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..

@hpvd commented on March 30th 2014

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 :-)

@tsteur commented on March 30th 2014

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.

@colinwilson commented on August 19th 2015

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?

@colinwilson commented on August 19th 2015

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.

This issue was closed on April 1st 2014
Powered by GitHub Issue Mirror