When shutting down Leap, it stops for about 1 minute showing a black login window, before continuing
This is really annoying. Ubuntu does not have this problem at all, so it is not my machine
Browsing the web I found this a rather common openSUSE phenomenon, but the offered “solutions” did not help,
like acpi=no or =force as grub2 parameter.
Being somewhat new to openSUSE, how can I log the shutdown sequence to analyze the problem?
Not only Leap 42.1, also 13.2 . . .
The Plymouth graphic is not restarted for shutdown/poweroff – instead of that the tty1 screen is displayed.
There is also the issue of dismounting auto-mounted NFS directories . . .
Examining a previous journal session indicates that on this machine takes about 39 seconds before the last journal entry is written.
With respect to Plymouth, the journal indicates the following at shutdown/poweroff:
Okt 21 20:41:19 xxx kdm[3733]: plymouth is NOT running
Okt 21 20:41:19 xxx org.kde.kuiserver[4064]: kuiserver: Fatal IO error: client killed
Okt 21 20:41:19 xxx org.gtk.vfs.Daemon[4064]: A connection to the bus can't be made
Okt 21 20:41:19 xxx org.gtk.vfs.Daemon[4064]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
Okt 21 20:41:19 xxx kdm[3733]: plymouth should quit after server startup
Okt 21 20:41:20 xxx kdm[3733]: Quitting Plymouth with transition
Okt 21 20:41:20 xxx kdm[3733]: Is Plymouth still running? no
Okt 21 20:41:21 xxx kdm[3733]: plymouth should quit after server startup
Okt 21 20:41:21 xxx kdm[3733]: Quitting Plymouth with transition
Okt 21 20:41:21 xxx kdm[3733]: Is Plymouth still running? no
Okt 21 20:41:25 xxx kdm[7578]: :0[7578]: Abnormal termination of greeter for display :0, code 1, signal 0
The first and last journal entries for shutdown/poweroff are typically:
Okt 21 20:41:19 xxx polkitd[980]: Unregistered Authentication Agent for unix-session:2 (system bus name :1.39, object path /org/kde/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8)
Okt 21 20:41:19 xxx kdm[3832]: :0[3832]: pam_unix(xdm:session): session closed for user xxx
.
.
.
Okt 21 20:41:57 xxx boot.apparmor[8120]: Unloading AppArmor profiles ..done
Okt 21 20:41:57 xxx auditd[736]: The audit daemon is exiting.
Okt 21 20:41:57 xxx kernel: audit: type=1305 audit(1445452917.870:434): audit_pid=0 old=736 auid=4294967295 ses=4294967295 res=1
Okt 21 20:41:57 xxx kernel: audit: type=1130 audit(1445452917.870:435): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="auditd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:57 xxx kernel: audit: type=1131 audit(1445452917.870:436): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="auditd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:57 xxx kernel: audit: type=1130 audit(1445452917.871:437): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-tmpfiles-setup" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:57 xxx kernel: audit: type=1131 audit(1445452917.871:438): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-tmpfiles-setup" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:57 xxx umount[8154]: umount: /var/run: target is busy
Okt 21 20:41:57 xxx umount[8154]: (In some cases useful info about processes that
Okt 21 20:41:57 xxx umount[8154]: use the device is found by lsof(8) or fuser(1).)
Okt 21 20:41:57 xxx umount[8161]: umount: /var: target is busy
Okt 21 20:41:57 xxx umount[8161]: (In some cases useful info about processes that
Okt 21 20:41:57 xxx umount[8161]: use the device is found by lsof(8) or fuser(1).)
Okt 21 20:41:57 xxx systemd[1]: Failed unmounting /var.
Okt 21 20:41:58 xxx kernel: audit: type=1130 audit(1445452918.235:439): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-remount-fs" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:58 xxx kernel: audit: type=1131 audit(1445452918.235:440): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-remount-fs" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:58 xxx kernel: audit: type=1130 audit(1445452918.236:441): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-readahead-replay" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:58 xxx kernel: audit: type=1131 audit(1445452918.236:442): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-readahead-replay" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:58 xxx kernel: audit: type=1130 audit(1445452918.237:443): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-readahead-collect" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Okt 21 20:41:58 xxx dmeventd[466]: dmeventd shutting down.
Okt 21 20:41:58 xxx rpcbind[682]: rpcbind terminating on signal. Restart with "rpcbind -w"
Okt 21 20:41:58 xxx systemd-journal[455]: Journal stopped
If running plasma and your display manager is sddm, the extended shutdown is likely to happen.
I changed my display manager to lightdm and I had my lengthy restart and shutdown reduced - dramatically!
You might like to try it. Other than that I cannot say.
Cheers,
Hugh
Thanks a lot (also to dcurtisfra)
I’ll try lightdm these days. But it is still a pity that it does not solve the problem, only avoids it.
Saludos
Being a (13.2) KDE fan I’ve noticed that, the lightdm installation pulls a little bit too many gtk things in with it.
I’ll stay with kdm for the moment and wait and see what the Leap 42.1 upgrade brings and, maybe take a closer look at the 13.2 shutdown/poweroff.
Christmas is coming!!
I too have experienced a long shutdown but most are pretty swift.
I changed the display managers in etc/sysconfig - even tried lightdm - but it did not work :disapointed:
I had a long shutdown when I used nfs (network file system). Removed from /etc/fstab and it shutdowns much faster.
I saw this in enlightenment sometimes I can’t even shutdown
I have to login to xfce and shutdown works.
In yast2-security center and hardening-boot settings
The shutdown behavior of login manager is set to
automatic
Changing it to
all users
seemed to solve my problem.
Must admit my shutdowns are a little long now I’ve upgraded to 42.1, plasma5. However I wasn’t sure what caused it as I’ve (improved) my hardware at the same time… Certainly not as long as a minute but noticeably slow. I have a new ssd for root formatted to ext4 and followed the advice on https://lizards.opensuse.org/2015/02/06/ssd-configuration-for-opensuse/
I will try that!
No it made no difference for me.
Please submit a bug report. See: https://bugzilla.opensuse.org/index.cgiOn another note, Plasma 5.5 will be available in December as an update for Tumbleweed.
No solution for here 
Meanwhile I reinstalled Leap with ext4 file System instead of btrfs. Same trouble again.
Luckily I can boot into a faultless Ubuntu partition… Startup AND shutdown take a few seconds only.
I am wondering what takes openSUSE so long
As an update to my own issue, I’m please to report that the latest group of updates today (19/11/15) have resolved it. Nice work devs!!
Yep - those updates also updated grub2
Installed … rebooted … same long waiting period at the login prompt as before…
Hi,
What display manager were you using when you had your problem?
What display manager are you using now?
I switched from sddm to lightdm and that fixed mine.
After the most recent updates I switched back to sddm but the long shutdown remained.
Just a while ago (an hour perhaps) I installed kdm and that also has a wonderful effect on the restart process.
Thanks,
Hugh
No results here so far.
Newest promising solution seems to explicitly shut down the wlan0 network by a systemd shutdown skript.
Waiting for the lan disconnection seems to cause the hanging shutdown in openSUSE.
However systemd skripting is something for which I don’t have enough tinkering time to learn it now 
I’ve had problems on shutdown with 42.1 and 13.2. It took a 90 seconds timeout waiting a zombi process everytime it turned off the machines. The problem was google chrome. It never kills the “Chrome_ProcessL” process when you exit it. Doing a killall -9 Chrome_ProcessL solved my problem. I am thinking about adding a cron task to kill Chrome_ProcessL periodically since it seems to not affect the running session of google chrome.
About start up, it takes about 4 seconds from grub to login screen on a machine with 42.1 and ssd 
That’s really weird. I have the same symptoms. It seems a longstanding serious bug in OS.
When you browse the web, in many cases it’s about the NFS. Then it’s the display manager. Then it’s the wifi. You narrowed it down to chrome (which I haven’t installed).