Hacker News Reader

Comment by NeutronBoy | Hacker News Reader

It looks like it's an issue with dbus queueing connections, and systemd's interaction triggering an edge case.

Are we really just posting bugs in widely-used software now?

It's so HN can have its 2 minutes of hate against systemd. A systemd dev opening a GitHub issue[1] was enough to get 194 votes and 284 comments.

[1]https://news.ycombinator.com/item?id=11797075

It can also be because people want others to know that they're not alone when they see strange delays when logging into production systems and there's a fix for it that you probably want to know about.

Yes, that is in fact why I submitted it. It took a while to figure out it wasn't happening just because my server was overloaded.

both sides are really toxic here. that's a problem.

even a compile time switch was not feasible for tmux (to enable pam). while systemd still lacks a good api design that is close to daemon(). in a world with so much communication we should at least try to work together..

Why is something like daemon() needed with systemd? Typically you just run your process as if it was in the foreground, and systemd handles the rest. What do you lose?

Tmux, GNU Screen, nohup, detach...

Unless you change a single config setting in systemd.

Which distributions already do for you.

Changing the config settings that logind applies to session units is the inferior solution. The superior solution is for logind to use KillUnit to send a hangup signal, leaving StopUnit for use at system shutdown.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

daemon() doesn't distinguish between terminal window life cycle and desktop session life cycle.

That was the original issue that caused the problem with systemd, not detaching process from terminal.

Adding any type of compile time switch adds extra maintenance burden and adds one more thing to test, one more thing that needs to be checked for regressions. One more thing may not seem like much, but increasing the maintenance burden on a project that had nothing to do with the reason something was broken in the first place seems incredibly one-sided and wrong.

It's not that simple. Without PAM support, tmux is already broken, even on non-systemd distributions, in some corner cases. E.g., starting gpg-agent the "wrong" way breaks it inside tmux sessions, even on sysvinit, if tmux does not register PAM sessions.

But, of course, because the bug is only seeing wide-spread attention since systemd triggers it more often, it can't get fixed, because Lennart is the reason we cannot have nice things. Or something.

I think it's more of "systemd has this ridiculous bug! More proof that it is the end as we know it!"

I really dislike systemd as much as the next person, but this is not an issue with systemd as far as the maintainers know.

ok, dbus has this ridiculous bug, triggering crazy systemd behaviour, more proof that both of dbus and systemd are best new shiny things since sliced bread.

But systemd relies on dbus; indeed, a major reason for its existence is to dbusify every aspect of your system. And the fact that dbus, which has been around for ages, is still exhibiting strange behavior like this does not bode well for the reliability of such a system.

The whole fd.o ball of mud is well beyond the complexity threshold. It's a pain in the ass to attempt to even understand the workings of, let alone maintain. Expect to see minor to moderate shitshows like this every few months or so, and box-breaking flagdays when the maintainers decide they don't like the current interface and throw it out to write a brand new one.

In Gentoo dbus is enabled by default only on desktop profiles, and even there it may be disabled completely by one USE-flag.

So what happens when you disable Desktop Bus and use systemd?

You cannot install systemd without dbus, which must be built with USE=systemd.

    eb=/usr/portage/sys-apps/systemd/systemd-226-r2.ebuild
    grep sys-apps/dbus "${eb}" | grep '\[systemd\]'

    PDEPEND=">=sys-apps/dbus-1.6.8-r1:0[systemd]

Gentoo with USE=-systemd (explicitly disabled) continues to use OpenRC which is included by default in the standard install process.

systemd has no dependency to dbus, even in Ubunutu it's just recommended[1] - the fact that recommended dependencies in Ubuntu are installed by default is another story. In Gentoo it's the same[2], PDEPEND means soft-dependencies like plugins[3], with the difference they are not installed by default.

[1] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/14804...

[2] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/syst...

[3] https://devmanual.gentoo.org/general-concepts/dependencies/

So effectively the only configuration that makes sense for leaving out dbus would be if you want to use systemd as the host for a stack of containers (hello CoreOS). Anything more complicated and you get dbus coming along for the ride, no ifs or buts about it.

As Ford put it: you can get the model T in any color, as long as it's black.

The perfect configuration is when you disable systemd and dbus, and even udev (replacing it with eudev or better mdev).

> PDEPEND means soft-dependencies like plugins

You might want to read the docs again:

    $ man 5 ebuild | grep -A 4 '^ *PDEPEND'
        PDEPEND
            This should contain a list of all packages that should be merged
            after this one (aka post merge dependencies), but which may be
            installed by the package manager at any time, if that is not
            possible.

This is in your [3]:

https://devmanual.gentoo.org/general-concepts/dependencies/#...

> systemd has no dependency to dbus

Last time I heard anything about it, systemd was so tightly coupled to dbus it would crash PID 1 if you restarted dbus and hang the system. Maybe that's changed? I doubt it given Lennart's explanation (which, by the way, includes the claim that "D-Bus is rock solid these days").

https://lists.freedesktop.org/archives/systemd-devel/2013-Ja...

Ah, thank you! I think "dbus with no systemd" is more relevant to the user needs, because dbus is needed by at least BlueZ.

Reply on news.ycombinator.com