[FR] Fill (if available) mon$remote_pid, mon$remote_process when mon$remote_address or mon$remote_protocol is not null
Currently some field from mon$attachments are null by formal reason: "remote_* value is absent for local stuff".
F.e. in gbak -se ip-address:service_mgr attachments filled mon$remote_protocol/_address but absent mon$remote_pid/_process
Keep in mind "remote is client" and fill (at least) mon$remote_pid/_process if possible.
Is there a way, to fill remote_pid, remote_process somehow when doing backup ?
I think it would make sense if operations executed by the services manager, like a backup, inherit the remote PID and process name (maybe with the process name modified to prefix or suffix it with service_mgr: or (service_mgr) or something).
I think it would be better to have ability to see list of currently executed services and a reference from attachment to the parent service.
But services are generally server-wide, while monitoring is database-wide. Or do you mean showing services attached to the current database?
Yes, but for a remote backup through the services manager, it is database specific , and those will make connections that are reported in MON$ATTACHMENTS (and IIRC, same goes for validation connections). Having the PID and process name inherited for those connections would make clear on whose behalf they are executing.
In embedded mode mon$server_pid/mon$remote_pid are the same.
But services are generally server-wide, while monitoring is database-wide. Or do you mean showing services attached to the current database?
There could be few ways to expose services list to the user. Simplest is to create separate service for this (or extend existing isc_info_svc_svr_db_info).
Or we can introduce new MON$SERVICES table and populate it with records in scope of current user provileges.
I any case we need stable service identifier (say, like attachment ID) that could be used as reference from database attachment, and a way to let attachment know it.
And I think that we should not confuse users by substituting remote properties of attachment by remote properties of its creator (service).
Perhaps the difference in these properties between gbak -b and gbak -b -se is more confusing.
@basid-irk Why do you not add information about FB version where you see this problem? Looks like in FB5 (and certainly later) it was fixed a few years ago.
embedded connection:
> "50/isql" -q -z -ch WIN1251
ISQL Version: WI-V5.0.3.1683 Firebird 5.0
SQL> set auto;set count;set time;set stats;set list;
SQL> connect 'security.db' user sysdba;
Server version:
WI-V5.0.3.1683 Firebird 5.0
Database: 'security.db', User: SYSDBA
SQL> select * from mon$attachments where mon$attachment_id = current_connection;
MON$ATTACHMENT_ID 4
MON$SERVER_PID 364
MON$STATE 1
MON$ATTACHMENT_NAME security.db
MON$USER SYSDBA
MON$ROLE NONE
MON$REMOTE_PROTOCOL <null>
MON$REMOTE_ADDRESS <null>
MON$REMOTE_PID <null>
MON$CHARACTER_SET_ID 52
MON$TIMESTAMP 2025-07-24 02:10:50.7370 Asia/Irkutsk
MON$GARBAGE_COLLECTION 1
MON$REMOTE_PROCESS <null>
MON$STAT_ID 14
MON$CLIENT_VERSION <null>
MON$REMOTE_VERSION <null>
MON$REMOTE_HOST <null>
MON$REMOTE_OS_USER <null>
MON$AUTH_METHOD User name in DPB
MON$SYSTEM_FLAG 0
MON$IDLE_TIMEOUT 0
MON$IDLE_TIMER <null>
MON$STATEMENT_TIMEOUT 0
MON$WIRE_COMPRESSED <null>
MON$WIRE_ENCRYPTED <null>
MON$WIRE_CRYPT_PLUGIN <null>
MON$SESSION_TIMEZONE Asia/Irkutsk
MON$PARALLEL_WORKERS 1
Records affected: 1
Server PID - present, but client info are absent.
Please compare it with example you've provided in the ticket: gbak -se ip-address:service_mgr attachments filled mon$remote_protocol/_address but absent mon$remote_pid/_process That's not embedded connection but remote service connection. Also reread please ticket header - 'Fill ... when mon$remote_address ... is not null'
What about embedded connections - well, certainly there is no remote_* objects. Mentioned mon$remote_address makes no sense here.
Issue was resolved by commit 5cf932d7fb4e13965bd73b5b00fba5b2ff695138