FBSVCMGR. Unable to get DB header when DB is in full shutdown state (6.x)

[Pavel Zotov]

It is unable to get DB header since #afb9dc80 when DB is in full shutdown state (at least on Windows; did not check on Linux)

Please consider following batch (one need to ajust 'fbc' variable to your environment):

===========

@echo off
setlocal enabledelayedexpansion enableextensions

::::::::::::::::::
set fbc=C:\FB\60sS
::::::::::::::::::

set dbn=C:\TEMP\tmp4test.fdb

set isc_user=sysdba
set isc_password=masterkey

set tmpsql=%~dpn0.tmp.sql
set tmplog=%~dpn0.tmp.log

if exist !dbn! del !dbn!
if exist !dbn! (
    @echo ERROR: could not remove file !dbn!
    goto :fin
)
@rem -----------------------------------------
@echo on
echo create database 'localhost:%dbn%'; show database; | %fbc%\isql -q -z
if NOT !errorlevel! EQU 0 (
    goto :fin
)

!fbc!\gfix -shut full -force 0 !dbn!
echo !errorlevel!
::timeout 10
@set run_cmd=!fbc!\fbsvcmgr localhost:service_mgr action_db_stats dbname !dbn! sts_hdr_pages
echo !run_cmd!
cmd /c !run_cmd!
echo !errorlevel!

:fin
    echo Bye-bye from %~f0

===========

This batch creates DB and immediately change its state to full shutdown.

Then it attempts to get DB header info using Services API.

On 6.0.0.2062-20260706_073606-902ca61 it works fine.

But on 6.0.0.2062-20260706_075559-afb9dc8 its output will be:

===========

!fbc!\gfix -shut full -force 0 !dbn!
echo !errorlevel!
0

echo !run_cmd!
C:\FB\60sS\fbsvcmgr localhost:service_mgr action_db_stats dbname C:\TEMP\tmp4test.fdb sts_hdr_pages
@rem @set run_cmd=!fbc!\gstat -h !dbn! ---------------------- [ 1 ]
cmd /c !run_cmd!
database C:\TEMP\TMP4TEST.FDB shutdown
echo !errorlevel!
1

===========

(i.e. fbsvcmgr failed with error and did not show DB header).

The above mentioned snapshots are here.

PS.

No such problem if we try to get DB header using 'gstat -h' (see line marked as "[ 1 ]")

[Dmitry Yemanov]

18.07.2026 10:44, Pavel Zotov wrote:
>
> echo !run_cmd!
> C:\FB\60sS\fbsvcmgr localhost:service_mgr action_db_stats dbname C:
> \TEMP\tmp4test.fdb sts_hdr_pages

Does it work if username/password are specified explicitly in the
fbsvcmgr call (rather than using ISC* variables)?


Dmitry

[Pavel Zotov]

No, result the same:

 ===========

set ISC_USER=
set ISC_PASSWORD=
echo create database 'localhost:C:\TEMP\tmp4test.fdb'; show database;   | C:\FB\60sS\isql -q -z -user SYSDBA -password masterkey  
...
WI-T6.0.0.2078 Firebird 6.0 Initial
...

!fbc!\gfix -shut full -force 0 !dbn! -user SYSDBA -password masterkey  

echo !errorlevel!
0

echo !run_cmd!
C:\FB\60sS\fbsvcmgr localhost:service_mgr user SYSDBA password masterkey action_db_stats dbname C:\TEMP\tmp4test.fdb sts_hdr_pages

cmd /c !run_cmd!
database C:\TEMP\TMP4TEST.FDB shutdown

echo !errorlevel!
1

=========== 

[Dmitry Yemanov]

19.07.2026 16:49, Pavel Zotov wrote:
>
> On Sunday, July 19, 2026 at 11:25:21 AM UTC+3 Dmitry Yemanov wrote:
>
> 18.07.2026 10:44, Pavel Zotov wrote:
> >
> > echo !run_cmd!
> > C:\FB\60sS\fbsvcmgr localhost:service_mgr action_db_stats dbname C:
> > \TEMP\tmp4test.fdb sts_hdr_pages
>
> Does it work if username/password are specified explicitly in the
> fbsvcmgr call (rather than using ISC* variables)?
>
> No, result the same:

Well, this is kinda expected. gstat now validates permissions if
launched remotely and this is done before the header is printed. But
it's impossible to attach the database in the full shutdown mode, hence
the error you get. As a workaround, you may either use gfix -h directly
or omit localhost in fbsvcmgr (please update to a new snapshot) --
permission checking is not performed in the embedded mode.


Dmitry

[Pavel Zotov]

Well, this is kinda expected. gstat now validates permissions if
launched remotely and this is done before the header is printed. But
it's impossible to attach the database in the full shutdown mode, hence
the error you get. As a workaround, you may either use gfix -h directly
or omit localhost in fbsvcmgr (please update to a new snapshot) --
permission checking is not performed in the embedded mode.

Checked on 6.0.0.2079-97c1429 -- all fine.

Test for CORE-3548 (which gives runtime error since  6.0.0.2067 2026.07.06 16f511eb ) will be adjusted.