Avoid D-Bus bus activation | Hacker News Reader

Avoid D-Bus bus activation

homepage.ntlworld.com

24 pointsvezzy-fnord44 comments

Having dæmon instead of daemon in the article makes my blood boil a little, but I managed to push through. The ligature has no place in writing about computer daemons. It might apply if we were having a talk about medieval literature regarding demons.

It's like "virii" or "octopi" or other hypercorrect mistakes.

EDIT: "viruses" and "octopuses", please. Maybe possibly potentially "octopodes."

It's a historical spelling, not misapplying a grammatical rule outside of its scope. I don't see the resemblance.

It's a mistake from hypercorrection. It's not a historical spelling, it's a misspelling.

>It's not a historical spelling

If you don't accept online evidence, will you accept a picture of a dictionary from 1933 listing it as a valid spelling?

It's a new coinage, after the ae ligature had fallen into disuse. Would you expect that "browser" should be spelled "browƒer"?

Uh, that's a font choice, so yes you can do that.

It is not just a font choice, it is a different set of characters that share some connection.

The same way as you can't just spell any german word that contains digraphs for Umlauts with the actual Umlauts. I made the "Oehler"/"Öhler" example above. People who are named Oehler would probably be pretty annoyed at your insistence to spell their name wrong, just like people here are annoyed at your spelling of daemon.

I assume you do not come from a country which has an extended latin alphabet? In Germany for example, it is pretty common to clarify how to spell such names on the phone, like saying "Mueller with U-E". If that would be a font choice, this would not be an issue.

Long s is the same character as short s. OE and Ö are not the same character.

æ is a ligature in some contexts, and its own letter in others.

None of which matters to the original question.

ſ and s is not the same character – in some languages at some times, it was used to mark a sharper s.

Combined with the z, from ſz came ß later.

Conceded. I still think the ae ligature in "Unix daemon" is a misspelling or usage failure.

There were no operating system daemons in 1933. You are proving the wrong thing, namely that the ligature is a valid way to spell a mythological daemon.

The videogame Natural Selection introduced fictional alien monsters, among them the "Onos", which resembles an elephant with the head of a rhinoceros. There were many debates about how to pluralize this - both "Onoses" and "Onii" feel improper.

Yeah, it's an attempt at being overly correct where it is, in fact, not correct.

It's a little bit comparable to taking a german name like "Oehler" and writing it "Öhler", because you realize that "Oe" is a digraph for "Ö" (and the name's pronunciation matches that), when in fact the name "Oehler" is written as "Oehler".

For exactly the same reason you might be tempted to write daemon as "dämon" because, again, digraph and pronunciation match, and the german word Dämon is actually correct, yet it still wouldn't be right to do that for what is known as a "daemon" in operating systems.

>Until the early twentieth century, the œ and æ ligatures had been commonly used to indicate an etymological connection with Latin or Greek.

https://en.wikipedia.org/wiki/List_of_words_that_may_be_spel...

https://en.wiktionary.org/wiki/daemon

https://en.wiktionary.org/wiki/d%C3%A6mon

Can you provide a solid source so I can fix all of this apparently-wrong information?

The word for computer "daemon" has an etymological connection to the daemon you are linking to here, it does not mean that it is the same word.

When you take an existing word and add a trade-specific meaning, you are not creating a new word.

If that were the true, Etymology itself would be meaningless, because words coming from other words would be considered "the same".

Yes, but the spellings valid in the trade context may differ from the spellings valid for the other meanings of the word. Consider "dialog" vs. "dialogue", or "disc" vs. "disk" (which have different connotations for the two spellings).

yep

> According to Fernando J. Corbato who worked on Project MAC in 1963, his team was the first to use the term daemon, inspired by Maxwell's demon, an imaginary agent in physics and thermodynamics that helped to sort molecules.

https://en.wikipedia.org/wiki/Daemon_(computing)#Etymology

I'd appreciate the cool factor if computing stuck with the ligature, but I wouldn't appreciate looking up how to type it every time.

I'd appreciate the cool factor if computing stuck with the ligature, but I wouldn't appreciate looking up how to type it every time.

Just for the curious, in Vim (possibly other Vi derivatives?) you can press Ctrl-K, A, E in sequence: æ (copy/pasted from my terminal).

> The ligature has no place in writing about computer daemons.

Surely we only write the simplified 'daemon' because for several decades mass-market typesetting was too limited to handle the ligature? Under the covers, if you will, it has always had æ in it but the UI was unable to render it.

Pedantically we should still all write encyclopædia but it fell out of custom in casual use because of the awkwardness of typing it.

Dbus, a Freedesktop project, being insular with Systemd? Perish the though...

At this point in time the sane thing to do would be to stay away from anything Freedesktop, Gnome, or Systemd. Otherwise you will find your future dictated by RH/Fedora whims.

