12.2 to 12.3 upgrade - shutdown issue

5 PCs (different hardware configurations) were upgraded from 12.2 to 12.3 and they all seem to exhibit the following intermittent issue.
Some times, when clicking “Turn Off Computer” or “Restart Computer” the Gecko screen doesn’t come up and the user is looking at a console login request, until the system actually shuts down.
At times this seem to take much longer than a few seconds (1-2 minutes) and the user tries to comply and attempts to log in (or believes the computer is frozen).
The same systems had no issues shutting down when running 12.2.

Any suggestion?

Configuration:
OS: Linux 3.7.10-1.1-desktop x86_64
System: openSUSE 12.3 (x86_64)
KDE: 4.10.1 “release 545”

Thank you and Best regards

PS1.
FYI, these are the steps used to upgrade from 12.2 to 12.3:

  • Performed BACKUP!
  • Tried the upgrade from DVD, media checked OK but it locked up during repositories update so I removed the DVD and continued as shown below.
  • Performed all software upgrades available for 12.2, including 3rd party like VMware, VirtualBox, etc.
  • In YaST/Software Repositiories edited all repositories for 12.2 to point to 12.3 (removed old ones that don’t exist anymore for 12.3).
  • Performed “Refresh all Autorefreshed”.
  • Logout and Console Login as root
  • #init 3 (worked without this too, just trying to be safe).
  • #zypper dup
  • after confirmation prompt and a couple of release notes to accept, it starts downloading.
  • the 5 PCs needed each between 1 and 3GB of downloads.
  • the download and install took 1.5 to 2.5 hrs on each PC (20MB/sec internet not a bottleneck).
  • the process worked unattended for the most part - one download error solved by retry and one post upgrade message from one package.
  • the system then returns to # prompt
  • tried #reboot and ‘#shutdown -h now’ but in all 5 cases the shutdown doesn’t complete, however all system files seem stopped and there is no activity (could just cycle consoles)
  • used reset button to restart (don’t like it at all but couldn’t find any other way).
  • booted successful every time and followed-up with various tweaks.

PS2.
Tweaks and notes, post upgrade.

  • MyComputer (konqueror sysinfo:/) was replaced by KInfoCenter (I’m still trying to find other ways to do what MyComputer did - like copy and paste my OS configuration).
  • The new KDE themes may require some widgets resizing due to slightly modified aspect/size.
  • On some systems the Desktop Effects Advanced settings had changed - had to change to get some effects back.
  • Some systems kept original theme, others switched to the new 12.3 one - reverted back in KDE settings.
  • One system had VMplayer complaining about “missing C headers for current kernel” but updating to latest VMplayer solved the issue.
  • No network problems observed, regardless of using network manager or not.
  • All browsers and mail apps seem to work fine (kmail & Claws). Skype seems to work too on all systems.
  • All multimedia programs seem to work. MythTV (0.25-3) still works after upgrade, no attention needed.
  • No problem observed with Wine or PlayOnLinux applications.
  • The Nvidia drivers seem to have updated correctly.
  • I didn’t need to, but some programs compiled from source may need to be recompiled.

I followed the same upgrade procedure as you on one of my pc and actually have seen this same behavior. I am just going to wait and see if it settles out over the next couple of update cycles. If I still see the same issue a month or so from now then I will file a bug report.
You could probably do a search of openSUSE bugzilla and see if someone already file something.

This is a consequence of the continuing march of systemd to trample on the venerable init. It depends on how much of *syvinit *you haave on the old system. It is the last thing I have to solve before being able to roll-out a remote upgrade of our 11.4(Evergreen) desktops. The upgrade removes the init components used to change the, now non-existent run-levels, by shutdown, halt etc.

So far on the dozen test systems I have stopped all the daemons that I thought might write to the hdds (cron, cups ntp,etc.), performed a sync, disconnected (ssh), and left a telephone message for the local operator not to panic but to power the machine off and on. The hardest part is tactfully getting them to restart the computer, and not just turn the monitor off and on.

lol!lol! It is hard to find good help.

After my upgrade from 12.2.to 12.3 i noticed that KDE was using opensuses theme rather than my own. So i thought hmm ive seen this before and went to Action policy editor from Systems Settings.

In the field provided type reboot or shutdown (if both of broken then procedure here needs to be down twice). Expand policy folders and select “Reboot/Shutdown the system” -

Choose Add from right bottom of this app and give it an appropriate Title like “Users allowed to Reboot/Shutdown” and select add from this dialogue box. Select your username that you are signed into and OK it. Apply changes if necessary. Open K menu and select reboot/shutdown and there you are.

The easiest way to do this would be to reload/apply the Actions/Policy - i dont know how to do this but this will obviously be better than doing the above.

This looks promising and may solve my other openSUSE Firewall problem as well but I had problem implementing your instructions. I was able to find the right settings ( I think) by typing “policy” into the kmenu and selecting “Actions Policy” and then I typed shutdown into the open field ( I guess it is a seach field, IMHO it is lacking an indicator) and the names below dropped out until only one was left and then I had to expand it with clicking on the little arrow (this all seems so ms windows centric it gave me a chill) and finally I end up with the window as seen below.

http://paste.opensuse.org/view/download/60966019

This does not seem like the right setting??
I have expanded all the settings and still can not find a proper way to change this behavior. If you have time can you please explain what should be done in more detail?
Thanks

