Issue Details (XML | Word | Printable)

Key: CORE-6172
Type: Bug Bug
Status: Open Open
Priority: Blocker Blocker
Assignee: Unassigned
Reporter: A Drouard
Votes: 0
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
Firebird Core

isql process in non-interactive session sometimes never ends

Created: 28/Oct/19 03:25 PM   Updated: 17/Feb/20 10:56 AM
Component/s: ISQL
Affects Version/s: 3.0.3
Fix Version/s: None

Environment: Windows, Java (for installation program)

QA Status: No test


 Description  « Hide
Firebird server is deployed with it's own port for each instance of our application.
We have about 150 Firebird instances on the same machine.
We run isql in order to create Firebird users with a random generated password with the following command :
<absolute_path_to_firebird_dir>\isql.exe -b -m -o "<absolute_path_to_firebird_dir>\init-users.log" -user sysdba -input "<absolute_path_to_firebird_dir>\init-users.sql" employee

Sometimes, isql.exe process is blocked. In such case, users are not created and init-users.log file is empty.

The init-users.sql file is generated like this :

create user user1 password 'randompassword1';
create user user2 password 'randompassword2';
create user user3 password 'randompassword3';
grant create database to user user1;
grant create database to user user2;
commit;
quit;


The installation program executes the following actions :

1) Unzip Firebird server binaries
2) Run isql to create users
3) Configure RemoteServicePort in firebird.conf
4) Register Firebird as Windows service

As isql need exclusive access to Firebird engine, we run it before registering service.
May be, isql.exe is disturbed by other Firebid instances ?

How can I ensure that isql will not block ?
How can I have more logs ?

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 29/Oct/19 05:39 AM
You are using rather old firebird version - try to reproduce with current snapshot builds.
If you have an instance with default port (3050) try to change order of execution of pp. 2 & 3.
Make sure you do not try to install wnet and xnet protocols in your instances.

If that does not help we will need a dump of hanged process.


A Drouard added a comment - 29/Oct/19 04:18 PM
Thank you for your reply.
As suggested we have reversed steps 2 and 3 and we will monitor if the problem occurs again.

What do you mean by installing wnet and xnet protocols ?
We use default firebird.conf file with WireCrypt = Disabled.

Do you confirm that isql always connects to the server in the same directory ?

Alexander Peshkov added a comment - 29/Oct/19 04:33 PM - edited
I understood - sooner of all you are installing them. On windows (unlike posix) client may talk to server using 3 different protocols - inet (TCP/IP), wnet (windows named pipes) or xnet (mutex-protected shared memory). Wnet is not a problem but looks like xnet can make isql connect to another instance of firebird, I am not 100% sure here as I do not work with windows.

To avoid this for sure you can change 2 more parameters in firebird.conf: IpcName and RemotePipeName, they have same meaning for xnet/wnet appropriately as default port for inet. Also you may set -i flag for firebird.exe - it will make server use only tcp/ip.

And please do not forget about version upgrade!


A Drouard added a comment - 06/Feb/20 01:30 PM
After 3 months with the new sequence of installation steps, the problem unexpectedly persists : sometimes step 3 (isql) blocks.
The installation steps are :
1) Unzip Firebird server binaries
2) Configure RemoteServicePort in firebird.conf
3) Run isql to create users
4) Register Firebird as Windows service and start it.

As a reminder, each instance of firebird is configured with its own port. Once the Windows service is installed, we use a TCP / IP connection.
The local connection with isql is only used to create users during the installation process of an additional Firebird instance on the same machine (OS is Windows 2016 Server).

I'm afraid I don't understand your advice regarding the "IpcName" and "RemotePipeName" parameters.
Currently these 2 parameters are commented :
#IpcName = FIREBIRD
#RemotePipeName = interbas

What value do you suggest for these parameters ?
Should we provide different values ​​for each instance of Firebird ?
How to ensure that these parameters have an influence on the local connection of isql ?

Please excuse me if these questions seem basic to you.

Alexander Peshkov added a comment - 06/Feb/20 01:47 PM
> What value do you suggest for these parameters ?
Unique for each instance, preferably ascii set of letters & digits, started with letter.

> Should we provide different values ​​for each instance of Firebird ?
Yes.

> How to ensure that these parameters have an influence on the local connection of isql ?
Create 2 instances not changing defaults but with different sets of users. Attach with protocol netbeui using isql from both instances:
    isql -user sysdba -pas XXX \\hostname\employee
and run
    show users
in both isql's. You will see same set of users in both isql-s.
Now change RemotePipeName to something unique (RemotePipeName = FB<TCP-port-num> not bad name), Restart firebird services. In same test you should see appropriate list of users for that instance.
(same for xnet & IpcName).


A Drouard added a comment - 06/Feb/20 02:47 PM
Thank you for the quick reply. I will try that.
Last precision, should I configure only IpcName or only RemotePipeName or both ?

Alexander Peshkov added a comment - 07/Feb/20 08:08 AM
In production both, for experiments - as you wish

A Drouard added a comment - 17/Feb/20 10:56 AM
I think there is a misunderstanding about my problem.
I use isql to establish a direct local connection.
As described in this documentation page https://firebirdsql.org/file/documentation/reference_manuals/user_manuals/html/qsg3-databases.html#qsg3-databases-connstrings
"the Firebird client will first attempt to make a direct, embedded connection to the database file, bypassing authentication"

During this connection the server service is not started.
So I do not use the wnet protocol or the xnet protocol.
Therefore the parameters "IpcName" and "RemotePipeName" do nothing to solve my problem.

I cannot find documentation on how the "local direct" connection is established in order to understand why it fails sometimes.
I have the impression that all parameters of firebird.conf file do not affect this direct local connection.
Am I wrong ?