cnid_dbd is never started via the command line or system startup scripts but only by the cnid_metad daemon. There is at most one instance of cnid_dbd per netatalk volume.
cnid_dbd uses the Berkleley DB database library and uses transactionally protected updates. The dbd backend with transactions will avoid corruption of the CNID database even if the system crashes unexpectedly.
cnid_dbd uses the same on-disk database format as the cdb backend. It is therefore possible to switch between the two backends as necessary.
cnid_dbd inherits the effective userid and groupid from cnid_metad on startup, which is normally caused by afpd serving a netatalk volume to a client. It changes to the Berkleley DB database home directory dbdir that is associated with the volume. If the userid inherited from cnid_metad is 0 (root), cnid_dbd will change userid and groupid to the owner and group of the database home directory. Otherwise, it will continue to use the inherited values. cnid_dbd will then attempt to open the database and start serving requests using filedescriptor clntfd. Subsequent instances of afpd that want to access the same volume are redirected to the running cnid_dbd process by cnid_metad via the filedescriptor ctrlfd.
cnid_dbd uses logconfig_string which is passed from cnid_metad to configure its logging output.
cnid_dbd can be configured to run forever or to exit after a period of inactivity. If cnid_dbd receives a TERM or an INT signal it will exit cleanly after flushing dirty database buffers to disk and closing Berkleley DB database environments. It is safe to terminate cnid_dbd this way, it will be restarted when necessary. Other signals are not handled and will cause an immediate exit, possibly leaving the CNID database in an inconsistent state (no transactions) or losing recent updates during recovery (transactions).
The Berkleley DB database subsystem will create files named log.xxxxxxxxxx in the database home directory dbdir, where xxxxxxxxxx is a monotonically increasing integer. These files contain ithe transactional database changes. They will be removed regularily, unless the logfile_autoremove option is specified in the db_param configuration file (see below).
Do not use cnid_dbd for databases on NFS mounted file systems. It makes the whole point of securing database changes properly moot. Use the dbdir: Option in the appropriate AppleVolumes configuration file to put the database onto a local disk.
cnid_dbd reads configuration information from the file db_param in the database directory dbdir on startup. If the file does not exist or a parameter is not listed, suitable default values are used. The format for a single parameter is the parameter name, followed by one or more spaces, followed by the parameter value, followed by a newline. The following parameters are currently recognized:
In order to update between Netatalk releases using different BerkeleyDB library versions, follow this steps:
Note that the first version to appear after Netatalk 2.1 ie Netatalk 2.1.1, will support BerkeleyDB updates on the fly without manual intervention. In other words Netatalk 2.1 does contain code to prepare the BerkeleyDB database for upgrades and to upgrade it in case it has been prepared before. That means it can't upgrade a 2.0.x version because that one didn't prepare the database.
cnid_metad(8), afpd(8), dbd(1)