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.

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

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.

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.

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.

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