You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(one may to use any number >=1 as argument to 'sleep' command - it's no matter)
When FIRST of them is started, it creates file 'fbNN_trace' - this is done in order to be able to be traced (by trace session that could be started in another windows).
This file will be deleted at the end of this command, when client and server will close their network ports.
But client can close its attachment faster than server, and thus it will immediately starts SECOND command, which also requires creation of fbNN_trace.
On Linux this will lead to opening by client existing file fbNN_trace file - because server not yet completed deletion of it.
Finally, server process (that was created by first command) successfully completes deletion - this can be done on Linux w/o any problem, even if fbNN_trace file is already opened by another program.
Second process (fbtracemgr) will not be broken, but the LAST command, which queries LIST of trace sessions, will FAIL: empty list will be returned instead of ID of active trace session.
Perhaps, this problem can also be seen on Super[Classic], but I did not encounter it on these modes (i.e. problem was found only for Classic).
The text was updated successfully, but these errors were encountered:
Ticket was created by request from Alex, after discussion about weird hanging of new QA test suite based on pytest.
Subsequent calls of services API can lead to problem with access to /tmp/firebird/fbNN_trace file when ServerMode = Classic.
Consider following .sh script with two commands:
(one may to use any number >=1 as argument to 'sleep' command - it's no matter)
When FIRST of them is started, it creates file 'fbNN_trace' - this is done in order to be able to be traced (by trace session that could be started in another windows).
This file will be deleted at the end of this command, when client and server will close their network ports.
But client can close its attachment faster than server, and thus it will immediately starts SECOND command, which also requires creation of fbNN_trace.
On Linux this will lead to opening by client existing file fbNN_trace file - because server not yet completed deletion of it.
Finally, server process (that was created by first command) successfully completes deletion - this can be done on Linux w/o any problem, even if fbNN_trace file is already opened by another program.
Second process (fbtracemgr) will not be broken, but the LAST command, which queries LIST of trace sessions, will FAIL: empty list will be returned instead of ID of active trace session.
Perhaps, this problem can also be seen on Super[Classic], but I did not encounter it on these modes (i.e. problem was found only for Classic).
The text was updated successfully, but these errors were encountered: