And thus my system waits for 1 minute and 30 seconds while three red stars cycle back and forth like the eye of a Cylon robot from BattleStar Gallacitica.
That msg appears almost every time I shut down. My system has become equally slow during boot up. When apps are summoned on the desktop instead of snapping into view almost instantly the busy wheel cycles for 5 to 15 seconds before the app appears. Even then, say when calling Dolphin for example, it is another 15 or more seconds after Dolphin appears before its controls respond to mouse clicks.
When DDGoing for an answer I found this bugzilla report, posted April 16, 2014 but many said they were having the problem since the beginning of that year. Systemd-208 was the version. (My systemd is 229). Various people identified various culprits: systemd-login.service, session-1.scope, or sssd. In that last regard a user posted:
But many reported that they don't use sssd. Four months after the initial post tempers were flaring because none of the "fixes" proposed worked. However, two days before the OP posted his bugzilla report Linus Torvolds made a comment about what he saw as systemd's problems:
The response from the systemd team has been to call all the reported problems "myths".
So, you can see the predicament that Kay Sievers and his crew put the Neon dev crew in, trying to workaround systemd "features".
It should be added that my own experience is that I never had a system shutdown hang like this before systemd came along.
As far as feature creep one has only to look at the systemd change logs and follow the version back in time to see how systemd is taking over (spreading like a fungus, as some claim?) activities long held by independent utilities. In deference to a bug the systemd developers deny exists is this new feature, which was added to systemd-230 (line 274) :
So, you can eliminate the 1m30s wait during shutdown, which is now a feature and not a bug, if you set KillUserProcesses=1 (yes)? What if you just want to log out? BTW, to avoid the 1m30s delay many report that the now logout first, then shutdown from the login screen. Anyway, I checked my logind.conf settings and they are:
BUT, even with that setting I still hang with that 1m30s message! That's probably because my systemd is 229, not 230. It is also obvious that "fix" for this bug, introduced by systemd, is a "work around", not a cure. The bug, which didn't exist before systemd was adopted, is in systemd and is just covered up. One of many perfect holes for a black hat, NSA or a foreign cyber hacking team.
As you read down in the logs you'll notice phrases such as "now supports" or "extended to include", etc...
Our own Snowhog posted in a bug report about this problem two months ago. He posted an image of his problem:
https://bugs.kde.org/attachment.cgi?id=99454
My suspicions are that the delays on gui appears appearing on my desktop and achieving functionality is also related to systemd problems.
Systemd is _PID1 of the boot process. The way systemd is creeping into all aspects of a Linux installation (rfkill, DNS, Bridging, IP, security, etc...), it appears that in the future there will be only three components, the kernel, systemd and the desktop.
Here is a DistroWatch poll on systemd: http://distrowatch.com/polls.php?poll=8
That msg appears almost every time I shut down. My system has become equally slow during boot up. When apps are summoned on the desktop instead of snapping into view almost instantly the busy wheel cycles for 5 to 15 seconds before the app appears. Even then, say when calling Dolphin for example, it is another 15 or more seconds after Dolphin appears before its controls respond to mouse clicks.
When DDGoing for an answer I found this bugzilla report, posted April 16, 2014 but many said they were having the problem since the beginning of that year. Systemd-208 was the version. (My systemd is 229). Various people identified various culprits: systemd-login.service, session-1.scope, or sssd. In that last regard a user posted:
I added the the following to sssd.service,
Before=systemd-user-sessions.service
So far this has worked, but I've only restarted a couple of times, so not conclusive
...
Just for clarification, for those of us who might not be checked out on systemd, the file that needs to be modified is most likely:
/usr/lib/systemd/system/sssd.service
and you put the "Before" line in the [Unit] section. You then must run:
systemctl daemon-reload
or it won't take before you reboot.
Before=systemd-user-sessions.service
So far this has worked, but I've only restarted a couple of times, so not conclusive
...
Just for clarification, for those of us who might not be checked out on systemd, the file that needs to be modified is most likely:
/usr/lib/systemd/system/sssd.service
and you put the "Before" line in the [Unit] section. You then must run:
systemctl daemon-reload
or it won't take before you reboot.
On Wed, Apr 2, 2014 at 11:42 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> The response is:
>
> "Generic terms are generic, not the first user owns them."
And by "their" you mean Kay Sievers.
Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to work around the
problems you cause.
Greg - just for your information, I will *not* be merging any code
from Kay into the kernel until this constant pattern is fixed.
This has been going on for *years*, and doesn't seem to be getting any
better. This is relevant to you because I have seen you talk about the
kdbus patches, and this is a heads-up that you need to keep them
separate from other work. Let distributions merge it as they need to
and maybe we can merge it once it has been proven to be stable by
whatever distro that was willing to play games with the developers.
But I'm not willing to merge something where the maintainer is known
to not care about bugs and regressions and then forces people in other
projects to fix their project. Because I am *not* willing to take
patches from people who don't clean up after their problems, and don't
admit that it's their problem to fix.
Kay - one more time: you caused the problem, you need to fix it. None
of this "I can do whatever I want, others have to clean up after me"
crap.
Linus
>
> The response is:
>
> "Generic terms are generic, not the first user owns them."
And by "their" you mean Kay Sievers.
Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to work around the
problems you cause.
Greg - just for your information, I will *not* be merging any code
from Kay into the kernel until this constant pattern is fixed.
This has been going on for *years*, and doesn't seem to be getting any
better. This is relevant to you because I have seen you talk about the
kdbus patches, and this is a heads-up that you need to keep them
separate from other work. Let distributions merge it as they need to
and maybe we can merge it once it has been proven to be stable by
whatever distro that was willing to play games with the developers.
But I'm not willing to merge something where the maintainer is known
to not care about bugs and regressions and then forces people in other
projects to fix their project. Because I am *not* willing to take
patches from people who don't clean up after their problems, and don't
admit that it's their problem to fix.
Kay - one more time: you caused the problem, you need to fix it. None
of this "I can do whatever I want, others have to clean up after me"
crap.
Linus
Myth: systemd is a feature creep.
Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.
Myth: systemd is unstable and buggy.
Certainly not according to our data. We have been monitoring the Fedora bug tracker (and some others) closely for a long long time. The number of bugs is very low for such a central component of the OS, especially if you discount the numerous RFE bugs we track for the project. We are pretty good in keeping systemd out of the list of blocker bugs of the distribution. We have a relatively fast development cycle with mostly incremental changes to keep quality and stability high.
Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.
Myth: systemd is unstable and buggy.
Certainly not according to our data. We have been monitoring the Fedora bug tracker (and some others) closely for a long long time. The number of bugs is very low for such a central component of the OS, especially if you discount the numerous RFE bugs we track for the project. We are pretty good in keeping systemd out of the list of blocker bugs of the distribution. We have a relatively fast development cycle with mostly incremental changes to keep quality and stability high.
It should be added that my own experience is that I never had a system shutdown hang like this before systemd came along.
As far as feature creep one has only to look at the systemd change logs and follow the version back in time to see how systemd is taking over (spreading like a fungus, as some claim?) activities long held by independent utilities. In deference to a bug the systemd developers deny exists is this new feature, which was added to systemd-230 (line 274) :
| systemd will now log about all service processes it kills forcibly |
| (using SIGKILL) because they remained after the clean shutdown phase |
| of the service completed. This should help identifying services that |
| shut down uncleanly. Moreover if KillUserProcesses= is enabled in |
| systemd-logind's configuration a similar log message is generated for |
| processes killed at the end of each session due to this setting. |
# /etc/systemd/logind.conf
# Generated by kcmsystemd control module v1.2.1.
[Login]
#NAutoVTs=
#ReserveVT=
KillUserProcesses=yes
KillOnlyUsers=jerry
#KillExcludeUsers=
#InhibitDelayMaxSec=
#HandlePowerKey=
#HandleSuspendKey=
#HandleHibernateKey=
HandleLidSwitch=poweroff
#HandleLidSwitchDocked=
#PowerKeyIgnoreInhibited=
#SuspendKeyIgnoreInhibited=
#HibernateKeyIgnoreInhibited=
#LidSwitchIgnoreInhibited=
#HoldoffTimeoutSec=
#IdleAction=
#IdleActionSec=
#RuntimeDirectorySize=
#RemoveIPC=
# Generated by kcmsystemd control module v1.2.1.
[Login]
#NAutoVTs=
#ReserveVT=
KillUserProcesses=yes
KillOnlyUsers=jerry
#KillExcludeUsers=
#InhibitDelayMaxSec=
#HandlePowerKey=
#HandleSuspendKey=
#HandleHibernateKey=
HandleLidSwitch=poweroff
#HandleLidSwitchDocked=
#PowerKeyIgnoreInhibited=
#SuspendKeyIgnoreInhibited=
#HibernateKeyIgnoreInhibited=
#LidSwitchIgnoreInhibited=
#HoldoffTimeoutSec=
#IdleAction=
#IdleActionSec=
#RuntimeDirectorySize=
#RemoveIPC=
As you read down in the logs you'll notice phrases such as "now supports" or "extended to include", etc...
Our own Snowhog posted in a bug report about this problem two months ago. He posted an image of his problem:
https://bugs.kde.org/attachment.cgi?id=99454
My suspicions are that the delays on gui appears appearing on my desktop and achieving functionality is also related to systemd problems.
Systemd is _PID1 of the boot process. The way systemd is creeping into all aspects of a Linux installation (rfkill, DNS, Bridging, IP, security, etc...), it appears that in the future there will be only three components, the kernel, systemd and the desktop.
Here is a DistroWatch poll on systemd: http://distrowatch.com/polls.php?poll=8
So, I'm going nowhere, because there is really nowhere to go.
It seems I still need "dbus-run-session" prefixing most gui applications in the KMenu system or in a Konsole. I supposed more updates will fix that later on.
Comment