0.9.12 Release

We are proud to release Elektra 0.9.12.

What is Elektra?

Elektra serves as a universal and secure framework to access configuration settings in a global, hierarchical key database. For more information, visit https://libelektra.org.

You can also read the news on our website.

You can try out the latest Elektra release using our docker image elektra/elektra. This is the quickest way to get started with Elektra without compiling and other obstacles, simply run:

docker pull elektra/elektra
docker run -it elektra/elektra

Highlights

New Backend

The entire logic for backends has been rewritten, to allow for more flexibility und an unlimited number of plugins. Instead of calling plugins directly, libelektra-kdb now only calls so-called backend plugins and special hook plugins. There is a contract between libelektra-kdb and the backend plugins. All backend plugins must adhere to this contract. To achieve this goal, most backend plugins will call other plugins (like libelektra-kdb did previously).

The logic previously implemented in libelektra-kdb was moved to the new default backend plugin backend. It works like the old system, but now also allows an unlimited number of plugins in positions where that makes sense. For example, you can have unlimited postgetstorage plugins, but only a single getresolver.

There have also been slight changes to kdbGet and kdbSet. Please read their API docs to find out, if you rely on any behavior that has been altered. You can also read the new low-level docs to find out all the intricate details.

The structure of system:/elektra/mountpoints changed as well. Take a look at the new docs, if you need to know details.

Updating config

The mountpoint configuration format contains breaking changes and a manual upgrade process is needed. Follow these steps to upgrade the old mountpoint configuration to the new format:

Warning: BACK UP YOUR CONFIG FILES BEFORE UPDATING! We recommend making a backup of the file printed by kdb file system:/elektra/mountpoints before updating your installation. In the unlikely case that the migration script fails, you can still use the information from the backup to manually recreate your mountpoints.

To update your existing system:/elektra/mountpoints data you can use the migration script.

Note: To run the script you must have Elektra, Python (>= 3.7) and the Python binding installed. The script uses the Python binding to manipulate Keys and KeySets, but it does not use the kdb CLI tool, or the KDB API. It is safe to run this script before, or after you update your Elektra installation.

By default, the script loads the file /etc/kdb/elektra.ecf. If you changed where system:/elektra/mountpoints is stored, you can provide an alternative path:

./migrate-mountpoints.py /path/to/your/mountpoints/config.file

Note: Because the script does not use the KDB API it only works, if the mountpoints config file uses the default dump format.

If your mountpoints config file is not using the dump format, you may still be able to use the migration script. However, in that case, you will have to use the script before updating your Elektra installation:

  1. Run kdb export system:/elektra/mountpoints dump to get a copy of your mountpoints config in dump format
  2. Write this data to a file and run the migration script on the file.
  3. To get the data back in your original format you can use
./migrate-mountpoints.py /path/to/file/from/step2 | kdb convert dump your-format > /path/to/converted/file
  1. Run kdb file system:/elektra/mountpoints to find out where your mountpoint config is stored. Make sure to back up this file, before upgrading your installation.
  2. Now upgrade your Elektra installation.
  3. Copy the file /path/to/converted/file from step 3 to the location you got in step 4.

The script will read the old mountpoint configuration from the given file. It will convert the configuration and print the new version to stdout.

You can inspect the output to make sure, everything is in order. When you are ready to commit the changes, you can manually edit the config file, or use:

./migrate-mountpoints.py --output=/etc/kdb/elektra.ecf /etc/kdb/elektra.ecf

Individual changes

Copy-on-Write

Thanks to (Maximilian Irlinger @atmaxinger) our Key and KeySet datastructures are now fully copy-on-write! This means noticeably reduced memory usage for cases where keys and keysets are copied and/or duplicated!

We ran some very promising benchmarks, each were performed with 400,000 keys. All benchmarks were executed using valgrind --tool=massif --time-unit=B --max-snapshots=200 --threshold=0.1.

Benchmark Old Implementation Copy-on-Write Size Reduction Remarks
createkeys.c 5.3 MiB 6.5 MiB -22 %
deepdup.c 10.5 MiB 8.2 MiB 22 %
large.c 18.9 MiB 15.3 MiB 19 %
kdb.c 23.5 MiB 17.8 MiB 24 %
kdbget.c 11.0 MiB 8.8 MiB 20 %
kdbmodify.c 11.0 MiB 8.8 MiB 20 % Same results as kdbget.c

First, it should be noted that a single key, without counting payload, is about 50% larger with the copy-on-write implementation. This explains why the createkeys.c benchmark yields a negative reduction result. This benchmark only allocates keys, so not much improvement can be expected there. Still, as other stuff also uses heap memory, the overall memory consumption only increased by 22%, which is far less than 50%.

All other benchmarks saw meaningful reductions of heap memory used. One interesting observation is that kdbget.c and kdbmodify.c used exactly the same memory. This can most likely be explained by internal caching within the memory allocator of glibc.

We also performed runtime tests on the same benchmarks using perf stat --repeat 13 to ensure no major performance regressions occur.

Benchmark Old Implementation Deviation Copy-on-Write Deviation Runtime Increase
createkeys.c 0.209572 s 0.36 % 0.21987 s 0.77 % 4.9 %
deepdup.c 0.23025 s 0.47 % 0.231804 s 0.32 % 0.6 %
large.c 1.14038 s 0.21 % 1.14837 s 0.21 % 0.7 %
kdb.c 1.9270 s 2.63 % 1.93354 s 0.17 % 0.3 %
kdbget.c 0.145663 s 0.17 % 0.15763 s 0.70 % 8.2 %
kdbmodify.c 0.146506 s 0.19 % 0.156347 s 0.15 % 6.7 %

Overall, the runtime performance hit is less than 10%. The more a program does, the less the additional overhead of the copy-on-write algorithms matter. One interesting detail is that keyCopy and keyDup have become quite a bit faster. This can be seen by comparing the differences between createkeys.c and deepdup.c. The differences are 21 ms for the old implementation and 12 ms for the copy-on-write implementation.

FLOSS

A Free/Libre and Open Source Software (FLOSS) Initiative couldn't survive with many small contributions fixing annoying problems. This release also contains all contributions done via one term of the FLOSS course. The success was tremendous, as shown in the rest of the release notes.

A big thanks to the students for their contributions!

Plugins

The following text lists news about the plugins we updated in this release.

yajl

list

logchange

toml

uname

quickdump

blockresolver

desktop

mini

mmapstorage

network

xfconf

date

csvstorage

Libraries

The text below summarizes updates to the C (and C++)-based libraries of Elektra.

Compatibility

Core

io

Merge

Bindings

Bindings allow you to utilize Elektra using various programming languages. This section keeps you up-to-date with the multi-language support provided by Elektra.

intercept/env

intercept/fs

jna

rust

elixir

Tools

kdb

elektrad

Scripts

Documentation

Use Cases

Decisions

Tutorials

Man Pages

Tests

Shell Recorder

Packaging

Build

CMake

Docker

Gradle

Infrastructure

Jenkins

Cirrus

GitHub Actions

Website

The website is generated from the repository, so all information about plugins, bindings and tools are always up-to-date. Furthermore, we changed:

Outlook

We are currently working on following topics:

Statistics

We closed about 150 issues for this release.

About 28 authors changed 960 files with 29400 insertions(+) and 20927 deletions(-) in 1421 commits.

Thanks to all authors for making this release possible!

Join the Initiative!

We welcome new contributors! Read here about how to get started.

As first step, you could give us feedback about these release notes. Contact us via our issue tracker.

Get the Release!

You can download the release from

The hashsums are:

The release tarball is also available signed using GnuPG from

The following GPG Key was used to sign this release: 12CC44541E1B8AD9B66AFAD55262E7353324914A

Already built API documentation can be found

Stay tuned!

Subscribe to the RSS feed to always get the release notifications.

If you also want to participate, or for any questions and comments, please contact us via our issue tracker on GitHub.

Permalink to this NEWS entry

For more information, see https://libelektra.org.

Best regards, Elektra Initiative