Could Tracy cause this: "Error: Exception: Unable to obtain lock for session (retry in 30s)"

[Ivan Gretsky]

Good day, @adrian!

Today I am having some large traffic on a project. And there stated to appear a lot of 500 errors like this: Error:  Exception: Unable to obtain lock for session (retry in 30s). I have found this thread, turned off Tracy (which was id Development mode, but limited with tracy-debugger permission) and it seemed to help. Could you please explain if that is expected. Do we need to fix Tracy? Or the best practice is to have it off/in PRODUCTION mode on prod?

Thanks!

[adrian]

Hi Ivan - it looks like you are also running SessionHandlerDB (as mentioned by the folks in that other thread).

I have found many issues with Tracy and that module over the years so I don't run that module (except when testing) and haven't ever seen that error. 

For now (if you don't need it, I would suggest disabling that module), but I would like to see if @ryan has any ideas.

[netcarver]

Just speculating about the SessionHandlerDB link: could this be caused by locking on the session table if there's a long running process holding a connection open somehow?

[adrian]

@Ivan Gretsky - if you can reproduce this reliably, I wonder if you could determine if $locked is 0 vs null: https://github.com/processwire/processwire/blob/6ff498f503db118d5b6c190b35bd937b38b80a77/wire/modules/Session/SessionHandlerDB/SessionHandlerDB.module#L90-L91

If it's null and it's a memory issue, then perhaps increasing your PHP memory limit might fix it?

[netcarver]

@Ivan Gretsky If you do have a reliable reproduction process, can you try replacing the SessionHandlerDB.module file with this one (everyone will be logged out when you try it) - and keep an eye out for any new entries in the "session-errors" log file.

SessionHandlerDB.module

[netcarver]

Here's a newer version of my spin on SessionHandlerDB that should handle a couple of edge cases. Please let me know if this is an improvement for you.

Spoiler

Specifically, it releases locks

• as many times as needed (in case session_reset() was called somewhere causing a second call to SessionHandler::read() - in which case the lock could be owned more than once by the same process, needing multiple releases.)
• as part of the SessionHandler::destroy() method called from PHP's session_destroy() call or session_regenerate_id(true).

SessionHandlerDB.module

[Ivan Gretsky]

On 4/12/2023 at 11:12 PM, netcarver said:

...and keep an eye out for any new entries in the "session-errors" log file.

I have installed the modified module. But there was no records in session-errors logs file. In fact it has not even been created. And it didn't solve the issue as far as I can tell as the mentioned error didn't go away.

With Tracy turned off it appeared less often but still did.

I think that long and heavy DB queries do cause this.

[netcarver]

Hello Ivan, thanks for trying that out - the session-errors log is only created if there's an issue obtaining a lock. If there are no issues, you won't see an entry there.