Problems with latest systemd 226-3

Irok · 2016-04-11 10:26:31

Install watchdog, enable and start it:

$pacman -S watchdog

$systemctl enable watchdog.service

$systemctl start watchdog.service

$sync

Reload daemons

$systemctl daemon-reload

In /etc/systemd/system.conf

From:

#DefaultTimeoutStartSec=90s

#DefaultTimeoutStopSec=90s

To:

DefaultTimeoutStartSec=10s

DefaultTimeoutStopSec=10s

delete "#" set to ten seconds and save the changes

Reload daemons

$systemctl daemon-reload

Last edited by Irok (2016-04-17 16:25:28)

ggoranov · 2016-04-11 10:29:57

Yes, I did all of it and watchdog is enabled. I think my problem is elsewhere since the 10 seconds timeout change does not take effect.

Last edited by ggoranov (2016-04-11 10:51:48)

Irok · 2016-04-11 13:17:12

You mean that the file do not change or that it do not work?

ggoranov · 2016-04-11 13:30:06

The file is changed but it did not have effect on the shut down execution.

Irok · 2016-04-11 13:41:58

Give us more information about your system, it usually works for everybody

ggoranov · 2016-04-11 14:38:56

I am a bit new to Arch linux and I am not completely sure what is need but here is some info:
* Display server - xorg-server 1.18.3-1
* Display manager - sddm 0.13.0-2
* Desktop environment - KDE5

I have not installed a driver for the GPU (which is AMD r7 M265) cause it seems the distribution currently runs out of the internal intel GPU. For that reason I get the following error when the machine boots or shuts down:

