<< Windows Systems | Firebird Superserver Manager | A: Document history >>

Fbmgr caveats

The following caveats are all specific to the Linux (and by assumption, other Unix systems) and do not apply to Windows versions of Firebird. The reason is simple, Windows doesn't have an fbmgr application as it uses the instsvc command instead.

fbmgr is deprecated at Firebird 2.5

The biggest drawback to the fbmgr utility is the fact that it is deprecated from Firebird 2.5 onwards and will be removed altogether from Firebird 3.0. You are advised to use fbguard instead.

The help command

The help command, as described previously, doesn't mention that fact that there is a start command. There is a very brief mention of the start command, but no text explains its use, unlike the other commands which are described.

Who owns the databases?

While not an error as such, this is something that you should be aware of. When the server boots, it starts the Firebird engine and runs it as the user firebird. By default, the firebird server has no interactive shell - it defaults to /bin/false - and so you cannot log in to, or su to, the firebird user to manually run a command.

This means that, unless you change the firebird user's default shell as described above, you will have to carry out any manual restarts etc. of the engine as the root user - although you can shut it down as any user provided you have the SYSDBA password.

If you do restart the engine as root, then it will now be running as root. While existing databases - owned by the firebird user - will happily be read from and written to by root, any new databases created will be owned by root. Everything will work fine for a while but after the server is next rebooted, these new databases will then fail to be accessible as the engine is now running as the firebird user again and that user has no permissions to access the databases owned by root.

You are therefore advised to always start and stop the server either:

• as root, using the rcfirebird command; or
• as firebird, using fbmgr,

but never, ever, as root using fbmgr. If you follow the above instructions, all your databases will be owned by the firebird user.

What's that defunct guardian process doing?

If you run fbmgr and shut down the database engine, the fbserver process vanishes from the list of processes running under the firebird user. However, a ps -ef|grep -i fir[e]bird command will show the following:

 tux> ps -ef|grep -i fir[e]bird

 firebird 29978 29844 0 15:57 pts/0 00:00:00 /opt/firebird/bin/fbmgr.bin
 firebird 29979 29978 0 15:57 ? 00:00:00 [fbguard] <defunct>
 root 29992 29955 0 15:57 pts/1 00:00:00 grep -i fire

The guardian process, fbguard, doesn't vanish until you exit from fbmgr. This again is not a major problem, but knowing that all you have to do is exit from fbmgr to make it vanish is helpful.

I can shut down but not start up the engine

If you log in to the server as a privileged user and have the SYSDBA's password, you can shut down and start up the engine with no problems. If, on the other hand, you log in as any other user and try to use fbmgr to stop and start the Firebird engine, you will find that you can stop it with no problems but you will not be allowed to restart it. Only privileged users can start the engine. The following shows the problem.

 tux> # Shutdown Firebird engine as user 'norman'.
 tux> fbmgr -shut -password secret
 no permissions to perform operation

 tux> fbmgr -shut -user sysdba -password secret
 server shutdown completed

 tux> # Try to restart the Firebird engine as user 'norman'.
 tux> fbmgr -start
 no permissions to perform operation

 tux> fbmgr -start -password secret
 no permissions to perform operation

 tux> fbmgr -start -user sysdba -password secret
 no permissions to perform operation

 tux> # Give up and restart the engine as 'firebird'.
 tux> su - firebird
 tux> bin/fbmgr -start
 server has been successfully started

It can be seen from the above that a normal user armed with the SYSDBA user name and password can stop the Firebird engine but is completely unable to restart it afterwards.

The reason why this is the case is quite simple. Until the firebird engine is started, there is no way to check that the password supplied for the SYSDBA user is actually correct. Because of this, logging in as a privileged user assumes SYSDBA privileges and allows you to start the engine.

Shut with no parameters appears to be a bug

Running fbmgr's -shut command with no user or password gives the following cryptic output:

 tux> fbmgr -shut
 Invalid clumplet buffer structure: buffer end before end of clumplet -
 no length component
 can not attach to server

The same result is obtained even with a user name supplied:

 tux> fbmgr -shut -user sysdba
 Invalid clumplet buffer structure: buffer end before end of clumplet -
 no length component
 can not attach to server

back to top of page
<< Windows Systems | Firebird Superserver Manager | A: Document history >>