Opened 9 years ago

Closed 7 years ago

Last modified 20 months ago

#7531 closed defect (fixed)

shutdown sometimes appears to hang - need ctl-alt-F2 for it to complete

Reported by: mikus Owned by: martin.langhoff
Priority: high Milestone:
Component: initramfs Version: Development build as of this date
Keywords: relnote blocks-:8.2.0 cjbfor9.1.0 ml8.2.3 Cc: mikus@…, dsd, cjb, joe, martin.langhoff
Blocked By: Blocking:
Deployments affected: Action Needed: reproduce
Verified: no


Booted my G1G1 (Joyride 2169 equiv., Q2D16) just long enough to use Terminal to copy a file. Issued 'shutdown -r now' command. The Sugar session ended [screen went to console text output left over from when Sugar was being started] -- then the XO just sat there.

After 15 minutes, I pressed ctl-alt-F2. Now the screen showed the ending picture (containing icons warning what not to do with the OLPC). After a normal-duration wait the XO shut down (and restarted, as I had asked for).

[I have on random occasions seen this same (shutdown seems to "hang") behavior with earlier Fedora9-based Joyrides, including when I used the Home View palette to initiate shutdown.]

Attachments (1)

chvt_retry.patch (1.3 KB) - added by martin.langhoff 7 years ago.
act-gui: chvt_retry.patch

Download all attachments as: .zip

Change History (24)

comment:1 follow-up: Changed 9 years ago by tomeu

Maybe we are suspending during the shutdown sequence?

comment:2 in reply to: ↑ 1 Changed 9 years ago by mikus

Replying to tomeu:

Maybe we are suspending during the shutdown sequence?