> The obvious thing to do is for the bus controller dæmon to hand off the task of starting and managing these dæmons to a dæmon management subsystem. Unfortunately, ... the writers of D-Bus didn't make it capable of talking to any of them.

but, not two sentences later,

> the bus controller dæmon talks ... to systemd and tells it to start the relevant dæmon(s)

Did I miss something? Or is this just exaggerated systemd butthurt?

I think the point is that it is a problem in non-systemd setups.

It quite clearly says that there's only two modes of operation: the incorrect D-Bus activator, and the communication with systemd's internal D-Bus protocol. Nothing else.

That's not "exaggerated systemd butthurt", it's your deliberately obtuse misreading.

Isn't systemd a daemon manager that solves all the pain of managing daemons though? If you want D-Bus activation and good daemon control then just use systemd as it was designed.

You don't realize the problem with an essential component like D-Bus properly integrating only one service manager out of dozens instead of being generic, or even better - not having explicitly broken functionality to begin with?

(And no, systemd does not solve all the pain. Having to debug dependency loops, stuck job states, journal fragmentation, intertwining of system and service states, etc. isn't much fun for the benefits that I can just as easily get from something intensely more modular and sanely architected like nosh or s6.)

systemd is a daemon manager that works on a limited number of linux (and only linux) systems. Sometimes you can't use systemd, sometimes you just don't want to. Most opensource software tries to be compatible with as much ecosystem as possible so that's not a problem. That doesn't seem to be the case for dbus/systemd.

Other systems which solve the same pain: upstart, nosh, daemontools, supervisord, ...

The post's author writes a systemd-alike daemon manager named 'nosh'. Hence the complaints about the non-systemd behavior.

Also note that DBus runs on more than just Linux (BDSs and perhaps OS X or Windows), while systemD only runs on Linux.

There's some temporal disconnect here, which I think is making the two of you talk (angrily) past each other.

The D-Bus activation system was written in 2006. So was Upstart. There wasn't a better activator to use at the time on Linux; it was certainly many years before anyone even thought of systemd. This was back when we were actively using hald. And the D-Bus developer had reservations about whether Upstart in fact covered that use case:

http://lists.freedesktop.org/archives/dbus/2006-October/0061...

https://lists.ubuntu.com/archives/upstart-devel/2006-October...

So it is reasonable that the "incorrect" activator was around. Back then, D-Bus (and hald) was our systemd.

Ubuntu added Upstart activation support to D-Bus in 2010, just a few months after systemd v1 was even released:

https://lists.ubuntu.com/archives/ubuntu-devel/2010-December...

So the article has some important omissions of chronology when it claims that "the writers of D-Bus didn't make it capable of talking to any [daemon management subsystems]". I don't think jjoonathan's reading is a misreading at all.

There wasn't a better activator to use at the time on Linux

runit, s6, depinit, initng, minit, eINIT, simpleinit-msb, plain old daemontools with UCSPI, etc. etc.

There were plenty. In fact, before Ubuntu wrote Upstart, they were considering adopting initng instead. Gentoo was experimenting with it at the time, but ultimately went on to make OpenRC.

Back then, D-Bus (and hald) was our systemd.

This statement is absolute nonsense. D-Bus, HALd and systemd are three completely orthogonal and unrelated pieces of software.

Yes, but by and large the most popular activator at the time was `/etc/init.d/foo start`, so either way, you would have had to include generic support for D-Bus to actually work on any of the systems the developers cared about (Fedora and OLPC, most notably). What they have is, essentially, generic support.

I can see the argument in the blog post for having the launch helper work with the `service` command, though. Although I'm not sure `service` existed.

> D-Bus, HALd and systemd are three completely orthogonal and unrelated pieces of software.

They're not unrelated, which is what I'm trying to say if you could just listen and make a cogent response instead of calling other people's statements nonsense without understanding. They are related in the sense that the way that hardware-support services were spawned on common Linux desktops of the 2006 era was through hald. Now, the way that hardware-support services are spawned is through systemd.

If they're unrelated, why did hald disappear?

You claimed there was no other, not which one was most popular. '/etc/init.d/foo start' was an LSB-standardized initscript convention, yes. Why do you even call that an "activator" in this context?

No, that is not the definition of generic support. Generic support would be having some way to intercept system bus events so that external programs can implement on-demand bus activation.

They are related in the sense that the way that hardware-support services were spawned on common Linux desktops of the 2006 era was through hald.

Correct.

Now, the way that hardware-support services are spawned is through systemd.

Incorrect. udisks2 and upower are the official successors to HALd. Otherwise, udev usurped many of the hotplugging capabilities. udev has existed way before systemd merged it into systemd-udevd.

If they're unrelated, why did hald disappear?

Because of DeviceKit (udisks/upower) and udev evolving and HALd becoming an unmaintainable mess, by David Zeuthen's own words: http://lists.freedesktop.org/archives/hal/2008-May/011560.ht...

I'm calling your statements nonsense because they clearly are.

> You claimed there was no other, not which one was most popular.

I said there was no better one. That's very different. Absolutely they could have written daemontools or anything else activation; there was just no major or even semi-major distro that used daemontools, so there was no point.

> by David Zeuthen's own words

Which contain this: "Apart from all that, I still believe the _idea_ of having privileged mechanisms exporting useful API is the right one if one wants to make progress on the Linux desktop. And certainly, just the last year with the introduction of ConsoleKit, PolicyKit and D-Bus system bus activation shows there's a real trend going in this direction."

That's exactly why I said they're related. They're not the same thing, obviously. But the growth of things like D-Bus system bus activation enabled the various kits, enabled UDisks (which is bus-activated), etc.

There were better ones. All of the examples I listed were improvements over sysvinit.

Again, it's not explicitly supporting one scheme over another. It's more like provide a generic event queue over some channel (stream, Netlink, etc.) for processes to consume and be able to exec(3) processes in response to received events. Much like how udev consumes kernel uevents.

Yes, D-Bus system bus activation assisted in lots of desktop subsystems. Your statement that "D-Bus and hald was our systemd" doesn't make any modicum of sense, nevertheless, and is simply conceptually confused.

You're really painting broad strokes and taking liberties with the way you categorize things. I don't like poisoning semantics, it's a very dirty game.

(As a side note, an "activator" is any program that conditionally exec(3)s a binary in response to an IPC event. Something as simple as "mkfifo /path/to/pipe && sh -c 'while true; do cat /path/to/pipe >/dev/null; /path/to/program; done' &" is an activator. It's not rocket science.)

I wonder if anyone has submitted patches to dbus-daemon adding support for non-systemd "daemon managers". If the article is to be believed it should be really easy. Maybe that could have been done instead of writing a blog post? Or in addition to?

Well, no. The blog post argues it shouldn't be used for this purpose at all and to just use a service manager directly.

It's pretty easy. The right way is to patch D-Bus, but you can just drop in a replacement for dbus-daemon-launch-helper, which is a standalone executable. I've done this on a system where interactive logins took place in temporary chroots; we were having bus-spawned daemons started outside the chroot, so I just wrote a wrapper to chroot and then exec the real dbus-daemon-launch-helper.

EDIT: Also, Ubuntu has been shipping Upstart activation support in D-Bus since 2010.

The fundamental problem here is plainly, and simply, why is an ipc daemon doing anything with starting and stopping processes. I could understand a bit more if something like gnome-session was poorly starting and stopping daemons, but an ipc daemon is near the bottom of the List of things that should have that functionality.

Because you want processes to start when IPC to them is needed. The classic example here is CUPS: you don't want CUPS running all the time (init script), nor do you want it running when a printer is plugged in (HAL activation), you just want it when someone's trying to print (service activation).

Apple did exactly this with CUPS and launchd well before either D-Bus or systemd existed. D-Bus was developed around the same time as Upstart, which didn't really support service activation, and well before systemd. So what could it have asked to run CUPS, other than itself?

There was inetd and xinetd, for many years. They start a process which listens on a tcp or udp socket, only when a connection or packet is seen on that socket. I'm not sure how popular they were, but I've been using "desktop" linux since 2003 and working with production servers since 2010, and I've never seen them in actual use myself.

Services like cups use a couple of megabytes of memory. All other applications dwarf it on the desktop, and service activation isn't appropriate for servers. It's a complication which you don't need. I'm all about reducing bloat; the best way to do that is uninstall the service.

systemd supports socket activiation, and it's actually pretty cool as a startup-dependency-satisfying scheme. But this article talks about just telling systemd to start the service, not by trying to access a socket the service will listen on. And it mentions the "service" command, which is a standard way to do that on redhat and debian based distros since as long as I can remember.

So when D-Bus was developed it should have used "service $NAME start" if it really wanted to try to start a service.

The proper way to do this is to have a way for processes to consume sort of public event queue exported by the service in question, and conditionally exec(3) processes in response. Much like the kernel has uevents for device node managers to listen on over a Netlink channel. Without proper mechanism, you can't have true activation from a black box.

To re-answer your question, ideally d-bus would send the request to the session manager, which already has logic to start and stop programs as needed. If it is a system-level service, then the session manager should call the init system, through the formalized methods already set up, to start the service. The problem described in the original article is that d-bus lacks any sort of logic to figure out what to do if things go wrong, and thus causes more problems than it solves, in more difficult places to troubleshoot.

Finally, regarding d-bus' age, development on DBus started in 2002, about the same time as the first release of OS X with Cups, and well before Canonical started work on upstart. For the first several years, d-bus was just a messaging service, and it worked decently at it. Pasting on another component that starts and stops services is just asking for problems.

Reply on news.ycombinator.com