isql process in non-interactive session sometimes never ends [CORE6172]

[firebird-automations]

Submitted by: A Drouard (adrouard)

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 ?

[firebird-automations]

Commented by: @AlexPeshkoff

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.

[firebird-automations]

Commented by: A Drouard (adrouard)

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 ?

[firebird-automations]

Commented by: @AlexPeshkoff

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!

[firebird-automations]

Commented by: A Drouard (adrouard)

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.

[firebird-automations]

Commented by: @AlexPeshkoff

> 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).

[firebird-automations]

Commented by: A Drouard (adrouard)

Thank you for the quick reply. I will try that.
Last precision, should I configure only IpcName or only RemotePipeName or both ?

[firebird-automations]

Commented by: @AlexPeshkoff

In production both, for experiments - as you wish

[firebird-automations]

Commented by: A Drouard (adrouard)

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 ?