CNID_DBD(8)

📦
version 4.5.1 · 11 versions
, in ubuntu stonking

💖 CNID_DBD 💖

okay so bestie, welcome to the CNID_DBD page from the Netatalk AFP Fileserver Manual — this is the manual for section 8 (system administration commands), and it's literally the CNID database access daemon. sit down, grab a strawberry 🍓, we're doing sysadmin lore today.

✨ NAME ✨

cnid_dbd — CNID database access daemon

🌸 SYNOPSIS 🌸

cnid_dbd

cnid_dbd [-v | -V]

🦋 DESCRIPTION 🦋

okay so cnid_dbd is the whole vibe of storage and retrieval for catalog node IDs (CNIDs) and the info that goes with them — it does this for the afpd daemon when you're running the dbd (Database Daemon) CNID backend. that's the job. that's the whole job. 🎀

and like, why does this even need to exist? because CNIDs are a component of Classic Mac OS based file systems, and their semantics do not map easily onto Unix file systems. so storing them separately, in a database, is literally necessary. no cap.

here's the part that surprises people: cnid_dbd is never started via the command line or system startup scripts. never ever. it's only started by the cnid_metad daemon. and there's exactly one instance of cnid_dbd per netatalk volume — one per volume, okay? not one to rule them all.

cnid_dbd uses the Berkeley DB database library and uses transactionally protected updates. and this is the slay part: the dbd backend with transactions will avoid corruption of the CNID database even if the system crashes unexpectedly. iconic behaviour honestly.

now, the userid situation, because it's giving ✨inheritance✨:

  • cnid_dbd inherits the effective userid and groupid from cnid_metad on startup — which normally happens because afpd is serving a netatalk volume to a client.
  • it changes to the Berkeley DB database home directory dbdir that's 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 just continues to use the inherited values.

then it attempts to open the database and starts serving requests using filedescriptor clntfd. and any subsequent instances of afpd that want to access the same volume? they get redirected to the already-running cnid_dbd process by cnid_metad via the filedescriptor ctrlfd. so efficient. so tidy. 💅

you can configure cnid_dbd to run forever, or to exit after a period of inactivity — your call bestie. and about signals:

if cnid_dbd receives a TERM or an INT signal, it will exit cleanly after flushing dirty database buffers to disk and closing Berkeley DB database environments. it is safe to terminate cnid_dbd this way, and 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). so like… don't. 😭

Also!! the Berkeley DB database subsystem will create files named log.xxxxxxxxxx in the database home directory dbdir, where xxxxxxxxxx is a monotonically increasing integer. those files contain the transactional database changes. they get removed regularly, unless the logfile_autoremove option is specified in the db_param configuration file (see below) with a value of 0 (default 1).

🎀 OPTIONS 🎀

  • -v | -V — Show version and exit. that's it, that's the option. short king. 👑

🌈 CONFIGURATION 🌈

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 — no drama.

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. simple. clean. we love a format.

the following parameters are currently recognized:

💜 logfile_autoremove

if set to 0, unused Berkeley DB transactional logfiles (log.xxxxxxxxxx in the database home directory) are not removed on startup of cnid_dbd and on a regular basis. Default: 1.

🧚 cachesize

determines the size of the Berkeley DB cache in kilobytes. Default: 8192. each cnid_dbd process grabs that much memory on top of its normal memory footprint. it can be used to tune database performance. the db_stat utility with the -m option that comes with Berkeley DB can help you determine whether you need to change this value. the default is pretty conservative so that a large percentage of requests should be satisfied from the cache directly. if memory is not a bottleneck on your system you might want to leave it at that value. the Berkeley DB Tutorial and Reference Guide has a section Selecting a cache size that gives more detailed information. 📚

⭐ flush_frequency; flush_interval

flush_frequency (Default: 1000) and flush_interval (Default: 1800) control how often changes to the database are checkpointed. both of these operations are performed if either i) more than flush_frequency requests have been received or ii) more than flush_interval seconds have elapsed since the last save/checkpoint.

be careful to check your hard disk configuration for on disk cache settings. many IDE disks just cache writes as the default behaviour, so even flushing database files to disk will not have the desired effect. 😬

💖 fd_table_size

is the maximum number of connections (filedescriptors) that can be open for afpd client processes in cnid_dbd. Default: 512.

if this number is exceeded, one of the existing connections is closed and reused. the affected afpd process will transparently reconnect later, which causes slight overhead. on the other hand, setting this parameter too high could affect performance in cnid_dbd since all descriptors have to be checked in a select() system call, or worse, you might exceed the per process limit of open file descriptors on your system. it is safe to set the value to 1 on volumes where only one afpd client process is expected to run, e.g. home directories. 🏠

🍓 idle_timeout

is the number of seconds of inactivity before an idle cnid_dbd exits. Default: 600. set this to 0 to disable the timeout. she can stay as long as she wants. ✨

👑 UPDATING 👑

Starting with Netatalk 2.1.1, automatic Berkeley DB updates are supported, as long as Netatalk 2.1.0 or later was used to create the database. okay so far so good.

in order to update between older Netatalk releases using different Berkeley DB library versions, follow these steps:

  • Stop the to be upgraded old version of Netatalk
  • Using the old Berkeley DB utilities run db_recover -h path/to/.AppleDB
  • Using the new Berkeley DB utilities run db_upgrade -v -h path/to/.AppleDB -f cnid2.db
  • Again using the new Berkeley DB utilities run db_checkpoint -1 -h path/to/.AppleDB
  • Start the the new version of Netatalk

(yes, "the the" — that's literally what the original says and we're keeping it, it's part of the lore 🫶)

🔥 WIRE PROTOCOL 🔥

cnid_dbd speaks a private TCP/IP protocol with afpd and nad on localhost:4700 (configurable per-volume via cnid server / cnid port in afp.conf(5)). the protocol is internal and may change between releases.

after a netatalk upgrade, restart the netatalk service. fr fr.

🌸 SEE ALSO 🌸

cnid_metad(8), afpd(8), dbd(1)

🫶 AUTHOR 🫶

Contributors to the Netatalk Project (https://netatalk.io/contributors)

and that's the whole page bestie!! 💖 this was Netatalk 4.5.1 energy, from the Netatalk AFP Fileserver Manual, CNID_DBD(8), and you absolutely ate this documentation. go flush your dirty database buffers safely, exit cleanly on TERM and INT, and never ever launch this daemon yourself. periodt. 💅✨🎀

📦 where this page comes from