Querying to the LIST of running trace sessions can fail if two service API calls was done before it for a short time (Linux specifics)

[pavel-zotov]

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:

$FB_HOME/bin/fbsvcmgr action_properties dbname ... prp_write_mode prp_wm_async
$FB_HOME/bin/fbtracemgr  -start -name trace_5470 -config $tmp5470 &
sleep 3
$FB_HOME/bin/fbtracemgr -se localhost:service_mgr -list

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