
Systemd-logind must be restarted to prevent delay - ivank
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1591411
======
userbinator
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
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
Try waiting 25 seconds.

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

~~~
digi_owl
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.

~~~
natermer
> 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.

~~~
craigsmansion
> Besides that it is pretty obvious that the standardization [..] has resulted
> in massive reduction of bugs and complexity.

If that were true it would be easy to see the difference in outstanding bugs
between distributions that adopted SystemD and those who haven't, since their
bug-numbers would be orders of magnitudes larger. To my knowledge this isn't
so.

From a larger perspective you are arguing for the benefits consolidation and
unification, as in 'If only we had one X (where X can be a Desktop
Environment, GUI toolkit, Editor, etc), every developer could focus their
effort on that, innovation would be quicker and adoption of the OS would be
better (and we would finally have "the year of the desktop").

It is a pretty idea, to boost productivity through standardisation, but by now
decades of free OS development (and proprietary OS development, to illustrate
the value of mono-cultures and cathedral planning) have shown it does not
work.

As of now, SystemD adoption hinders the development of:

-alternative cgroup managers

-non-affiliated container development

-DE development on non-linux systems

-GNU running on alternative kernels

-adoption and development of alternative init systems

Now none of these directly affect the Desktop Experience, so many will not
care. But standardisation is not necessarily a direct benefit, or even a net
benefit from a larger--long-term--context, especially in the Free Software
world.

~~~
tveita
Successful standardization of protocols and formats tend to benefit the entire
software ecosystem, both open source and otherwise.

Standardization on a specific implementation has a greater risk of stagnation,
and encourages fragile software relying on undocumented and sometimes
unintended behavior.

~~~
snaky
> Successful standardization of protocols and formats tend to benefit the
> entire software ecosystem

It depends on how good those protocols and formats are. Let's look at OSI
protocol stack which is failed miserably on that task exactly.

------
api
That's okay. Sooner or later they'll get around to integrating ssh into
systemd to fix this.

/joking

I hope.

~~~
wmf
I hope they replace PAM first; I've never had a good experience with it.

~~~
d33
What makes you think they'd do a good job?

~~~
Spivak
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.

------
beedogs
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?

~~~
dijit
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
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
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.

~~~
rhinoceraptor
My point is the overwhelming majority of (technical) people simply don't care
about init. I search for 'how to enable service in Linux X'. If I'm a real
wizard, I might even write a simple init script. But the amount that I care or
think about init is basically nil.

~~~
dijit
the problem isn't necessarily init.

it's everything else.

The lock in, the increasing lack of interoperability, the hostility, the
increasing controversies.

But also, it's a little bit the init, which could have been designed much
better.

------
chmike
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 ?

~~~
snaky
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
Alternatively there is a Funtoo, a fork of Gentoo which blocks systemd.

~~~
snaky
Actually there's more distributives without systemd, Gentoo is different
because it just gives a choice - with systemd, udev, dbus or almost anything
else.

