Commented by: Nick Upson (nickupson)

additional evidence:

firebird.log contents of one occurrance

ash-cs_testnet2.hosted-at.thebunker.net Wed Aug 31 15:56:23 2011
ISC_kill: process 3161 couldn't deliver signal 16 to process 20338: permission denied

ash-cs_testnet2.hosted-at.thebunker.net Wed Aug 31 15:56:23 2011
Fatal lock manager error: invalid lock id (58912), errno: 22

extract from ls -l /opt/firebird

-rw-rw-rw- 1 root root 156865 Aug 31 15:56 firebird.log

-rw-rw-rw- 1 firebird firebird 65536 Aug 31 15:56 isc_event1.ash-cs_testnet2.hosted-at.thebunker.net
-rw-rw-rw- 1 root root 0 Jun 12 11:16 isc_init1.ash-cs_testnet2.hosted-at.thebunker.net
-rw-rw-rw- 1 root root 1048576 Aug 31 16:13 isc_lock1.ash-cs_testnet2.hosted-at.thebunker.net

Commented by: @dyemanov

You seem to be running Firebird as root while gbak is running under some "normal" (firebird?) user account. Or, alternatively, you could be running some ISQL script (or GFIX or whatever) as root at the time when GBAK is running. As you specify a local connection string to gbak, it runs in the embedded mode. As a result, a regular user process (gbak) cannot deliver a signal to the privileged user process (fb_inet_server or isql), hence the problem. You should be either running fb_inet_server as "firebird" or using the localhost prefix in the gbak command line. Something like that.

The top output (ownership and program name) for processes 20338 and 3161 could explain the issue.

Commented by: Nick Upson (nickupson)

gbak is being run as root, all copies of fb_inet_server and fb_lock_mgr are running as firebird, there are other processes, both C with firebird calls and isql scripts, that could be running as root but that's only the client and they are all connected to the database that is backed up, the restore (which is when this error occurs) involves the database name which is unique and onlyused for that purpose.

Noticed that I hadn't said this is classic, specifically FirebirdCS-2.1.4.18393-0

Commented by: Nick Upson (nickupson)

I can make this happen with reasonable reliability by running the "gbak -create ..." and the isql script, each in it's own continuous loop. I then get the error more often and several times within a hour. This obviously depends upon the details of the machine but running both of these for a long time should produce evidence for anyone. The isql script just does a series of procedure calls which inserts records into a table.

note that the "gbak -create ..." refers to a tmporary database name being used to validate the backup and the isql is connecting to a different database via localhost.

both gbak and isql are running as root

changing the gbak so that the database string being created refers to localhost seems to reduce the frequency of the error and changes the message to
gbak -V -CREATE 110901130102.fbk -user sysdba -pass genesis localhost:/opt/unb/archive/tmp/110901130102.fdb
gbak:opened file 110901130102.fbk
Fatal lock manager error: invalid lock id (223072), errno: 11
--Resource temporarily unavailable

Commented by: @AlexPeshkoff

How did you install firebird on your system?
You have absolutely wrong access rights for files, and this is the reason of a bug.

Commented by: Nick Upson (nickupson)

I originally installed 2.1.3 and recently did an upgrade to 2.1.4, which seems to have been the cause of the problem as uninstalling and then install of 2.1.4 and the problem has gone away.

This is, IMO, a serious problem and also doesn't explain why such a signal is being attempted, the gbak is creating one database while the isql session is causing an update in another

Commented by: @dyemanov

Prior to Firebird 2.5, the lock and event tables are per instance (i.e. shared among all the actively connected databases).

Commented by: Nick Upson (nickupson)

great, that explains why the signal was sent. Hopefully the upgrade problem is handled in 2.5 as well

Commented by: @AlexPeshkoff

Did you use RPM to upgrade?
Was it rpm from SF or distro-specific?
Must say that SF rpms are known to have upgrade problems, moreover - we stop rpm support starting with FB3. You should better use tgz or if you really need rpm - take it from your distro.

Commented by: Nick Upson (nickupson)

I used FirebirdCS-2.1.4.18393-0.i686.rpm via "yum upgrade" from the http://www.ibphoenix.com/, AFAIK, centos doesn't have a specific distro

lack of rpm support may force me to change database or generate my own rpm, why is support dropped?

Commented by: @AlexPeshkoff

The reason to drop rpm support is very simple - we can't provide enough good quality of rpms for different distros and can't release as many types of rpms as types of linux distros exist.
I'm very sorry if you will have to change the database due to such strange reason... Be sure that .tar.gz installer is fine when upgrading database. And certainly you are free to build your own rpm! Moreover, if it's specific for centos it will upgrade perfectly.

Commented by: @pmakowski

Centos have rpm
just use the EPEL repository
http://fedoraproject.org/wiki/EPEL

http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/firebird.html

Commented by: Nick Upson (nickupson)

so is that different to FirebirdCS-2.1.4.18393-0.i686.rpm?

Commented by: @pmakowski

yes as Alex said, FirebirdCS-2.1.4.18393-0.i686.rpm is a generic rpm without update support (just install and remove)
EPEL repository is a repo made for RHEL and derivative like Centos or ScientificLinux