Apr 11 13:48:43 ggoranov-e450 kernel: [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 3 test failed (scratch(0xC040)=0xCAFEDEAD)
Apr 11 13:48:43 ggoranov-e450 kernel: [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 4 test failed (scratch(0xC040)=0xCAFEDEAD)
Apr 11 13:48:43 ggoranov-e450 kernel: [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 5 test failed (scratch(0xC040)=0xCAFEDEAD)
Apr 11 13:48:43 ggoranov-e450 kernel: [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 6 test failed (scratch(0xC040)=0xCAFEDEAD)
Apr 11 13:48:44 ggoranov-e450 kernel: [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 7 test failed (scratch(0xC040)=0xCAFEDEAD)
Apr 11 13:48:44 ggoranov-e450 kernel: [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 8 test failed (scratch(0xC040)=0xCAFEDEAD)
Apr 11 13:48:44 ggoranov-e450 kernel: [drm] ring test on 9 succeeded in 6 usecs
Apr 11 13:48:44 ggoranov-e450 kernel: [drm] ring test on 10 succeeded in 6 usecs

Afterwards I get the timeout waiting message:

Apr 11 13:48:45 ggoranov-e450 sddm[277]: Running display setup script "/usr/share/sddm/scripts/Xsetup"
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Display server started.
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Socket server starting...
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Socket server started.
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Greeter starting...
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Adding cookie to "/var/run/sddm/{d780a6aa-50a4-4cf7-80d0-e841f95d55ce}"
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Signal received: SIGTERM
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Socket server stopping...
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Socket server stopped.
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Display server stopping...
Apr 11 13:48:45 ggoranov-e450 sddm-helper[1089]: [PAM] Starting...
Apr 11 13:48:45 ggoranov-e450 sddm-helper[1089]: [PAM] Authenticating...
Apr 11 13:48:45 ggoranov-e450 sddm-helper[1089]: [PAM] returning.
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Display server stopped.
Apr 11 13:48:45 ggoranov-e450 sddm[277]: Running display stop script "/usr/share/sddm/scripts/Xstop"
Apr 11 13:48:45 ggoranov-e450 sddm[277]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.
Apr 11 13:48:45 ggoranov-e450 systemd[1]: Stopped Simple Desktop Display Manager.
Apr 11 13:48:46 ggoranov-e450 systemd[1]: Stopped Watchdog Daemon.
Apr 11 13:50:12 ggoranov-e450 systemd[1]: session-c2.scope: Stopping timed out. Killing.
Apr 11 13:50:12 ggoranov-e450 systemd[1]: Stopped Session c2 of user ggoranov.
Apr 11 13:50:12 ggoranov-e450 systemd[1]: session-c2.scope: Unit entered failed state.
Apr 11 13:50:12 ggoranov-e450 systemd[1]: Removed slice User Slice of ggoranov.

You can see how the log jumps from 13:48:46 to 13:50:12. This should be the waiting period.

firekage · 2016-04-11 16:04:47

ggoranov wrote:

Irok wrote:
Hi, solution working for me :
Install watchdog enable the service with systemctl and start it, reload daemons.
in /etc/systemd/system.conf file reduce the time to ten secons as berbae said
Do not mess with the hooks can cause that swap fails at boot
I am using conky and chromium in plasma destopk and the combination of this two solutions solved the problem for me ( no message stop job is running for session C1 )

That fixed the problem for me as well

I don't think that it is solution for everyone - i have 3 machines. On all of them it does not work. Watchdog installed, enabled, running.

Irok · 2016-04-11 16:08:53

The problem is not the solution to the error, it should work when you finish to install the drivers.

Irok · 2016-04-11 16:13:14

firekage, meaby you are right and don't work for everybody, did you set to ten seconds in /etc/systemd/system.conf?

I guess you have differents desktops and display managers, it should worked unless in one of them.

Last edited by Irok (2016-04-11 16:20:15)

Irok · 2016-04-11 16:45:50

anyway check here too https://github.com/systemd/systemd/issues/1615 there is another solution totally diferent that may work by Ebiggers posted by Potomac 12 days ago, I have no problem with the solution I posted and shutdown is normal. I have no test this solution so do it on your own risk. Some users say it works, as mine worked for me and others I did not check more.

Last edited by Irok (2016-04-11 17:01:56)

firekage · 2016-04-11 18:28:12

Irok wrote:

firekage, meaby you are right and don't work for everybody, did you set to ten seconds in /etc/systemd/system.conf?
I guess you have differents desktops and display managers, it should worked unless in one of them.

Yes, i did it, i did it exacly for 10 second. I have 3 machines (desktop with Intel Skylake I7-6700K, netbook with Intel Atom N2600, and laptop with Intel Pentium B960) that have Arch installed (64 bit) with KDE (Plasma 5 display manager) and all of them have the same problem.

Irok wrote:

anyway check here too https://github.com/systemd/systemd/issues/1615 there is another solution totally diferent that may work by Ebiggers posted by Potomac 12 days ago, I have no problem with the solution I posted and shutdown is normal. I have no test this solution so do it on your own risk. Some users say it works, as mine worked for me and others I did not check more.

I wil check it. Thanks.

Edit: i forget about it. This also does not work for me.

Last edited by firekage (2016-04-11 18:30:11)

ggoranov · 2016-04-11 18:55:07

The workaround related to coredump works for me as well

Potomac commented 12 days ago
There is a workaround found by Ebiggers :
just create a file "/etc/sysctl.d/50-coredump.conf" with the following contents:
kernel.core_pattern=core
then after a reboot this bug will never occur

Irok · 2016-04-11 19:33:51

Well we have now two choices then, firekage is extrange that not work for you cause I am using plasma as well. I had doubts in xcfce with slim. I'm sorry that doesn't work for you. Try installing grsec as last chance to my solution.

Last edited by Irok (2016-04-11 20:04:05)

mrunion · 2016-04-12 15:10:37

I first admit that I just skimmed this thread, so if I missed this already, please forgive me.

But...I run OpenBox and have no shutdown problems. But when I boot my test user with KDE/Plasma, the machine won't shut down. If I force a power off and use OpenBox again, it will shutdown as normal.

Does that even help at all?

Layus · 2016-04-13 08:15:03

There appears to be two distinct issues with systemd 226-3 (and some other versions).

The first one is an issue with coredumps when killing applications, and is described at https://github.com/systemd/systemd/issues/2691. Related github issues are https://github.com/systemd/systemd/issues/1615 and many others.

The other is a bug with applications refusing to die, and is not an issue with systemd, but with the application itself. This is the case with conky for example.
Both cases are linked with the application reacting badly to the SIGTERM sent to to them when the system goes down.
- In the first case, the application crashes, but a bug with coredumps makes the system wait forever on the coredump service that can not start during shutdown. See https://github.com/systemd/systemd/pull/2993 for an attempt at fixing it.
- In the second case, the application ignores (or misses) the SIGTERM signal and continues running, unaware of the shutdown.
As systemd cannot tell this situation from a service requiring more time to exit cleanly, it must wait untill the hard limit of 90s before killing the process with SIGKILL. Fixing the application is the way to go. For conky I have submitted https://github.com/brndnmtthws/conky/pull/233.

Of course, this does not explain why so many programs started to fail with systemd versions around 229-3.
I think one explanation might be that systemd started to send SIGHUP on top of SIGTERM (as outlined in post #44).
SIGHUP is often used to tell processes to reload their configuration.
The processes failing to shutdown properly are probably not handling correctly a reload operation during their exit sequence (chromium ?).

This topic and linked pages are already full of short-term solutions, so I will not summarize them here.

Irok · 2016-04-14 14:22:57

The problem with chromium is not chromium itself is the flash pluggin (in my opinion).

Last edited by Irok (2016-04-14 15:07:20)

Irok · 2016-04-17 16:24:13

Sorry, I forget to add to the solution use sync after start and enable watchdog

Clouseau · 2016-04-21 07:18:22

I have this issue too, shutdown 90s timeout. Do not use conky, I am on uptodate system with plasma 5 and sddm.

Irok · 2016-04-21 11:35:15

Clouseau wrote:

I have this issue too, shutdown 90s timeout. Do not use conky, I am on uptodate system with plasma 5 and sddm.

Did you try what I posted?, it should work

Install watchdog, enable and start it:

$pacman -S watchdog

$systemctl enable watchdog.service

$systemctl start watchdog.service

$sync

Reload daemons

$systemctl daemon-reload

In /etc/systemd/system.conf

From:

#DefaultTimeoutStartSec=90s

#DefaultTimeoutStopSec=90s

To:

DefaultTimeoutStartSec=10s

DefaultTimeoutStopSec=10s

delete "#" set to ten seconds and save the changes

Reload daemons

$systemctl daemon-reload

Last edited by Irok (2016-04-21 11:49:54)

Irok · 2016-05-08 11:09:51

The problem is back again after a few reboots with latest update. This time with a difference. I can see clearly that is related to core dumps.

Last edited by Irok (2016-05-14 02:00:37)

Pyntux · 2016-05-17 22:16:05

I didi not tried solution with watchdog, but I tried making

 "/etc/sysctl.d/50-coredump.conf"

with " kernel.core_pattern=core" in file, and problem with hanging 90 sec is solved, but I have some strange core dump files in /home/user dir...every file (for now 3 files) are about 60mb...So I deleted that script...

I will try now with watchdog...

Last edited by Pyntux (2016-05-17 22:16:45)

beta990 · 2016-05-18 08:27:28

Irok wrote:

[.]

This works for me, I didn't needed to install the watchdog.
I recommend to increase the timeout a bit, since on slow HDD's it may need a few more secs. to complete running jobs.

Just see I have this line uncomment: ShutdownWatchdogSec=2min

Last edited by beta990 (2016-05-18 08:35:17)

Irok · 2016-05-20 00:51:57

Pyntux wrote:

I didi not tried solution with watchdog, but I tried making
 "/etc/sysctl.d/50-coredump.conf"
with " kernel.core_pattern=core" in file, and problem with hanging 90 sec is solved, but I have some strange core dump files in /home/user dir...every file (for now 3 files) are about 60mb...So I deleted that script...
I will try now with watchdog...

I recommend in your case do not use it, it works but chek your home, is going to be full of coredumps logs. In stead disable the core dumps:

ln -s /dev/null /etc/sysctl.d/50-coredump.conf

or

echo '* hard core 0' >> /etc/security/limits.conf

First one was the option I am using now, the watchdog solution I proposed is obviusly a dirty job only for a short time, but this never ends. The problem now seens only to be related to coredumps (in my case I can see it clearly), as it is not important for average user disable the coredumps is a cleaner solution that the one I proposed.

Pyntux · 2016-05-20 04:49:09

Irok wrote:

I recommend in your case do not use it, it works but chek your home, is going to be full of coredumps logs. In stead disable the core dumps:
ln -s /dev/null /etc/sysctl.d/50-coredump.conf
or
echo '* hard core 0' >> /etc/security/limits.conf
First one was the option I am using now, the watchdog solution I proposed is obviusly a dirty job only for a short time, but this never ends. The problem now seens only to be related to coredumps (in my case I can see it clearly), as it is not important for average user disable the coredumps is a cleaner solution that the one I proposed.

I tried with watchdog and that did not solve problem. But now 90sec bug is here only when I reboot (from KDE), for shutdown works good. Even if I first logout to sddm, than reboot, everything works...Very strange...

Are there any disadvantages iof turning off core dumps?

Irok · 2016-05-20 12:31:46

Pyntux wrote:

Irok wrote:
I recommend in your case do not use it, it works but chek your home, is going to be full of coredumps logs. In stead disable the core dumps:
ln -s /dev/null /etc/sysctl.d/50-coredump.conf
or
echo '* hard core 0' >> /etc/security/limits.conf
First one was the option I am using now, the watchdog solution I proposed is obviusly a dirty job only for a short time, but this never ends. The problem now seens only to be related to coredumps (in my case I can see it clearly), as it is not important for average user disable the coredumps is a cleaner solution that the one I proposed.
I tried with watchdog and that did not solve problem. But now 90sec bug is here only when I reboot (from KDE), for shutdown works good. Even if I first logout to sddm, than reboot, everything works...Very strange...
Are there any disadvantages iof turning off core dumps?

Hi , install watchdog does not solve in all cases the problem you must set in /etc/systemd/system.conf to ten seconds to make it work. Anyway is really dirty. No there is no problem in turn off the coredumps, even for a developer is deprecated. If someome have a different opinion please post.

Arch Linux

#51 2016-04-11 10:26:31

Re: Problems with latest systemd 226-3

#52 2016-04-11 10:29:57

Re: Problems with latest systemd 226-3

#53 2016-04-11 13:17:12

Re: Problems with latest systemd 226-3

#54 2016-04-11 13:30:06

Re: Problems with latest systemd 226-3

#55 2016-04-11 13:41:58

Re: Problems with latest systemd 226-3

#56 2016-04-11 14:38:56

Re: Problems with latest systemd 226-3

#57 2016-04-11 16:04:47

Re: Problems with latest systemd 226-3

#58 2016-04-11 16:08:53

Re: Problems with latest systemd 226-3

#59 2016-04-11 16:13:14

Re: Problems with latest systemd 226-3

#60 2016-04-11 16:45:50

Re: Problems with latest systemd 226-3

#61 2016-04-11 18:28:12

Re: Problems with latest systemd 226-3

#62 2016-04-11 18:55:07

Re: Problems with latest systemd 226-3

#63 2016-04-11 19:33:51

Re: Problems with latest systemd 226-3

#64 2016-04-12 15:10:37

Re: Problems with latest systemd 226-3

#65 2016-04-13 08:15:03

Re: Problems with latest systemd 226-3

#66 2016-04-14 14:22:57

Re: Problems with latest systemd 226-3

#67 2016-04-17 16:24:13

Re: Problems with latest systemd 226-3

#68 2016-04-21 07:18:22

Re: Problems with latest systemd 226-3

#69 2016-04-21 11:35:15

Re: Problems with latest systemd 226-3

#70 2016-05-08 11:09:51

Re: Problems with latest systemd 226-3

#71 2016-05-17 22:16:05

Re: Problems with latest systemd 226-3

#72 2016-05-18 08:27:28

Re: Problems with latest systemd 226-3

#73 2016-05-20 00:51:57

Re: Problems with latest systemd 226-3

#74 2016-05-20 04:49:09

Re: Problems with latest systemd 226-3

#75 2016-05-20 12:31:46

Re: Problems with latest systemd 226-3

Board footer