Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Piwik should not require mysql LOCK privilege so more users can enjoy Free Web Analytics! #3204

Closed
mattab opened this issue Jun 7, 2012 · 6 comments
Labels
Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical. Task Indicates an issue is neither a feature nor a bug and it's purely a "technical" change.
Milestone

Comments

@mattab
Copy link
Member

mattab commented Jun 7, 2012

Since Piwik 1.8 (tickets #2984 and log deletion #2805), we require the LOCK privilege to install Piwik. Apparently, some web hosts have disabled it and refuse to enable it.

If you experience the problem that your web host does not allow LOCK privilege on the piwik mysql user, but you would like to use Piwik, please comment in this ticket. Thank you!

@diosmosis
Copy link
Member

(In [6483]) Fixes #3204, removed LOCK TABLES privilege check from installation. Modified LogDataPurger so log_actions are not purged if the lock tables privilege is not granted.

@diosmosis
Copy link
Member

Committed a fix for this, but there's still one other instance of LOCK TABLES in ArchiveProcessing::loadNextIdarchive. I don't think its necessary, but I didn't write the code so I've left it for now. Is locking necessary here? If it is, I think it can be replaced w/ GET_LOCK.

@mattab
Copy link
Member Author

mattab commented Jun 18, 2012

It is "necessary" to make sure that when several archives are requested at the same time, they have a distinct idarchive allocated. Sounds good if we can use GET_LOCK instead. Could we not use GET_LOCK for the log deletion from log_action as well btw?

Also it would be nice to say in the UI, in the inline help "The table log_action will not be purged: please grant the LOCK privilege to the %s Mysql user" so that users understand that the feature is limited pending the privilege.

@diosmosis
Copy link
Member

Replying to matt:

It is "necessary" to make sure that when several archives are requested at the same time, they have a distinct idarchive allocated. Sounds good if we can use GET_LOCK instead. Could we not use GET_LOCK for the log deletion from log_action as well btw?

The reason I think the locking might not be necessary is that the INSERT INTO SELECT should lock the table itself. Do you know of a situation where it wouldn't?

And I don't think GET_LOCK will work for log_action purging. For log_action purging we need to make sure no visits/link_actions/conversions/etc. are added while actions are being deleted and GET_LOCK won't do that (unless you add a GET_LOCK call to the Tracker).

Also it would be nice to say in the UI, in the inline help "The table log_action will not be purged: please grant the LOCK privilege to the %s Mysql user" so that users understand that the feature is limited pending the privilege.

Ok, will get to it soon...

@mattab
Copy link
Member Author

mattab commented Jun 19, 2012

The reason I think the locking might not be necessary is that the INSERT INTO SELECT should lock the table itself. Do you know of a situation where it wouldn't?

maybe a GET_LOCK would be enough here....? but we need the lock.
it was a patch suggested by power user lorieri which fixes an edge case bug hard to reproduce, so I'm reluctant to break it again by removing the lock :)

And I don't think GET_LOCK will work for log_action purging.
Thanks for reminding me.

@diosmosis
Copy link
Member

(In [6485]) Refs #3204, added extra info message to privacy manager purge function when lock tables privilege is not granted to user & replaced lock tables sql in ArchiveProcessing w/ GET_LOCK.

Notes:

  • Added Piwik_GetDbLock & Piwik_ReleaseDbLock functions.

@mattab mattab added this to the 1.x - Piwik 1.x milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical. Task Indicates an issue is neither a feature nor a bug and it's purely a "technical" change.
Projects
None yet
Development

No branches or pull requests

2 participants