The case for the /usr merge [LWN.net]

The case for the /usr merge

Posted Jan 29, 2012 11:44 UTC (Sun) by k8to (guest, #15413)
In reply to: The case for the /usr merge by Kit
Parent article: The case for the /usr merge

Like it or not, the common programming patterns and libraries around dbus are pretty fragile. It's very common for dbus programs to fail to operate correctly if dbus isn't already running when they start up. It's common for them to fail to establish communication with launched subprocesses.

Essentially, the filesystem, pipes, sockets are pretty safe to assume to be always present, and you can develop against them without fear (though please handle the errors). With dbus, you have to handle a number of additional cases, and it seems more difficult than real programmers are going to do in reality.

For that problem alone, I question the value of having dbus at all.

Then there are the security concerns.. but that's the topic for another day.

to post comments

The case for the /usr merge

Posted Jan 29, 2012 21:48 UTC (Sun) by paulj (subscriber, #341) [Link] (4 responses)

A good example of fragile DBus programming patterns is systemd. Guess what happens if early boot goes wrong (e.g. cryptsetup fails on some not-very-important filesystem) and you get dumped to a rescue shell and you try use systemctl? A nice "Can't connect to message-bus" type of error.

Why on earth is systemctl not talking *directly* to systemd??

The case for the /usr merge

Posted Jan 30, 2012 0:11 UTC (Mon) by mezcalero (subscriber, #45103) [Link] (3 responses)

This is simply not true. systemd speaks the D-Bus protocol without relying on the D-Bus daemon. One of the nice things about systemd is that is is fully introspectable even if the only processes running are systemd itself and a bash. For example, boot into emergency mode by passing "emergency" on the kernel cmdline, and you'll see that "systemctl" works just fine even though no processes between PID 1 and bash are around.

Don't spread obvious falsehoods, please!

The case for the /usr merge

Posted Jan 30, 2012 1:35 UTC (Mon) by slashdot (guest, #22014) [Link]

paulj seemed to speak from experience though, so maybe (some past version of?) systemctl first tries to talk via dbus, but doesn't always properly fallback to direct communication when that fails?

The case for the /usr merge

Posted Jan 30, 2012 12:20 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

Systemctl gives DBus connection errors in certain situations. And, other than to those quite familiar with systemd, it's NOT an obvious falsehood. I know you get a lot of uncalled-for personal crap from snipers, but does it help for you to respond to other people in a bordering-on-insulting fashion?

Here's what I was going by:

https://picasaweb.google.com/114169232705420738100/System...

I'm not sure, but there's probably some combination of a couple of silly little bugs here:

a) If emergency mode had root mounted RO (I'm not sure if that happened at shutdown or at beginning of emergency mode): Going to emergency mode with root RO when some ancillary fs has failed to mount (I don't remember what old initscripts did, but I think they first mounted / RW before mounting rest?)

b) Shutdown having become fragile in the face of a RO /. I've had old init + initscripts in a similar situation, & services would fail to stop, but init would eventually reboot anyway. A fragile reboot can be a huge problem if you're remote and have no physical access to the power/reset buttons.

c) A slightly misleading or confusing error message from systemctl.

d) Unrelated to my original post, but also evident in those photos: Parallel jobs stomp over the tty with output. Particularly confusing if you've missed the fact you're supposed to type in a passphrase. (This possibly isn't a little bug, in terms of fixing it).

Bugs, which will be fixed no doubt, I'm sure. Also, just because a messenger doesn't have a perfectly set-out message, doesn't mean the messenger should then be shot.

The case for the /usr merge

Posted Jan 30, 2012 16:55 UTC (Mon) by michich (guest, #17902) [Link]

If you can find a sequence of steps to reproduce the problem reliably, please file a bug in Bugzilla.

But... the second screenshot shows 2.6.34.7-66.fc13. Are you really running Fedora 16 on a kernel from Fedora 13?