New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Append the IP address of the remote host to error messages in firebird.log for TCP connections [CORE2493] #2906
Comments
Modified by: @dyemanovpriority: Major [ 3 ] => Minor [ 4 ] summary: Please, add IP address of remote host to error messages in firebird.log for TCP connections. => Append the IP address of the remote host to error messages in firebird.log for TCP connections Version: 2.5 Beta 1 [ 10251 ] => |
Commented by: @ibaseru I wan to raise interest to this, because Interbase already have things like that: IBASE (Server) Sat Mar 10 18:56:02 2007 |
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovFix Version: 3.0 Alpha 1 [ 10331 ] |
Commented by: @dyemanov I'm thinking about the following change in the output. Now:
To be:
Does it look suitable? Or perhaps it's too much verbose? |
Commented by: @dyemanov A shorter alternative:
|
Commented by: @pmakowski I like the last one (A shorter alternative) |
Commented by: @sim1984 Whether it is impossible to add this improvement in 2.5.2? |
Commented by: @dyemanov Not for 2.5.2 for sure. |
Modified by: @dyemanovstatus: Open [ 1 ] => In Progress [ 3 ] |
Commented by: @sim1984 Add there a line of connection |
Commented by: @dyemanov I doubt this is possible in general, as the network layer is isolated from the engine. Theoretically, a database pathname / alias could be gathered from the op_attach packet and stored for the reporting purposes, but surely not the host name. Also, what db info to report if the network error happens with the listener socket in SS/SC? It multiplexes all the connections, so it seems impossible to report a db info properly. So I tend to reject this idea. |
Commented by: @sim1984 In principle I agree. The purpose of this message to clarify a problem with communication links with computers of clients. It is for this purpose optional to know a name DB. |
Commented by: Jesus Angel Garcia Zarco (cointec) If it is feasible, backport to version 2.5.X the information that is posible to record. |
Commented by: @dyemanov I'm about to commit the simplest solution, based on the already available information in the remote subsystem. // No connection was established // Established connection (client-side) // Established connection (server-side) Would it be acceptable for v3? Later we could add more context information, if required. |
Commented by: @sim1984 This is the right decision not to delay the release of Fb3. The only caveat - the original version of your proposed text of the error message was more detailed (I do not take parameters, only the text itself). |
Commented by: @dyemanov The "original version" was taken from the top of my head, the latest one is based on the existing code. We could translate network error codes into text, but I'm not sure we should (everyone can google). We could add client process info for server-side messages, but it requires more coding. |
Modified by: @dyemanovstatus: In Progress [ 3 ] => Open [ 1 ] |
Modified by: @hvladassignee: Dmitry Yemanov [ dimitr ] => Vlad Khorsun [ hvlad ] |
Commented by: @hvlad Log message now looks like INET/inet_error: <routine_name> errno = <error_number> [, <peer_Info>] [, <user_info>] where <peer_Info> ::= <user_info> ::= <peer_kind> ::= [aux] client|server [aux] client|server - kind of connection with peer: <peer_name> - name of the peer host: <peer_address> - IP address and port reported by getnameinfo() API function <user_name> - authenticated Firebird login name, coupd be reported by server side Examples: b) client detect abnormal disconnect |
Commented by: @pavel-zotov I could reproduce 10053 using this scenario: isql-1: isql-2: isql-1: firebird.log: CSPROG Tue Jan 12 09:21:32 2016 NOTE: message "SEND errno = 10053" was added, not "READ errno = 10053" (as you've wrote). Is this result expected ? Can message "read errno = 10053, server host ..." be reproduced by some other way, not using ES / EDS ? PS. Message: INET/inet_error: read errno = 10054, client host = ..., address = ..., user = ... - does appear in firebird.log when either ISQL process is forcely kiled (by pskill et al) or its window is closed or by pressing Ctrl-Break inside ISQL when it idle or does something; But this message (and none at all) do NOT appear when either ISQL session is closed due to gfix -shut full -force 0, or because of delete from mon$attachments. |
Commented by: @hvlad > Is this result expected ? > Can message "read errno = 10053, server host ..." be reproduced by some other way, not using ES / EDS ? > Is it correct ? |
Commented by: @pavel-zotov >> Can message "read errno = 10053, server host ..." be reproduced by some other way, not using ES / EDS ? Can you please tell me what's this ? (I mean that it should differ from ES/EDS) >But why do you need exactly this message ? Just for making new .fbt that will be useful (IMO) for this ticket. |
Commented by: @hvlad >>> Can message "read errno = 10053, server host ..." be reproduced by some other way, not using ES / EDS ? read error could happen when ... read return error (aborted, for example). > Just for making new .fbt that will be useful (IMO) for this ticket. I still don't understand how *failed operation name* is related with this ticket (which is about reporting *peer name\address*) |
Commented by: @pavel-zotov > I still don't understand how *failed operation name* is related with this ticket (which is about reporting *peer name\address*) I'm not interested about OPERATION that failed; the only what's matter - content of firebird.log and parsing 10054 & 10053 lines :-) In the post 10/Jan/16 11:11 PM you've wrote that firebird.log can contain message:b) client detect abnormal disconnect
|
Commented by: @dyemanov Better ignore everything between "inet_error:" and "errno" tokens. |
Commented by: @pavel-zotov echo set list on; ^ MON$REMOTE_ADDRESS fe80::c40e:21ec:b5c7:8963%3/56831 -- then it hangs and we terminate it by pressing Ctrl-Break --- type firebird.log INET/inet_error: read errno = 10054, client host = oksana, address = fe80::c40e:21ec:b5c7:8963/56831, user = oksana1 NOTE: percent sign present when returning from mon$attachments and absent when data are written into fb.log. Why ? |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: Done with caveats Test Details: Test verifies that only ONE of pair messages is really added to firebird.log - 10053. It seems that it is unable to implement test which will lead to appearance of 10054 because in such case engine keeps DB file opened after killing launched ISQL process which is done ES/EDS. |
Commented by: @hvlad Because printf is crazy, when have format specifier with no arguments. Docs: The results are undefined if there are not enough arguments for all the format specifications. Fixed. |
Commented by: @hvlad Backported into v2.5.9 |
Modified by: @hvladFix Version: 2.5.9 [ 10862 ] |
Commented by: @pavel-zotov Message in firebird.log slightly differ in 2.5.9 vs 3.0.4: 3.0.4: 2.5.9.does not contain "client host = <name>" and *does* contain some suffix after user name (which is in uppercase). |
Submitted by: John Kilin (johnkilin)
Votes: 15
Commits: b7d8f28 737b5f8 9e5c39a 2820ede FirebirdSQL/fbt-repository@608b7d3 FirebirdSQL/fbt-repository@ee456a8 FirebirdSQL/fbt-repository@c620f65 FirebirdSQL/fbt-repository@7bdd463
====== Test Details ======
Test verifies that only ONE of pair messages is really added to firebird.log - 10053.
It seems that it is unable to implement test which will lead to appearance of 10054 because in such case engine keeps DB file opened after killing launched ISQL process which is done ES/EDS.
When this file has name = "initial" ('bugs.core_2493.fdb") then fb_test will raise exception on cleanup phase. Otherwise one can not to remove this (new) .fdb-file when test is finished.
It seems that DB file is kept opened such too long time only under fb_test env., so I will investigate this later.
The text was updated successfully, but these errors were encountered: