boycott kdbus

Note this site is a parody of and is meant to be comic relief.

   o                              \O_
<\==-   -   - -   -  -  - --- __/
/ \                             \

Seriously though we need to work together to raise the level of discourse in the open source world.

Check out the uslessbusd project for a saner kdbus base.

kdbus0 is a replacement for the D-Bus daemon which is used in GNU/Linux and Unix systems, originally authored by Lennart Poettering of Red Hat. It represents a monumental increase in complexity, a slap in the face to the Unix philosophy, and its inherent domineering and viral nature turns it into something akin to an "in-kernel" implementation of D-Bus that is spreading all across the Linux ecosystem. This site aims to serve as a rundown and a wake-up call to take a stand against the widespread proliferation of kdbus, to detail why it is harmful, and to persuade users to reject its use, and especially its ubiquity.

Disclaimer: We are not D-Bus purists by any means. We do recognize the need for a new D-Bus system in the 21st century, but kdbus is not it.

The Rundown
  1. 1. kdbus flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an IPC system, as it interfears with power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, mDNS/DNS-SD, the Linux console and other things ....probably. The agenda for kdbus to be an ever-growing and invasive message oriented meddleware for GNU/Linux was elucidated in a 2014 Auckland Linux Conf talk 2. Keep it simple, stupid.

  2. 2. kdbus's journal files (handled by journald) are stored in a complicated binary format3, and must be queried using journalctl. This makes journal logs potentially corruptible, as they do not have ACID- compliant transactions. You typically don't want that to happen to your syslogs. The advice of the kdbus developers? Ignore it. The only way to generate traditional logs is to run a standard syslogd like rsyslog alongside the journal4. There's also embedded HTTP server integration (libmicrohttpd). QR codes are served, as well, through libqrencode.

  3. 3. Since kdbus is very tightly welded with the Linux kernel API, different kdbus versions are incompatible with different kernel versions and portability is unnecessarily hampered in many components. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, serving as an obstacle to developing software portable with both Linux variations and other Unix-like systems. It also raises some issues backporting patches and maintaining long-term stable systems.

  4. 4. udev and dbus are forced dependencies. In fact, udev merged with kdbus a long time ago5. The integration of the device node manager, which was once a part of the Linux kernel, is not a decision that is to be taken lightly. The political implications of it are high, and it makes a lot of packages dependent on udev, in turn dependent on kdbus, despite the existence of forks, such as eudev. Starting with kdbus-209, the developers now have their own, non-standard and sparsely documented sd-bus API that replaces much of libdbus's job, and further decreases transparency. Further, they intend to migrate udev to this new transport, replacing Netlink and thus making udev a kdbus-only daemon6. The effects of this move are profound.

  5. 5. kdbus features a helper which captures coredumps and directs them either to /var/lib/kdbus/coredump... or the journal, where they must be queried using coredumpctl7. The latter behavior was a default and is likely to return8. It assumes that users and admins are dumb9, but more critically, the fundamentally corruptible nature of journal logs makes this a severe impediment, and an irresponsible design choice. It can also create complications in multi-user environments related to privileges.

  6. 6. kdbus makes the kernel a single point of failure. As of this writing, kdbus has had some CVE reports, since its inception in March 201010. So far, this may not seem like that much, but its essential and overbearing nature will make it a juicy target for crackers, as it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical.

  7. 7. kdbus is viral by its very nature, due to its auxiliaries exposing APIs, while being bound to kdbus's init. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment often makes use of kdbus components, such as logind, and support for non-kdbus systems is becoming increasingly difficult. Under Wayland, GNOME relies on logind, which in turn requires and is a part of kdbus11. More and more maintainers are going to require kdbus for this reason, and similar instances like it. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. Other dependent packages include the Weston compositor, Polkit, upower, udisks2, PackageKit, etc. It's also worth noting that kdbus will refuse to start as a user instance, unless the system boots with it as well - blatant coercion12.

  8. 8. kdbus clusters itself into PID 1, rather than acting as a standalone process supervisor. Due to it controlling lots of different components, there are tons of scenarios in which it can crash and bring down the whole system. We should also mention that in order to reduce the need for rebooting, kdbus provides a mechanism to reserialize and reexecute systemctl in real time, however, if this fails, of course, the system goes down. There are several ways that this can occur13, including an inability to reload a previous, potentially incompatible state. This happens to be another example of SPOF and an unnecessary burden on an already critical component (init).

  9. 9. kdbus is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much14. In general, the kdbus developers' idea of a standard libc is one that has bug-for-bug compatibility with glibc.

  10. 10. kdbus's complicated nature makes it harder to extend and step outside its boundaries. While you can more or less trivially start shell scripts from unit files, it's more difficult to write behavior that goes outside the box, what with all the feature bloat. Many users will likely need to write more complicated programs that directly interact with the kdbus API, or even patch kdbus directly. One also needs to worry about a much higher multitude of code paths and behaviors in a system-critical program, including the possibility of kdbus not synchronizing with the message bus queue on boot, and thus freezing. This is as opposed to a conventional init, which is deterministic and predictable in nature, mostly just serially execing scripts.

  11. 11. Ultimately, kdbus's spread is symbolic of something more than kdbus itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and is just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.

  12. 12. kdbus doesn't even know what it wants to be. It is variously referred to as a "system daemon" or a "basic userspace building block to make an OS from", both of which are highly ambiguous. It engulfs functionality that variously belonged to util-linux, wireless tools, syslog and other projects. It has no clear direction, other than the whims of the developers themselves. Ironically, despite aiming to standardize Linux distributions, it itself has no clear standard, and is perpetually rolling.

External Resources and References


[1] <--can't argue w/ that!!
[2] This post someone wrote on Reddit.

What You Can Do

Boycott distros that use kdbus.

Spread word of this web page.

Contribute to and use distros that we like

Consider migrating to *BSD, Plan 9 or something similar, when things get really out of hand.

Lennart Poettering out doing what he does best

Send inquiries, feedback and suggestions to