OpenSuSE Leap 15.1 suffers from a 90 seconds delay during shutdown/reboot.
Here are the relevant lines of a log file I managed to produce.
Anyone an idea what is going on here?
76.984308] systemd[1]: klog.service: Failed to send unit remove signal for klog.service: Transport endpoint is not connected
76.984320] systemd[1]: winbind.service: Failed to send unit remove signal for winbind.service: Transport endpoint is not connected
77.002581] systemd[1]: Hardware watchdog ‘iTCO_wdt’, version 0
77.002600] systemd[1]: Set hardware watchdog to 10min.
77.002606] watchdog: watchdog0: watchdog did not stop!
77.015101] systemd-shutdown[1]: Sending SIGTERM to remaining processes…
77.019276] systemd-journald[473]: Failed to forward syslog message: Connection refused
77.019471] systemd-journald[473]: Failed to forward syslog message: Connection refused
77.019593] systemd-journald[473]: Received SIGTERM from PID 1 (systemd-shutdow).
77.019608] systemd-journald[473]: systemd-journald stopped as pid 473
167.020886] systemd-shutdown[1]: Sending SIGKILL to remaining processes…
167.027376] systemd-shutdown[1]: Sending SIGKILL to PID 484 (lvmetad).
Hi, I witnessed something similar during the beta phase but apparently with different logs: see https://bugzilla.opensuse.org/show_bug.cgi?id=1129476
But I must say that I haven’t seen that behaviour after the General Availability release, so I was thinking of closing that bug report.
Apparently it is something HW related and I was wondering if somebody else witnessed that odd 90 s delay…
Let me know if I can do some further testing.
I read your link.
Every time I followed these these instructions:.
> boot to multi-user.target (just adding ‘3’ to the boot command line)
> login as root and issue ‘systemctl isolate graphical.target’ on VT1
> login as normal desktop user via GDM (desktop shows on VT2)
> logout as ‘root’ from VT1
> work on the desktop (VT2) as usual, reboot or shutdown from desktop when finished.
the shutdown time was normal. But as soon as I booted default to the graphical desktop, the 90seconds delay came back when shutting down.
Well, at least the problem seems reproducible on your system, with Leap 15.1 beta I had some 2 “normal” reboots out of 5 and now after the official release every reboot was fine so far.
I think that joining the bug report with your results is a good idea, apparently there are very few of us witnessing this and the developers may not be able to reproduce and fix this problem without our help.
I also have this problem with two desktop PCs. They have both been upgraded with the Leap 15.1 DVD from 15.0. The systems have different hardware except they both have the same Radeon HD 6450 1GB graphics. I will try deleting liblvm2app2_2, liblvm2cmd2_02, lvm2 as suggested above and see what happens. :\
Apparently lvmetad ignores SIGTERM and a 90s timeout is triggered, but the details are beyond my understanding,
It seems that this behaviour has been around for some time and the 90s timeout was introduced in systemd 231, so we should see this problem also in Leap 15.0.
Maybe something has changed in the boot/shutdown timing in Leap 15.1 so that now some systems trigger the undesired timeout.
Until somebody comes up with a better fix, I’m just running with all lvm services disabled since I don’t use lvm at all on the troubled laptop.
There was one occasion when shutting down seemed to have an unnecessary delay. But it hasn’t happened since. And I did not check logs for that one occasion, so I’m not sure what happened. Mostly by 15.1 shutdowns are reasonably fast.
Uninstalling the lvm2 rpms fixed my pc as well.
Reboot or shutdown would hang for 90 seconds.
System details:
The pc is a tower, Intel i7-8700K 6 core, all SSD devices, no spinning drives.
Built in Intel 630 HD graphics, 16 GB ram.
Two CT500MX500SSD1 devices for sda and sdb (openSUSE).
One CT500MX500SSD4 device for sdc (windows 10)
root (sda1) is ext4, /home (sda2) is XFS (2 partitions on one 500 GB SSD).
/data1 (sdb1) is an XFS data partition on a second 500 GB SSD.
Updated from 15.0 to 15.1 via full install dvd, reformatting root,
then reinstalled 3rd party apps after install and reboot - google chrome, google earth.
Windows dual boot is on the 3rd (sdc) nvme SSD. sdc1 is the /boot/efi partition.
Dual boot works fine.
On last update 29 May ~ 1 June of LEAP 15.1 , on 3 machines I have (one on XFCE, 2 on KDE) shutdown almost does not work. I have to cut power to shut down which I do at a stalled screen. This is major problem.
Also opening is much delayed.
This is first problem for me with openSUSE in about 8 years of doing updates. Reliability is why I use openSUSE.
Regret I cannot get screen shot of closing problem.
System1 : Dell Latitude E6530, 8 GB RAM, i7 Intel Intel graphics. System 2 (old) Acer Aspire 7520, 4 Gb RAM. System3 (old) HP (circa 2014) RAM 4 Gb Intel chip only on KDE desktop with Intel graphics. Dell has KDE and XFCE desktop capability.
No problem here, even on the laptop that had that nasty 90s delay at reboot. The kernel seems the only recent update capable of causing major problems; maybe you have some HW which require a driver that has been updated?
Apparently the new nouveau driver has problems with some GPUs: https://bugzilla.opensuse.org/show_bug.cgi?id=1137067
Can you boot with the “modprobe.blacklist=nouveau” boot option? Or you can simply boot the previous kernel and possibly uninstall/taboo the new kernel if it is really the culprit.
Removing the three lvm2 packages the problem seems solved on the laptop (a tuxedo infinity pro processor= Intel Core i7-8565U, RAM=32Gb, 2TB SSD disk) but not solved on the desktop computer, if it can be useful I attach the two shutdown log (obtained following the instructions here https://freedesktop.org/wiki/Software/systemd/Debugging/ ) of the laptop where the problem seems solved:
You can do what I did with your last problem. Copy and paste the suspect lines into various search engines (duckduckgo, google, bing, yahoo, yacy, gigablast, metager) and read the forum posts and bug reports they find.
erlangen:~ # journalctl -b -1 -o short-monotonic|grep slice
11.343988] erlangen systemd[1]: Created slice User Slice of UID 475.
17.724135] erlangen systemd[1]: Created slice User Slice of UID 1000.
28.029387] erlangen systemd[1]: Removed slice User Slice of UID 475.
89.648156] erlangen systemd[1]: Created slice User Slice of UID 475.
96.739412] erlangen systemd[1]: Created slice User Slice of UID 1001.
106.952788] erlangen systemd[1]: Removed slice User Slice of UID 475.
2274.221444] erlangen systemd[1]: Removed slice system-getty.slice.
** 2276.181448] erlangen systemd[1]: Removed slice User Slice of UID 1000.
2364.278105] erlangen systemd[1]: Removed slice User Slice of UID 1001.
2366.039988] erlangen systemd[1]: Removed slice User and Session Slice.**
2366.069253] erlangen systemd[1]: Removed slice system-systemd\x2dfsck.slice.
erlangen:~ #
UID 1000 terminates immediate, UID 1001 first hits the timeout of 90 secs and then shutdown proceeds properly by removing slice User and Session within 2 seconds.