My personal interpretation of 'suspend' is that it is supposed to slow-blink the "power" light. Did not see the "power" light blinking. [Pressing ctl-alt-F3 while shutdown was "hung" didn't "wake up" the system.]

Besides, how come the ending picture was now shown on ctl-alt-F2, instead of on ctl-alt-F3 (where the Sugar GUI screen had been shown). I do not think that 'suspend' would cause switching between "consoles".

comment:3 Changed 9 years ago by kimquirk

  • Keywords relnote added

If it shuts down properly from the home screen, this is not a blocker. It might be good for release notes.

comment:4 Changed 9 years ago by dsd

  • Cc dsd added
  • Keywords blocks?:8.2.0 added

I have seen it happen when shutting down from the home screen.

comment:5 Changed 9 years ago by mstone

  • Action Needed changed from never set to diagnose
  • Cc cjb added
  • Keywords blocks-:8.2.0 added; blocks?:8.2.0 removed
  • Milestone changed from 8.2.0 (was Update.2) to 8.2.1
  • Priority changed from normal to high

This is nasty but is a lot less nasty than many other things. Not a blocker, worth release-noting, and I'd probably accept a fix if one turned up. Please fix blockers first.

Note: I believe that upstart will refuse to shut down unless all its services shutdown when it asks. If so, this may be easy to fix.

comment:6 Changed 9 years ago by dsd

This smells a bit like a bug I solved at a previous internship. Is chvt involved in the shutdown sequence?

chvt can hang indefinitely due to a race with the kernel, X, or even another chvt. I worked around this by moving some of the logic into userspace for that company's software release. See

comment:7 Changed 9 years ago by thomaswamm

I saw something like this while testing build 8.2-757. I requested Shutdown from Home view, but it got stuck with a white-text-on-black-background console screen. I was impatient, so just held down Power button. But my notebook tells me this also happened while I was testing joyride-2301. I don't know how to reproduce it. My cryptic scribbles from 2301 say "Shutdown fails waiting for X-server to shut down. xinit unexpected signal 15. Pwr button reveals info."

comment:8 follow-up: Changed 8 years ago by thomaswamm

  • Action Needed changed from diagnose to reproduce
  • Version changed from not specified to Development build as of this date

Hang on shutdown has happened in 8.2-767. See also #7812.

Need a reliable way to reproduce this bug to facilitate diagnosis.

comment:9 in reply to: ↑ 8 Changed 8 years ago by mikus

Replying to thomaswamm:

Need a reliable way to reproduce this bug to facilitate diagnosis.

I'm not sure everyone means the same thing when they say "hang on shutdown bug". I do not know of any reliable way to reproduce shutdown halting before showing the final screen (the one with the "don't do this" and "caution" images), such that ctl-alt-F2 needs to be pressed to allow shutdown to display that screen and complete. But since this halting situation occurs for me on about 2 out of 3 shutdowns, I consider this bug "reproducible", even if the way to do so is not reliable.

comment:10 Changed 8 years ago by joe

  • Cc joe added

comment:11 Changed 8 years ago by mstone-xmlrpc

  • Keywords cjbfor9.1.0 added
  • Milestone changed from 8.2.1 to 9.1.0

Pushing out to 9.1.0, per edmcnierney's request.

comment:12 Changed 8 years ago by mikus

  • Resolution set to wontfix
  • Status changed from new to closed

This ticket is getting long in the tooth -- I'll close it, on the presumption that the 8.2 release will *not* be fixed for this situation.

I am not seeing this problem on the 0.83 Joyrides - their shutdown process appears to not need manual intervention.

comment:13 Changed 8 years ago by dsd

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I saw it, and I still believe it to be a chvt race condition.

comment:14 Changed 8 years ago by mikus

So far on 'staging-7', I have not seen shutdown appear to hang. It just sits there for a long time showing an uninteresting text-tty screen, but eventually the power does go off.

comment:15 Changed 8 years ago by mikus

On 'staging-8', I have so far had to press ctl-alt-F2 every time, for shutdown to complete.

comment:16 Changed 8 years ago by skierpage

Note the Support FAQ has a section for this which recommends pressing Ctrl+Alt+F4 (the Group View key). F2/F4??

Still happens for me with candidate-800 (a candidate for 8.2.1.)

comment:17 Changed 8 years ago by skierpage

I restarted again using the menu on the XO guy in home view, but this time I first stopped all activities first and had no virtual terminals (consoles) running.

I still briefly saw the xinit unexpected signal 15 message, but this was followed by additional text output and then the XO warnings screen, and my XO-1 restarted cleanly. So that warning message alone doesn't mean shutdown will hang.

comment:18 Changed 7 years ago by martin.langhoff

  • Cc martin.langhoff added
  • Keywords ml8.2.3 added

Changed 7 years ago by martin.langhoff

act-gui: chvt_retry.patch

comment:19 Changed 7 years ago by martin.langhoff

  • Owner set to martin.langhoff
  • Status changed from reopened to new

act-gui implements its own chvt. Implemented the moral equivalent of dsd's patch in it -- seems to work.

Testing reboots on a build with this patch and the fix for #9289.

The same pychvt.pyx is present in the dracut-modules-olpc, so this patch may be interesting there too.

comment:20 Changed 7 years ago by martin.langhoff

  • Milestone changed from 9.1.0-cancelled to 8.2.2
  • Resolution set to fixed
  • Status changed from new to closed

comment:21 Changed 7 years ago by martin.langhoff

  • Component changed from not assigned to initramfs

comment:22 Changed 7 years ago by dsd

Somewhat irrlevant now, but FWIW, this wasn't the right fix (explaining why it still happened in #9943). This bug is related to shutdown, but the initramfs only runs during early boot (and the code in question above only runs on those boots where we have to activate the XO).

The fix for this is in ul-warning in the olpc-bootanim package, which runs in the shutdown path. Fixed for 10.1.2.

comment:23 Changed 20 months ago by Quozl

  • Milestone 8.2.2 deleted

Milestone 8.2.2 deleted

Note: See TracTickets for help on using tickets.