Hi
After upgrading to 13.1 with zypper dup
shutdown never terminates.
After isssuing shutdown command system goes into the plymouth screen.
Toggling ESC goes into console mode where it hangs showing
login> Started Show Plymouth Boot Screen
(or maybe reboot)
Any suggestions…
MN
UPDATE>
Shutdown hangs for for several minutes but it eventually terminates. After the first time it was allowed to terminate,
shutdown now completes promptly without delays.
However, reboot does not complete. The system displays plymouths reboot screen but it does not respond to “escape”
and seems frozen there.
Well it is not always video but it is often :’(
What video do you have and what driver.
That happened to me this morning. I had just run Yast online updates, followed by “zypper up”.
I don’t run plymouth. On shutdown, I got to a text screen showing login, but not actually allowing anything to be typed it.
I then used CTRL-ALT-DEL a few times, with no evident effect.
I tried CTRL-ALT-F2, which got a blank screen. Thne CTRL-ALT-F1 got me back to the screen with the login. And then it finally shutdown (actually rebooted, which is what I had wanted).
I’ve had this happen before. It seems that updating some libraries interferes with “systemd” communication.
I don’t know how to document the problem, so I have not reported as a bug.
Could be https://bugzilla.novell.com/show_bug.cgi?id=841544
Check logs for any systemd errors during shutdown (although I’m not sure whether they will be in syslog; do you have persistent journal?)
In any case - such delay usually means that some service does not stop. I wish we could deactivate “quiet” mode using key combination or something like this.
Yet, it could be. As far as I understand, the situation is as follows:
I have two remote disks mounted via sshfs. If I issue “shutdown” without any preparation, the system hangs for 2 minutes, until
it times out an attempt to unmount the devices. I guess that systemd wants to umount the devices when it is too late, i.e.,
network already down or sshd not running. If I umount the devices by hand before issuing shutdown, everything proceeds smoothly
and the system shuts down in a few seconds. I tested putting the umount command in rcX.d with X=0,5,6 with the name
K01remotes (so that it is done before sshd at any rate) but this does not seem to help. It is at best “erratic”.
However: If I issue reboot, the system hangs for undefinite time, even after manually unmounting the remote disk. The reboot
issue seems to be something unrelated to the above. See the final lines of the journal file:
Jan 12 11:56:15 coihue systemd[1]: Started Show Plymouth Reboot Screen.
Jan 12 11:56:15 coihue systemd[1]: Starting Reboot…
Jan 12 11:56:15 coihue systemd[1]: Shutting down.
Jan 12 11:56:15 coihue systemd[1]: Hardware watchdog ‘INTCAMT’, version 0
Jan 12 11:56:15 coihue systemd[1]: Set hardware watchdog to 10min.
Jan 12 11:56:15 coihue systemd-journal[302]: Journal stopped
[here I waited 12 minutes and forced poweroff]
Should I file one (or two) bug(s) ? How and where?
Thanks,
MNatiello
https://bugzilla.novell.com/show_bug.cgi?id=857031
It is says “NFS mount” but the real problem is, there is missing dependency between services that need network and network service itself.
However: If I issue reboot, the system hangs for undefinite time, even after manually unmounting the remote disk. The reboot
issue seems to be something unrelated to the above.
a) enable persistent journal (mkdir /var/log/journal)
b) reboot, verify that this directory has content
c) activate debugging for systemd (/usr/bin/kill -RTMIN+22 1)
d) reboot. Wait for 5 minutes before pressing power button 
e) after reboot fetch logs from previous boot ("journalctl -b -1) and upload to susepaste or pastebin.
So it seems. But the delay in shutdown and the hang in reboot still seem to be unrelated things. I can cope with the delay by
stopping the services by hand before power down. However, the reboot hangs independently of this delay.
e) after reboot fetch logs from previous boot ("journalctl -b -1) and upload to susepaste or pastebin.
Here is the pasted log. I waited 8 minutes before pressing the button, but clearly nothing happens after “Journal Stopped”.
http://paste.opensuse.org/56301468
Hope this helps.
MNatiello
Could you provide /proc/self/mountinfo? It looks like you have some mount that will not die.
1. Jan 12 12:54:57 coihue umount[2621]: umount: /home: target is busy.
1. Jan 12 12:54:57 coihue umount[2621]: (In some cases useful info about processes that use
1. Jan 12 12:54:57 coihue umount[2621]: the device is found by lsof(8) or fuser(1))
1.
Here is the pasted log. I waited 8 minutes
It will reset itself after 10 minutes
1. Jan 12 12:54:57 coihue systemd[1]: Set hardware watchdog to 10min.
Interesting.
I did not make notes. I’m pretty sure that the last time that I had this problem was with my NFS server, rather than any client. And there were no clients running. But NFS doesn’t always know that.
A perhaps related issue. An NFS client is setup to use “autofs”, so that mounts should be done only as demanded. But my home NFS mount seems to be already mounted shortly after boot anyway.
Perhaps I should forcibly unmount before shutdown, and see if it still mounts on boot the next time.
This is not the problem. If you see the timestamps, the system gets through this problem within the second.
It will reset itself after 10 minutes
- Jan 12 12:54:57 coihue systemd[1]: Set hardware watchdog to 10min.
I don’t think so. In the first try (reported above) I waited 12 minutes, induced by that line, but nothing happened.
One more data point:
I experienced the same symptoms after installing 13.1: it hangs very long (hours) between shutdown and actual power off.
I had a hard NFS mount and when I set NFS mount options to noauto and I don’t mount it manually, then shutdown and power off works as expected. That begs the question whether NFS umount hangs in shutdown.
Any idea how to debug that?
I had more or less the same experience. Shutdown delayed for several minutes. My network connection is controlled by ifup and i have a connection with a nfs share that is specified in fstab. What I saw was that the network connection went down before disconnecting from the nfs server. And that of course gives timeouts or hangs. Now, the network connection is managed by network@.service and network@.service is a part of network.service. The nfs connection is a remote file system and mounted just before reaching remote-fs.target. the network.service has a before dependency of network.target. This should ensure that the network is up before mounting remote file systems and vice-versa on shutdown. Apparently being a part of another service, as with network@.service and network.service, does not mean that the former obeys the befores or afters of the latter. On start-up this obviously did not matter but on shutdown it certainly did. So I gave network@.service the same befores and afters as network.service and now all is well https://forums.opensuse.org/images/icons/icon12.png.
