Bug 175485
| Summary: | port databases/firebird25-server (classic) keeps attached to security2.fdb for each connection | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Haris Papadopoulos <haris> |
| Component: | Individual Port(s) | Assignee: | Jose Alonso Cardenas Marquez <acm> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Haris Papadopoulos
2013-01-21 19:10:00 UTC
Responsible Changed From-To: freebsd-ports-bugs->acm Over to maintainer (via the GNATS Auto Assign Tool) State Changed From-To: open->feedback - firebird25-* ports have been updated. Pleas, could you test it again? I 've managed to setup a new laptop: 9.1-STABLE FreeBSD 9.1-STABLE #0 r249094: amd64 and I built and installed the new version successfully from ports: # isql-fb -z ISQL Version: FB-V2.5.2.26540 Firebird 2.5 I setup fbtrace.conf so that I could give you a complete feedback. Unfortunately, icu(obviously) stopped me. From firebird.log: Trace plugin libfbtrace.so returned error on call trace_create. Error details: cannot initialize UNICODE collation to use in trace plugin icu version: 50.1.2 built from ports. I can only confirm that fuser command still shows attachments to security2.fdb by the same processes that hold the actual connections to the database. I created an empty testdb.fdb, and connected to it from: 1. SQuirrel SQL using Jaybird driver and Classic server(/usr/local/sbin/fb_inet_server) 2. isql-fb # ps -axfw | grep fb_inet 41417 ?? Is 0:00,04 fb_inet_server # ps -axfw | grep isql 55581 1 I+ 0:00,05 isql-fb -USER SYSDBA -PASS masterkey # fuser /var/db/firebird/security2.fdb /var/db/firebird/security2.fdb: 55581w 41417w The above attachments will stay there until the connections are closed. Haris State Changed From-To: feedback->closed - It has been fixed with my latest commit. Please, update your ports tree and tell me if you have the same firebird problems I can confirm that icu issue has been fixed. However, the issue with the
security2.fdb attachments still remains. I have the audit trace log
now(only for security2.fdb):
2013-10-02T16:56:07.8500 (2361:0x8006fbc18) TRACE_INIT
SESSION_1 Firebird Audit
2013-10-02T16:56:07.8500 (2361:0x8006fbc18) ATTACH_DATABASE
/var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE,
<internal>)
2013-10-02T16:56:07.8510 (2361:0x8006fbc18) COMPILE_BLR
/var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE,
<internal>)
-------------------------------------------------------------------------------
0 blr_version5,
1 blr_begin,
2 blr_message, 1, 4,0,
6 blr_long, 0,
8 blr_long, 0,
10 blr_short, 0,
12 blr_text, 66,0,
15 blr_message, 0, 1,0,
19 blr_cstring, 129,0,
22 blr_receive, 0,
24 blr_begin,
25 blr_for,
26 blr_rse, 1,
28 blr_relation, 9,
'R','D','B','$','U','S','E','R','S', 0,
40 blr_first,
41 blr_literal, blr_short, 0, 1,0,
46 blr_boolean,
47 blr_eql,
48 blr_field, 0, 13,
'R','D','B','$','U','S','E','R','_','N','A','M','E',
64 blr_parameter, 0, 0,0,
68 blr_end,
69 blr_send, 1,
71 blr_begin,
72 blr_assignment,
73 blr_field, 0, 7, 'R','D','B','$','G','I','D',
83 blr_parameter, 1, 0,0,
87 blr_assignment,
88 blr_field, 0, 7, 'R','D','B','$','U','I','D',
98 blr_parameter, 1, 1,0,
102 blr_assignment,
103 blr_literal, blr_short, 0, 1,0,
108 blr_parameter, 1, 2,0,
112 blr_assignment,
113 blr_field, 0, 10,
'R','D','B','$','P','A','S','S','W','D',
126 blr_parameter, 1, 3,0,
130 blr_end,
131 blr_send, 1,
133 blr_assignment,
134 blr_literal, blr_short, 0, 0,0,
139 blr_parameter, 1, 2,0,
143 blr_end,
144 blr_end,
145 blr_eoc
0 ms
2013-10-02T16:56:07.8520 (2361:0x8006fbc18) START_TRANSACTION
/var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE,
<internal>)
(TRA_126, CONCURRENCY | WAIT | READ_ONLY)
2013-10-02T16:56:07.8540 (2361:0x8006fbc18) ROLLBACK_TRANSACTION
/var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE,
<internal>)
(TRA_126, CONCURRENCY | WAIT | READ_ONLY)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)
2013-10-02T17:03:51.6320 (2361:0x8006fbc18) DETACH_DATABASE
/var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE,
<internal>)
2013-10-02T17:03:51.6320 (2361:0x8006fbc18) TRACE_FINI
SESSION_1 Firebird Audit
Note the time difference for the DETACH_DATABASE. It happens when the
connection to the database is closed.
/Haris
2013/10/2 Haris Papadopoulos <haris@softways.gr> > The following reply was made to PR ports/175485; it has been noted by > GNATS. > > From: Haris Papadopoulos <haris@softways.gr> > To: bug-followup@FreeBSD.org, haris@softways.gr > Cc: > Subject: Re: ports/175485: port databases/firebird25-server (classic) keeps > attached to security2.fdb for each connection > Date: Wed, 02 Oct 2013 17:12:30 +0300 > > I can confirm that icu issue has been fixed. However, the issue with the > security2.fdb attachments still remains. I have the audit trace log > now(only for security2.fdb): > > 2013-10-02T16:56:07.8500 (2361:0x8006fbc18) TRACE_INIT > SESSION_1 Firebird Audit > > > 2013-10-02T16:56:07.8500 (2361:0x8006fbc18) ATTACH_DATABASE > /var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE, > <internal>) > > 2013-10-02T16:56:07.8510 (2361:0x8006fbc18) COMPILE_BLR > /var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE, > <internal>) > > ------------------------------------------------------------------------------- > 0 blr_version5, > 1 blr_begin, > 2 blr_message, 1, 4,0, > 6 blr_long, 0, > 8 blr_long, 0, > 10 blr_short, 0, > 12 blr_text, 66,0, > 15 blr_message, 0, 1,0, > 19 blr_cstring, 129,0, > 22 blr_receive, 0, > 24 blr_begin, > 25 blr_for, > 26 blr_rse, 1, > 28 blr_relation, 9, > 'R','D','B','$','U','S','E','R','S', 0, > 40 blr_first, > 41 blr_literal, blr_short, 0, 1,0, > 46 blr_boolean, > 47 blr_eql, > 48 blr_field, 0, 13, > 'R','D','B','$','U','S','E','R','_','N','A','M','E', > 64 blr_parameter, 0, 0,0, > 68 blr_end, > 69 blr_send, 1, > 71 blr_begin, > 72 blr_assignment, > 73 blr_field, 0, 7, 'R','D','B','$','G','I','D', > 83 blr_parameter, 1, 0,0, > 87 blr_assignment, > 88 blr_field, 0, 7, 'R','D','B','$','U','I','D', > 98 blr_parameter, 1, 1,0, > 102 blr_assignment, > 103 blr_literal, blr_short, 0, 1,0, > 108 blr_parameter, 1, 2,0, > 112 blr_assignment, > 113 blr_field, 0, 10, > 'R','D','B','$','P','A','S','S','W','D', > 126 blr_parameter, 1, 3,0, > 130 blr_end, > 131 blr_send, 1, > 133 blr_assignment, > 134 blr_literal, blr_short, 0, 0,0, > 139 blr_parameter, 1, 2,0, > 143 blr_end, > 144 blr_end, > 145 blr_eoc > > 0 ms > 2013-10-02T16:56:07.8520 (2361:0x8006fbc18) START_TRANSACTION > /var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE, > <internal>) > (TRA_126, CONCURRENCY | WAIT | READ_ONLY) > > 2013-10-02T16:56:07.8540 (2361:0x8006fbc18) ROLLBACK_TRANSACTION > /var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE, > <internal>) > (TRA_126, CONCURRENCY | WAIT | READ_ONLY) > 0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s) > > 2013-10-02T17:03:51.6320 (2361:0x8006fbc18) DETACH_DATABASE > /var/db/firebird/security2.fdb (ATT_320, SYSDBA:NONE, NONE, > <internal>) > > 2013-10-02T17:03:51.6320 (2361:0x8006fbc18) TRACE_FINI > SESSION_1 Firebird Audit > > Note the time difference for the DETACH_DATABASE. It happens when the > connection to the database is closed. > > /Haris > Hi Haris if you use firebird like classic server this'll create connections by each session to security2 database. isql-fb -USER SYSDBA -PASS masterkey 'localhost:/var/db/firebird/firstdb.fdb' but if you use firebird like super classic, the connections are managed via network layer (firebird_server="YES" into /etc/rc.conf). this'll create just one connection to security2 database isql-fb -USER SYSDBA -PASS masterkey 'localhost:/var/db/firebird/firstdb.fdb' fuser - firebird classic server for 4 connections: [root@hellfire]# fuser /var/db/firebird/security2.fdb /var/db/firebird/security2.fdb: 75893w 75885w 75884w 75871w fuser - firebird super classic for 4 connections: [root@hellfire]# fuser /var/db/firebird/security2.fdb /var/db/firebird/security2.fdb: 75845w Maybe you could look at http://www.firebirdsql.org/manual/qsg25-appx-architectures.html. If I'm not mistaken multiple connections to security2 on classic server are normals. Greetings ACM Hi, I 'm sorry to say that this doesn't work for me. I have: firebird_enable="YES" firebird_server="YES" in /etc/rc.conf root@raindog:~ # pkg_info | grep firebird firebird-client-2.5.2_2 Firebird-2 database client firebird-server-2.5.2_2 Firebird-2 relational database (server) root@raindog:~ # isql-fb -z ISQL Version: FB-V2.5.2.26540 Firebird 2.5 root@raindog:~ # uname -a FreeBSD raindog.softways.lan 9.1-STABLE FreeBSD 9.1-STABLE #1: Sat Aug 31 10:26:40 EEST 2013 root@raindog.softways.lan:/usr/obj/usr/src/sys/MYKERNEL amd64 root@raindog:~ # ps -axfw | grep fb_smp 2290 0 I 0:00,15 /usr/local/sbin/fb_smp_server and I still see as many connections to security2.fdb as the connections to the actual database. I can also understand that for fb_inet_server multiple connections would be OK but how can one explain that Firebird 2.1.x fb_inet_server does not keep these connections open. Anyway, I don't know what else to check and it surely bothers me that Classic Superserver works for you. Thanks again, Greetings /Haris 2013/10/4 Haris Papadopoulos <haris@softways.gr> > The following reply was made to PR ports/175485; it has been noted by > GNATS. > > From: Haris Papadopoulos <haris@softways.gr> > To: bug-followup@FreeBSD.org, haris@softways.gr > Cc: > Subject: Re: ports/175485: port databases/firebird25-server (classic) keeps > attached to security2.fdb for each connection > Date: Fri, 04 Oct 2013 20:20:39 +0300 > > Hi, > > I 'm sorry to say that this doesn't work for me. I have: > > firebird_enable="YES" > firebird_server="YES" > in /etc/rc.conf > > root@raindog:~ # pkg_info | grep firebird > firebird-client-2.5.2_2 Firebird-2 database client > firebird-server-2.5.2_2 Firebird-2 relational database (server) > > root@raindog:~ # isql-fb -z > ISQL Version: FB-V2.5.2.26540 Firebird 2.5 > > root@raindog:~ # uname -a > FreeBSD raindog.softways.lan 9.1-STABLE FreeBSD 9.1-STABLE #1: Sat Aug > 31 10:26:40 EEST 2013 > root@raindog.softways.lan:/usr/obj/usr/src/sys/MYKERNEL amd64 > > root@raindog:~ # ps -axfw | grep fb_smp > 2290 0 I 0:00,15 /usr/local/sbin/fb_smp_server > > and I still see as many connections to security2.fdb as the connections > to the actual database. > > I can also understand that for fb_inet_server multiple connections would > be OK but how can one explain that Firebird 2.1.x fb_inet_server does > not keep these connections open. > > Anyway, I don't know what else to check and it surely bothers me that > Classic Superserver works for you. > > Thanks again, > Greetings > /Haris > Hi Haris are you use localhost:/path/to/database on connection string? isql-fb -USER SYSDBA -PASS masterkey 'localhost:/var/db/firebird/firstdb.fdb' if you only use /path/to/database, your firebird client will connect like classic server to database defined by you. You must add 'localhost:/path/to/database' if you want to connect like Classic Super Server (localhost is the trick). btw, I added Super Server support to firebird25-server. If you update to latest version, you must add the following to /etc/rc.conf (see message post installation): firebird_enable="YES" firebird_mode="superclassic" Just remember: Classic Server Use inetd -> fb_inet_server -> localhost:/path/to/database or /path/to/database (mutiple connections to security2) Super Classic Server Use rc.d/firebird -> fb_smp_server -> localhost:/path/to/database (one connection to security2) Super Server Use rc.d/firebird -> fbguard -> IP:/path/to/database (one connection to security2) Greetings ACM Hi, Yes! You are totally right! This is the trick. I can confirm that it has been fixed. Thank you for your great efforts. Also, great news for SuperServer! I will update asap. Greetings, Haris |
