10 ms·

Systemd-logind must be restarted to prevent delay

126 points by ivank 10y ago

api 10y ago
That's okay. Sooner or later they'll get around to integrating ssh into systemd to fix this. /joking I hope.
- yarrel 10y ago
  You know it's going to happen.
- wmf 10y ago
  I hope they replace PAM first; I've never had a good experience with it.
  - deleted 10y ago
    [deleted]
  - d33 10y ago
    What makes you think they'd do a good job?
    - Spivak 10y ago
      PAM behind the scenes seems fine, it's the interface that's clunky and prone to error. Imagine a world where a PAM would come with a file /etc/systemd/system/sssd.pam which specified all of its dependencies, what services it should be installed in, and uses Before= and After= to determine its position. Enabling SSS auth would be as simple as systemctl enable sssd.pam. And since sssd.pam would depend on sssd.service if sssd.service fails for some reason the pam module could be disabled to keep the junk out of your logs.
- pdkl95 10y ago
  Give it time; they're busy with "systemd-mount" http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Mount http://www.phoronix.com/scan.php?page=news_item&px=Systemd-M...
  - colemickens 10y ago
    Though I'm sure everyone is aware, `systemd-mount` is merely a tool that generates systemd mount units, which have been around for a while and are a helpful concept for building dependencies between services and the mounts they depend upon.
    - subway 10y ago
      Not to nitpick, but I'm fairly certain that when using mount units, systemd is directly calling mount(2), eschewing use of mount(8). edit: I also want to say until somewhat recently, systemd's mount units were just a wrapper around mount(8), but could be completely mistaken.
      - simcop2387 10y ago
        Correct, and these are still wrappers around mount(2). The whole idea with systemd-mount seems to be a way to auto-generate the units based on some set of policies.
userbinator 10y ago
Before visting the link and reading my guess was some quadratic algorithm in logging code, but after reading it seems to be a sudden jump and the explanation in poettering's fix here isn't clear either: https://github.com/systemd/systemd/pull/3191 https://github.com/systemd/systemd/pull/3191 "On overloaded systems this means that only 30 connections may be queued" --- what is it about logging in (and out) multiple times that causes a system to become "overloaded"? 1000 simultaneous logins might, but AFAICS this bug seems to be about sequential login-logout-repeat. Edit: this is what's actually causing the problem: https://github.com/systemd/systemd/issues/1961 https://github.com/systemd/systemd/issues/1961
- loeg 10y ago
  And if you follow the github thread to the bottom, the problem seems to be tracked in this freedesktop.org dbus bug: https://bugs.freedesktop.org/show_bug.cgi?id=95263 https://bugs.freedesktop.org/show_bug.cgi?id=95263 (which is no longer responding, at least for me right now).
  - throwanem 10y ago
    Try waiting 25 seconds.
xiao_bai 10y ago
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.
chmike 10y ago
In Ubuntu 15.10, systemd-login was crashing at each login. Now this. Is systemd production ready? Since it affects login, can this systemd be trusted ? Is it safe ?
- jononor 10y ago
  Did you read the thread? If not, the proposed patch (which one deployment confirmed fixed the issue) is for dbus.
- snaky 10y ago
  There's only one USE-flag in Gentoo to disable systemd completely. https://wiki.gentoo.org/wiki/Gentoo_Without_systemd https://wiki.gentoo.org/wiki/Gentoo_Without_systemd
  - onli 10y ago
    Alternatively there is a Funtoo, a fork of Gentoo which blocks systemd.
    - snaky 10y ago
      Actually there's more distributives without systemd, Gentoo is different because it just gives a choice - with systemd, udev, dbus or almost anything else.
beedogs 10y ago
And now they're taking over mounting and unmounting filesystems, too. What's it going to take to get this cancer out of Linux distros?
- to3m 10y ago
  Complaining on forums ought to do it.
- dijit 10y ago
  Moving to BSD and Gentoo in the business space. taking money away from the main driver; Red Hat. Unfortunately most companies that use Red Hat products don't actually pay for it already (My multi-national company uses CentOS)
  - rhinoceraptor 10y ago
    That seems extremely unlikely. All the people who care about systemd spend their time groveling incessantly on the internet about it. And all the people who don't care, just use it without ever giving it a second thought. And moving to BSD or Gentoo only costs businesses more money, there's no rational reason to do it for a business.
    - dijit 10y ago
      I care about systemd. Thus all my personal infra is using variants of BSD fit for the purpose and I'm pushing for my next game launch to be on FreeBSD where POSIX/Unix is required. Change is slow but it will happen if people can make convincing arguments against systemd to people who just want it to work and not break with the least amount of money. Topics like this help my cause. It's not about grovelling it's about sending a message that "if you're going to try to be the alpha and the omega then we will hold you responsible when you fail to deliver" Nobody asked them to do this, people fought against it. But here we are and they are absolutely responsible for the bugs they inflict on the world and their hostile attitudes towards other projects.
      - 10y ago