Perhaps polkit needs reloading -
I should have mentioned that if you click on any of the policies that an authorization box pops up. Type in your root password and menus on your right will be highlighted. To reenable shutdown flick the switch. What I mean here is select any drop down menu and select an alternate answer and then change it back to original answer

Do this simply to allow you the option of applying the policy again .

Click on the apply button and see if shutdown box appears. It should do.

The polkit/systemd framework is quite powerful - its similiar to sudo but with more oomph. Im still trying to figure if theres a reset button somewhere for it.

Let me know how you get on

Thanks for the info. I’m afraid I can’t find

Expand policy folders and select “Reboot/Shutdown the system”
either.

Also, I’m not sure I was clear enough in my first post, this is not a problem of the system not shutting down, it just takes much too long and there is no graphic or progress screen covering the console login screen but eventually it does shut down (100% of the cases).
Is the solution you proposed meant to enable shutdown for an user that can’t shutdown the system or to actually make the shutdown process consistent? Only second part would help the original issue.

Regards

Hi, I think I could picture how the situation you describe could happen. Actually, some of my systems were previously upgraded from 11.4 or 12.1 to 12.2 too (so none is a straightforward clean 12.2 to 12.3 upgrade).

Unfortunately, I’m not sure I understand completely your workaround, so I have a few follow-up questions, if I may.
Q1. Is this sequence (stopped daemons/sync/power cycle) needed one time only after upgrade and it cures the future shutdown “hiccups” or when problem happens (and how to recognize when needed if the system shuts down anyways)?
Q2. Can this become a script or some additional commands to run at shutdown (so we can modify system scripts or edit the command line under System Settings/Login Screen)?

Thanks

Additional info - it happened with the graphic screen too! The Plymouth shutdown screen showed, it faded out, then it sat there for a minute or so before turning off.
This also kinda sucks - the black screen may give the user the impression it is safe to unplug the power cord or switch the power center off.

Unrelated to this, I found on all systems, all the menu fonts were missing in acroread and flash (small blocks instead); fixed as described here:
https://forums.opensuse.org/english/get-technical-help-here/tumbleweed/482399-little-boxes-instead-letters-acrobat-reader-plymouth-2.html#post2537450

On second thought:
Q3 - Are you in fact referring to not being able to reboot the system after upgrade (and not to the shutdown inconsistency on the upgraded system)?

Thanks

Since the issue manifests itself quite often, I’m trying to do some troubleshooting but I can’t seem to find any logs for the shutdown sequence.
I found some posts stating that /var/log/messages contains the info but I could only see one or two lines vaguely related to shutdown in there, not the whole sequence.
I found some other openSUSE instructions that state the boot log - /var/log/boot.msg and for shutdown /var/log/boot.omsg. The boot.msg file is there and does contain boot information. However, there is no boot.omsg file to be found.

Does anyone have any suggestion on how to enable logging for shutdown?

Thanks

On 2013-03-19 21:16, nkent001 wrote:

> Does anyone have any suggestion on how to enable logging for shutdown?

All boot and halt logging goes to “/var/log/messages”, and nothing goes
anymore to “/var/log/boot.msg”, the file is deprecated with systemd.

During halt sequence the messages have to stop when the syslog service
stops, obviously. And a bit later the disk is umounted. The traditional
method to debug these messages is using a real serial port (no, usb is
not valid for this). And I don’t know if it will work now with systemd.

There is also a systemd journal somewhere if it is activated. Don’t ask
me about it, me dunno.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

I see (it looks like boot.msg still functions on my system but that is irrelevant).
For now I will pay closer attention to /var/log/messages and see if I can come up with anything.

Thank you

I’ll have to test some more but I might’ve stumbled upon something.
Since this started to look more and more like systemd problem, I decided to search for ‘systemd hangs shutdown’. This comes up with a bunch of hits, and one is a suggestion to replace halt with poweroff.
I decided to give it a try and in ‘Configure Desktop / System Administration / Login Screen / Shutdown / Halt’ I replaced

/sbin/shutdown -h -P now

with

/sbin/poweroff

I had tried about 15 times and each time the shutdown only took about 10 seconds.
I need to keep an eye on this for a while and see if I just got lucky or this actually helped.

Thank you all for the info and suggestions so far.

Wow great job :slight_smile: I will try this out on my other machine that shows the symptoms.

thanks for this, I had this issue on a laptop (not on any of the desktops), works perfect

for reboot I changed

/sbin/shutdown -r now

to

/sbin/reboot

have tried a dozen times now and worked every singe time

When I was testing stuff, I also tried /sbin/reboot once and ended up staring at the login prompt for 5 minutes before decided to log in and typing poweroff.
Since I wasn’t concerned with the reboot (most users need to shut down) I disregarded it and kept original ‘shutdown -r now’.

Nevertheless, I just tried again now for a few times and reboot seems to work fine too. I figure, I must’ve been doing something else wrong the first time I tried.

Thanks

Thanks, please let us know how it went.

I am having a very similar issue after upgrading from OpenSUSE 12.2 to 12.3. That is, when I try to shut my laptop down using the GUI shutdown icons then it takes a VERY LONG time to shutdown. I would say an extra 60 to 90 seconds. Whereas, if I shutdown from the command line using “shutdown now” (or reboot with “shutdown -r now”) then it happens quickly as it did in OpenSUSE 12.2

I hope someone comes up with a fix soon!