| Subject | Re: [firebird-support] Firebird Has To Be Manually Startred On One PC. |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-06-08T01:08:54Z |
At 07:34 AM 8/06/2008, you wrote:
To add complications, /SILENT means you won't see any messages if/when the install script bumps into errors. So, thanks to the bug, if guardian isn't running but a firebird server is, then the script won't stop executing (as it should) but will carry on regardless.
If you have completed an "as-a-service install" (stuffed-up or not), trying to start Firebird as application isn't going to cure anything - it will just make matters worse.
"Install" means multiple things. Firebird's installer script (and presumably your modified version of it) creates directories and copies files into them. After that, it invokes instsvc.exe with the appropriate switches to *install the service* (which writes the necessary stuff into the system database), again with flags as appropriate for running the specified executable. If it can, it starts the service. However, If it can't start the service, you won't know, because you're using /SILENT to suppress messages.
What you are encountering here is what you could expect when you try to install Firebird over the top of a running Firebird. You're not supposed to do that and the installer script is expected to stop if it finds a running Firebird or InterBase server.
The trouble is, it was always assumed that the test for a running server executable (fbserver.exe or fb_inet_server.exe) worked. It was not until late in the v.2.1 and v.2.0.4 release cycles that it was discovered that call actually returns negative ALWAYS if there's no guardian. It got fixed (or so we hope) for the v.2.1.0 and v.2.0.4 releases.
That late fix to the server executables is documented in the Bugfixes document sections for both v.2.1 and v.2.0.4:
http://www.firebirdsql.org/rlsnotesh/bugfix210.html#bug-210afterrc2
and the first bug report in this section:
http://www.firebirdsql.org/devel/doc/rlsnotes/html/bugfix210.html#bug20x
Bugfixes are never backported to obsolete release versions, which kinda blows away your assumptions about your "fail-safe v.2.0.1 self-install".
Just to get a bit "preachy", you do owe it to yourself to keep things up-to-date - or at least to keep abreast of what's happening in the version you're using so that you're aware of known issues as they surface. V.2.0.1 is well over a year old and has been superseded by two subsequent patch releases (a.k.a. bugfix release, subrelease, da-da-da-da, no new functionality, nothing new to break existing functionality, just bugfixes!) There's nothing quite like the release notes of the *next* patch release for alerting you to the bugs lurking in the preceding release. Documentation is available at all points during the development cycle of releases AND patch releases, both on the website and in the kits...
./heLen
>Hi Again Folks:Assuming you didn't omit the 't'.... ;-)
>
> Developing on XP Home, Visual Studio 2008, C++,
>Firebird-2.0.1.12855 - Superserver, and IBPP.
>
> Thanks to clever design by Firebird's creators, my
>app can perform a silent install of the SuperServer,
>and a user that doesn't even know what a database is
>has very nice Client - Server components up and running.
>
> Well, most users can. One user, my partner in this
>business, is having fits.
>
> I'll spare you the long story. Firebird is installed
>with:
>
> "..\..\..\inno\release_package\Firebird-2.0.1.12855-1-Win32.exe"
> /SILENT
> ServerComponent,
> ServerComponent\SuperServerComponent,
> DevAdminComponent,ClientComponen
>
> All of this is one one line.
> On my machine this means Firebird server is running,AS A SERVICE (the default on a service-capable host)
>and ready for the app to run GSEC, add a user, and changeThere's a Catch-22. You can't *complete* a no-brain service install up to the point where the newly-installed service is started if the already has a Firebird server running. The installer script is supposed to be able to detect a running server and abort if it gets a positive. The trouble is, in your v.2.0.1 environment, this isn't going to work unless the guardian is installed and running (due to a bug, see below.). But guardian isn't recommended if Firebird is being run as a service and is totally contraindicated if the Firebird service is Classic (not your case, I know), so it's not a "given" that a running server is under guardian control.
>the password.
>
> On my business partner's machine this installs Firebrid
>but doesn't start the service, which causes the password
>and account add to fail.
To add complications, /SILENT means you won't see any messages if/when the install script bumps into errors. So, thanks to the bug, if guardian isn't running but a firebird server is, then the script won't stop executing (as it should) but will carry on regardless.
> Is there a clever way to tell the server to be runningThere's no way to make a service run if that service is already running, "clever" or not.
>when Inno is finished, like it does on my machines?
> Can I test if the guardian is running?The script (or perhaps the instsvc.exe call, I'm not sure which) does that test itself. Even in obsolete versions it gets the right answer if guardian is running.
> Is there any problem if I add a command to runOf course there's a problem. Guardian running as an application will try to start fbserver.exe -a. Do you understand the differences between running as a service and running as an application?
>"fbguard.exe -a" to the install process for every install,
>even if the guardian is running?
If you have completed an "as-a-service install" (stuffed-up or not), trying to start Firebird as application isn't going to cure anything - it will just make matters worse.
"Install" means multiple things. Firebird's installer script (and presumably your modified version of it) creates directories and copies files into them. After that, it invokes instsvc.exe with the appropriate switches to *install the service* (which writes the necessary stuff into the system database), again with flags as appropriate for running the specified executable. If it can, it starts the service. However, If it can't start the service, you won't know, because you're using /SILENT to suppress messages.
What you are encountering here is what you could expect when you try to install Firebird over the top of a running Firebird. You're not supposed to do that and the installer script is expected to stop if it finds a running Firebird or InterBase server.
The trouble is, it was always assumed that the test for a running server executable (fbserver.exe or fb_inet_server.exe) worked. It was not until late in the v.2.1 and v.2.0.4 release cycles that it was discovered that call actually returns negative ALWAYS if there's no guardian. It got fixed (or so we hope) for the v.2.1.0 and v.2.0.4 releases.
That late fix to the server executables is documented in the Bugfixes document sections for both v.2.1 and v.2.0.4:
http://www.firebirdsql.org/rlsnotesh/bugfix210.html#bug-210afterrc2
and the first bug report in this section:
http://www.firebirdsql.org/devel/doc/rlsnotes/html/bugfix210.html#bug20x
Bugfixes are never backported to obsolete release versions, which kinda blows away your assumptions about your "fail-safe v.2.0.1 self-install".
Just to get a bit "preachy", you do owe it to yourself to keep things up-to-date - or at least to keep abreast of what's happening in the version you're using so that you're aware of known issues as they surface. V.2.0.1 is well over a year old and has been superseded by two subsequent patch releases (a.k.a. bugfix release, subrelease, da-da-da-da, no new functionality, nothing new to break existing functionality, just bugfixes!) There's nothing quite like the release notes of the *next* patch release for alerting you to the bugs lurking in the preceding release. Documentation is available at all points during the development cycle of releases AND patch releases, both on the website and in the kits...
./heLen