Bug in FB2.0 Setup. Setup program don't detect runned server. [CORE1820] #2250
Submitted by: Vit Kanevsky (vitk)
In case of installing firebird server 126.96.36.19982 (and probably all other of 2.0 family) with the option "Guardian controlling server" swithed off, setup program don't detect runned server and try to overwrite it, with an appropriate errors, while trying to rewrite fbserver.exe and all of DLLs.
Setup detect a runned server as here (Innosetup code fragment from original setup program):
function FirebirdDefaultServerRunning: boolean;
//Look for a running version of Firebird 1.5 or later
if (Handle > 0) then
Researching of runned server by Handles.exe shows the next:
There are no named mutexes with names FirebirdGuardianMutex or FirebirdServerMutex.
In case of installing firebird with guardian swithed on, mutex FirebirdGuardianMutex created and setup works good, but with the guardian switched off there are no thats mutexes.
There are 2 named mutexes in server FIREBIRD_CONNECT_MUTEX & firebird_trace_mutex.
The text was updated successfully, but these errors were encountered:
Commented by: @reevespaul
FB_Disabled, FB_Server, FB_Guard were all used in previous versions, which is why the test exists.
Testing for FirebirdServerMutex demonstrates a certain amount of optimism, considering this mutex has never existed.
However, the underlying problem is that this area has always been a bad hack. Neither InterBase before us, nor Firebird since has paid proper attention to this issue.
Now is probably not the best time to add a new mutex. FIREBIRD_CONNECT_MUTEX wont work, because it is actually declared as %s_CONNECT_MUTEX and there is no guarantee that the prefix will be FIREBIRD.
This leaves us with adding a test for firebird_trace_mutex. As the change only affects the binary installer there is a good chance we can get this into 2.0.4. Unfortunately it is not likely to be in the release candidate, which is currently in QA.
Commented by: @dyemanov
firebird_trace_mutex is a debugging facility that can disappear in some future build, so it doesn't look like a good option. Also, this mutex exists in the client library as well, so the check could fail if some other version of fbembed.dll is loaded by a running application.
Commented by: @reevespaul
Actually, it doesn't matter if firebird_trace_mutex disappears in a future version - the tests are version specific. But the fact that it is in the client library means it won't work.
I don't think that EnumProcesses + OpenProcess + GetProcessImageFileName is easily available within InnoSetup. They could be made available by making various declarations (heck, we could even create our own install.dll and declare it if we wanted to) but I'd rather keep things as simple as possible. It looks like the correct solution is to actually create the FirebirdServerMutex, although this will mean a change to the engine code.
Alternatively, how reliable is FIREBIRD_CONNECT_MUTEX? Doesn't this depend on a value in firebird.conf?