| Subject | Re: [firebird-support] INET/inet_error: connect errno = 111 - absolutely expected? |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-01-09T03:18:33Z |
At 11:49 AM 9/01/2008, you wrote:
The fbmgr utility is a front-end script to a binary (fbmgr.bin) that can be used to start up the fbserver executable (which is the service). In the normal course of things, i.e., at bootup, the OS user 'firebird' calls fbmgr.bin directly to start the service. The user 'firebird' is privileged and not subject to authentication. If you did a standard install of FirebirdSS from the distribution kit (RPM or via the tarball and scripts) fbserver is started automatically on a machine reboot, by user firebird. In reality, there's no reason why you even have to be concerned about fbmgr. It's a bit like ambulance insurance.
Once fbserver is running, it is listening for client connection requests. If fbmgr is used to stop, or to stop and restart, the server, only SYSDBA can do that and the SYSDBA password (but not the username) is a required switch. Since the server is running, the authentication of the SYSDBA login is just as normal.
A 111 error on an attempt to do a stop/restart would indicate that the server wasn't running. At this level, it might also indicate that you either forgot to supply the password, or the password was wrong (though the "invalid username or password" exception might prevail at this level) or that you tried to supply both a username and password. If you try to do an fbmgr -start (rather than a restart) by explicitly supplying the SYSDBA credentials, when you're not root or firebird, you might get a 111. (Firebird is rather particular about who starts it!)
Anyway - consider it (and the follow-up questions) irrelevant to Firebird. You get a 111 error ("connection refused") when a client tries to connect to a Firebird server that isn't running; or one that, although running, has the Firebird service port fire-walled or otherwise tied up. If the Firebird SS service is running and its service port (usually 3050) is open then you don't get a 111 error.
You're likely to see one if someone used fbmgr to stop and restart fbserver and the restart is still under way when a client tries to [re]connect. The same conditions might occur if fbserver has crashed and the guardian is still in the process of trying to restart it. (Guardian uses the firebird user credentials as well.) I think you probably get a 111 if you try to start a server that's already running, as well.
./heLen
>There are a number of messages in this group and other resourcesNot surprising - INET/inet_error signals only an error received from the network layer. Firebird doesn't have any way to interpret network errors, so they're just "for information only". Often an INET error is preceded or followed by an error message from the engine or the remote interface, although not always. Many, if not most, network errors are benign from Firebird's POV. Error 111 does tend to be a bit of a showstopper, though. ;-)
>concerning the ``INET/inet_error: connect errno = 111'' message in the
>{interbase,firebird}.log. It's not covered, per se, in the
>firebirdsql.org FAQ.
>Since this is where the experts are found -- can we have anI've never seen a 111 error in my firebird logs. But, if you want "absolutely" and "authoritative" you're asking in the wrong place. Ask that on firebird-devel. On the whole, this 'ere's the dining room, not the kitchen.
>authoritative statement that, at service startup with Firebird (or
>Interbase) SS startup, precisely one such message is expected and
>normal. I presume it's due to fbmgr (or ibmgr) attempting to connect
>before the server has begun listening.
The fbmgr utility is a front-end script to a binary (fbmgr.bin) that can be used to start up the fbserver executable (which is the service). In the normal course of things, i.e., at bootup, the OS user 'firebird' calls fbmgr.bin directly to start the service. The user 'firebird' is privileged and not subject to authentication. If you did a standard install of FirebirdSS from the distribution kit (RPM or via the tarball and scripts) fbserver is started automatically on a machine reboot, by user firebird. In reality, there's no reason why you even have to be concerned about fbmgr. It's a bit like ambulance insurance.
Once fbserver is running, it is listening for client connection requests. If fbmgr is used to stop, or to stop and restart, the server, only SYSDBA can do that and the SYSDBA password (but not the username) is a required switch. Since the server is running, the authentication of the SYSDBA login is just as normal.
A 111 error on an attempt to do a stop/restart would indicate that the server wasn't running. At this level, it might also indicate that you either forgot to supply the password, or the password was wrong (though the "invalid username or password" exception might prevail at this level) or that you tried to supply both a username and password. If you try to do an fbmgr -start (rather than a restart) by explicitly supplying the SYSDBA credentials, when you're not root or firebird, you might get a 111. (Firebird is rather particular about who starts it!)
>This issue is covered at http://dn.codegear.com/article/27663. But IFor InterBase 6.0.x (see the date? August 2001!!), not Firebird. According to that article, fbmgr "immediately" tries to connect to isc4.gdb (that's the IB name for the security database) when it's called with the -start switch. Well, it might have been true of IB 6.0.1, I don't remember. AFAIR, there was something about needing to be root or SYSDBA to start IB 6. Superserver on Linux was (to say the least!) experimental in IB 6.0.
>am unaware of the credentials of the author. Moreover, there are a
>couple of unanswered followup queries asking if there were plans to
>eliminate this error message (since it is normal).
Anyway - consider it (and the follow-up questions) irrelevant to Firebird. You get a 111 error ("connection refused") when a client tries to connect to a Firebird server that isn't running; or one that, although running, has the Firebird service port fire-walled or otherwise tied up. If the Firebird SS service is running and its service port (usually 3050) is open then you don't get a 111 error.
You're likely to see one if someone used fbmgr to stop and restart fbserver and the restart is still under way when a client tries to [re]connect. The same conditions might occur if fbserver has crashed and the guardian is still in the process of trying to restart it. (Guardian uses the firebird user credentials as well.) I think you probably get a 111 if you try to start a server that's already running, as well.
>...and while I'm on a roll, short of changing the source code, isYou can't "configure Firebird's logging". In Firebird 2.1 you can write database triggers, from which you can write whatever you want to custom logs at both connection and transaction level, to your heart's content.
>there a way to configure Firebird's logging so that each new client
>connection and disconnect to the server is logged (a la PostgreSQL's
>``log_connections'' parameter).
./heLen