126 points by ivank 10y ago

api 10y ago

That's okay. Sooner or later they'll get around to integrating ssh into systemd to fix this. /joking I hope.

yarrel 10y ago
You know it's going to happen.
wmf 10y ago
I hope they replace PAM first; I've never had a good experience with it.
- deleted 10y ago
  [deleted]
- d33 10y ago
  What makes you think they'd do a good job?
  - Spivak 10y ago
    PAM behind the scenes seems fine, it's the interface that's clunky and prone to error. Imagine a world where a PAM would come with a file /etc/systemd/system/sssd.pam which specified all of its dependencies, what services it should be installed in, and uses Before= and After= to determine its position. Enabling SSS auth would be as simple as systemctl enable sssd.pam. And since sssd.pam would depend on sssd.service if sssd.service fails for some reason the pam module could be disabled to keep the junk out of your logs.
pdkl95 10y ago
Give it time; they're busy with "systemd-mount" http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Mount http://www.phoronix.com/scan.php?page=news_item&px=Systemd-M...
- colemickens 10y ago
  Though I'm sure everyone is aware, `systemd-mount` is merely a tool that generates systemd mount units, which have been around for a while and are a helpful concept for building dependencies between services and the mounts they depend upon.
  - subway 10y ago
    Not to nitpick, but I'm fairly certain that when using mount units, systemd is directly calling mount(2), eschewing use of mount(8). edit: I also want to say until somewhat recently, systemd's mount units were just a wrapper around mount(8), but could be completely mistaken.
    - simcop2387 10y ago
      Correct, and these are still wrappers around mount(2). The whole idea with systemd-mount seems to be a way to auto-generate the units based on some set of policies.

userbinator 10y ago

Before visting the link and reading my guess was some quadratic algorithm in logging code, but after reading it seems to be a sudden jump and the explanation in poettering's fix here isn't clear either: https://github.com/systemd/systemd/pull/3191 https://github.com/systemd/systemd/pull/3191 "On overloaded systems this means that only 30 connections may be queued" --- what is it about logging in (and out) multiple times that causes a system to become "overloaded"? 1000 simultaneous logins might, but AFAICS this bug seems to be about sequential login-logout-repeat. Edit: this is what's actually causing the problem: https://github.com/systemd/systemd/issues/1961 https://github.com/systemd/systemd/issues/1961

loeg 10y ago
And if you follow the github thread to the bottom, the problem seems to be tracked in this freedesktop.org dbus bug: https://bugs.freedesktop.org/show_bug.cgi?id=95263 https://bugs.freedesktop.org/show_bug.cgi?id=95263 (which is no longer responding, at least for me right now).
- throwanem 10y ago
  Try waiting 25 seconds.

xiao_bai 10y ago

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.

chmike 10y ago

In Ubuntu 15.10, systemd-login was crashing at each login. Now this. Is systemd production ready? Since it affects login, can this systemd be trusted ? Is it safe ?

jononor 10y ago
Did you read the thread? If not, the proposed patch (which one deployment confirmed fixed the issue) is for dbus.
snaky 10y ago
There's only one USE-flag in Gentoo to disable systemd completely. https://wiki.gentoo.org/wiki/Gentoo_Without_systemd https://wiki.gentoo.org/wiki/Gentoo_Without_systemd
- onli 10y ago
  Alternatively there is a Funtoo, a fork of Gentoo which blocks systemd.
  - snaky 10y ago
    Actually there's more distributives without systemd, Gentoo is different because it just gives a choice - with systemd, udev, dbus or almost anything else.

beedogs 10y ago

And now they're taking over mounting and unmounting filesystems, too. What's it going to take to get this cancer out of Linux distros?

to3m 10y ago
Complaining on forums ought to do it.
dijit 10y ago
Moving to BSD and Gentoo in the business space. taking money away from the main driver; Red Hat. Unfortunately most companies that use Red Hat products don't actually pay for it already (My multi-national company uses CentOS)
- rhinoceraptor 10y ago
  That seems extremely unlikely. All the people who care about systemd spend their time groveling incessantly on the internet about it. And all the people who don't care, just use it without ever giving it a second thought. And moving to BSD or Gentoo only costs businesses more money, there's no rational reason to do it for a business.
  - dijit 10y ago
    I care about systemd. Thus all my personal infra is using variants of BSD fit for the purpose and I'm pushing for my next game launch to be on FreeBSD where POSIX/Unix is required. Change is slow but it will happen if people can make convincing arguments against systemd to people who just want it to work and not break with the least amount of money. Topics like this help my cause. It's not about grovelling it's about sending a message that "if you're going to try to be the alpha and the omega then we will hold you responsible when you fail to deliver" Nobody asked them to do this, people fought against it. But here we are and they are absolutely responsible for the bugs they inflict on the world and their hostile attitudes towards other projects.
    - 10y ago