8 ms·

This seems like more of an issue with dbus than systemd, based on the comments on the bug tracker.

NeutronBoy 10y ago
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?
- hyperion2010 10y ago
  Nah, just shistemd.
- xiao_bai 10y ago
  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.
  - snaky 10y ago
    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.
  - bitwize 10y ago
    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.
    - snaky 10y ago
      In Gentoo dbus is enabled by default only on desktop profiles, and even there it may be disabled completely by one USE-flag.
      - JdeBP 10y ago
        So what happens when you disable Desktop Bus and use systemd?
        pdkl95 10y ago
        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.
        snaky 10y ago
        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/1480451 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/14804... [2] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/systemd/systemd-231.ebuild#n76 https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/syst... [3] https://devmanual.gentoo.org/general-concepts/dependencies/ https://devmanual.gentoo.org/general-concepts/dependencies/
        digi_owl 10y ago
        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.
- sesutton 10y ago
  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 https://news.ycombinator.com/item?id=11797075
  - Natsu 10y ago
    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.
    - ivank 10y ago
      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.
  - merb 10y ago
    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..
    - jononor 10y ago
      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?
      - digi_owl 10y ago
        Tmux, GNU Screen, nohup, detach...
        creshal 10y ago
        Unless you change a single config setting in systemd. Which distributions already do for you.
digi_owl 10y ago
Thing is, why is systemd so reliant on dbus? A bus introduced to handle signaling between desktop programs. Things used to be done kernel up. But these days it seems that things are happening DE down. Meaning that where before if the kernel came up, i had a reasonable chance of getting a shell and firing up everything else i needed from there. But these days if you don't get to the display manager you may as well hit the reset button, because something between the kernel and the display has gotten is panties so much in a twist that there is only the Windows solution.
- snaky 10y ago
  Because it's the same gang of people. > Remember that udev and sysfs are written by the same people, working together off-list. They're free to break the exported data format on a whim, because they write the code at both ends and fundamentally they're talking to themselves. They honestly say you can't expect a new kernel to work with an old udev, and they say it with a straight face. (To me, this sounds like saying you can't expect a new kernel to work with an old version of ps, because of /proc.) > Documentation is a threat to this way of working, because it would impose restrictions on them. A spec is only of use if you introduce the radical idea that the information exported by sysfs exists for some purpose _other_ than simply to provide udev with information (and a specific version of udev matched to that kernel version, at that). http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html (http://www.landley.net/notes-2015.html#05-07-2015 http://www.landley.net/notes-2015.html#05-07-2015)
  - deleted 10y ago
    [deleted]
- natermer 10y ago
  > Things used to be done kernel up. But these days it seems that things are happening DE down. The software hierarchy in order of importance, starting with most important: 1. User's needs/wants 2. User's applications 3. User's operational environment 4. application APIs 5. OS services 6. OS Kernel. The point of a OS is to make it easier to write and run applications. That is it. The 'kernel on up' design is fantasy and is NEVER how it was done in Linux or GNU or anywhere. GNU knew that User/User applications were primary importance. This is why they designed the OS following established APIs designed to help with application compatibility. Those APIs and GNU environment dictated the design of the kernel. Now as the requirements on OS rise so does the complexity. New needs/wants/desires dictate new design choices, of which filter from application on down. Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000.

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?

hyperion2010 10y ago
Nah, just shistemd.
xiao_bai 10y ago
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.
- snaky 10y ago
  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.
- bitwize 10y ago
  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.
  - snaky 10y ago
    In Gentoo dbus is enabled by default only on desktop profiles, and even there it may be disabled completely by one USE-flag.
    - JdeBP 10y ago
      So what happens when you disable Desktop Bus and use systemd?
      - pdkl95 10y ago
        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.
      - snaky 10y ago
        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/1480451 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/14804... [2] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/systemd/systemd-231.ebuild#n76 https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/syst... [3] https://devmanual.gentoo.org/general-concepts/dependencies/ https://devmanual.gentoo.org/general-concepts/dependencies/
        digi_owl 10y ago
        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.
sesutton 10y ago
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 https://news.ycombinator.com/item?id=11797075
- Natsu 10y ago
  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.
  - ivank 10y ago
    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.
- merb 10y ago
  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..
  - jononor 10y ago
    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?
    - digi_owl 10y ago
      Tmux, GNU Screen, nohup, detach...
      - creshal 10y ago
        Unless you change a single config setting in systemd. Which distributions already do for you.

digi_owl 10y ago

Thing is, why is systemd so reliant on dbus? A bus introduced to handle signaling between desktop programs. Things used to be done kernel up. But these days it seems that things are happening DE down. Meaning that where before if the kernel came up, i had a reasonable chance of getting a shell and firing up everything else i needed from there. But these days if you don't get to the display manager you may as well hit the reset button, because something between the kernel and the display has gotten is panties so much in a twist that there is only the Windows solution.

snaky 10y ago
Because it's the same gang of people. > Remember that udev and sysfs are written by the same people, working together off-list. They're free to break the exported data format on a whim, because they write the code at both ends and fundamentally they're talking to themselves. They honestly say you can't expect a new kernel to work with an old udev, and they say it with a straight face. (To me, this sounds like saying you can't expect a new kernel to work with an old version of ps, because of /proc.) > Documentation is a threat to this way of working, because it would impose restrictions on them. A spec is only of use if you introduce the radical idea that the information exported by sysfs exists for some purpose _other_ than simply to provide udev with information (and a specific version of udev matched to that kernel version, at that). http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html (http://www.landley.net/notes-2015.html#05-07-2015 http://www.landley.net/notes-2015.html#05-07-2015)
- deleted 10y ago
  [deleted]
natermer 10y ago
> Things used to be done kernel up. But these days it seems that things are happening DE down. The software hierarchy in order of importance, starting with most important: 1. User's needs/wants 2. User's applications 3. User's operational environment 4. application APIs 5. OS services 6. OS Kernel. The point of a OS is to make it easier to write and run applications. That is it. The 'kernel on up' design is fantasy and is NEVER how it was done in Linux or GNU or anywhere. GNU knew that User/User applications were primary importance. This is why they designed the OS following established APIs designed to help with application compatibility. Those APIs and GNU environment dictated the design of the kernel. Now as the requirements on OS rise so does the complexity. New needs/wants/desires dictate new design choices, of which filter from application on down. Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000.