Submitted by: Steffen Heil (firebirdsql.org_partner.sh-solutions.de)

Attachments:
firebird-3.0.3.32900.0-unlock.patch

During start, firebird itself as well as gfix check if the folder /tmp/firebird exists and create them if necessary.
However if two processes try that at the same time, there is a short amount of time during that the folder was created but the permissions were not adjusted yet, then one process will raise an exception.

We had real life issure with that like this:
The firebird service was started by systemd first. (Actually starting fbguard.)
Then our own service was started that first called "gfix -w" to configure forced writes and then started a java application that accesses the database.

In one out of 25 reboots firebird failed because it could not access the folder /tmp/firebird, resulting in a "Securtiy Database Error" that was infact an error in initialization of locks. We tracked it down to createLockDirectory in osutils.cpp.

We now simply fixed that by adding ExecStartPre directives to the systemd service to create and configure said folder in advance.

However I strongly think that firebird code should not create such szenarios in the first place. I will attach a patch that fixes the issue.

What I am more concerned about is that there could be a similar race condition with creating the lock *files*.
However in 16.000 reboots we did not have problems there.

So, could someone please add Information on how lock initialization is suppost to work?
Especially if two non-root users start a firebird command line tool like gfix at the same time...

Commits: eae0235 8d500d0