init rc main process stopped and continued in loop on system reboot/shutdown

Bug #401333 reported by Michal Matyska on 2009-07-19
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
upstart (Ubuntu)
Medium
Scott James Remnant (Canonical)

Bug Description

I'm running Karmic and had some troubles with splash screen and framebuffer setting, so I removed the splash screen (well usually I suspend/resume the laptop, so why to care about splash ;-). This has revealed one unexpected behavior when I do updates which require system restart. On the console I can see messages:

init: rc main process stopped by STOP signal
init: rc main process continued by CONT signal

in loop for 10 or 11 times with one second delay after these two lines were shown. After that, the system is finally rebooted, but discs were not cleanly unmounted and on the start there are following messages:

[ 1.806707] EXT3-fs: INFO: recovery required on readonly filesystem.
[ 1.806709] EXT3-fs: write access will be enabled during recovery.
[ 5.979290] kjournald starting. Commit interval 5 seconds
[ 5.979307] EXT3-fs: sda1: orphan cleanup on readonly fs
[ 6.048412] ext3_orphan_cleanup: deleting unreferenced inode 5178383
[ 6.066797] EXT3-fs: sda1: 1 orphan inode deleted
[ 6.066799] EXT3-fs: recovery complete.
[ 6.084156] EXT3-fs: mounted filesystem with writeback data mode.

upstart: 0.6.1-1

Michal Matyska (michal-matyska) wrote :

Today I did another reboot and noticed that the issue has disappeared.
Might be fixed by upstart: 0.6.2-1

Michal Matyska (michal-matyska) wrote :

Not reproducible any more.

Changed in ubuntu:
status: New → Invalid
Marco Rodrigues (gothicx) wrote :

I still have this problem.. and the after shutdown it asks me to run 'fsck'. Really strange.

Changed in ubuntu:
status: Invalid → Fix Released
affects: ubuntu → upstart (Ubuntu)
Changed in upstart (Ubuntu):
status: Fix Released → Confirmed
Marco Rodrigues (gothicx) wrote :

Maybe it could be a kernel problem. Bug 418560

Michal Matyska (michal-matyska) wrote :

I moved this bug to Invalid because it has been resolved with some update before even confirmed and I was too lazy to find which update was it.

You can easilly distinguish between these two bugs... if you wait long enough (30 seconds) and your computer does not restart/shutdown then you are affected by #418509 (which was resolved by kernel 2.6.31-8).

You can also check the console output... start Ubuntu with nosplash option (edit once grub boot option) and when you invoke shutdown switch to console output (it is Alt+F7 on my desktop) and check the output.

This is perfectly normal. init is simply reporting that something is stopping and continuing its rc process; the thing that's doing that is killall5 being run from rc as part of the process of killing all system processes.

Changed in upstart (Ubuntu):
status: Confirmed → Won't Fix
Martin Emrich (emme) wrote :

I have this problem since two days (Linux 2.6.31-10, upstart 0.6.3-3). After ca. 10 of these STOP/CONT cycles the system finally reboots/shuts down. Two times, I was even dropped to an emergency shell after starting the system later and had to fsck my filesystem. One is karmic amd64, the other karmic i386.

Changed in upstart (Ubuntu):
status: Won't Fix → New
oli z (oliver-z) wrote :

same here
i always get this after reboot instead of the nice screen and this looks somehow ill

also i had to fsck my partitions just as martin emrich wrote

On Thu, 2009-09-17 at 07:23 +0000, Martin Emrich wrote:

> ** Changed in: upstart (Ubuntu)
> Status: Won't Fix => New
>
Please don't revert this status.

Scott
--
Scott James Remnant
<email address hidden>

Changed in upstart (Ubuntu):
status: New → Won't Fix
Kaaahn! (cnetrix) wrote :

I'm getting the same bug... is it normal that Karmic is taking a long time to shut down? It feels like it takes three times as long as Jaunty shutting down. Without the splash screen I see these two lines:

"init: rc main process stopped by STOP signal
init: rc main process continued by CONT signal"

repeating 8 times down my screen before it finally shuts down.

On Thu, 2009-09-17 at 19:02 +0000, Kaaahn! wrote:

> I'm getting the same bug... is it normal that Karmic is taking a long
> time to shut down? It feels like it takes three times as long as Jaunty
> shutting down.
>
No, but these messages are not relevant to that.

Scott
--
Scott James Remnant
<email address hidden>

I've just realised that these messages appear at all because the log priority is low enough that they appear, booting with "--quiet" on the kernel command-line is enough to hide them. But we use "quiet" not "--quiet", Upstart should respect that

Changed in upstart (Ubuntu):
status: Won't Fix → Fix Committed
importance: Undecided → Medium
assignee: nobody → Scott James Remnant (scott)
milestone: none → ubuntu-9.10-beta
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package upstart - 0.6.3-4

---------------
upstart (0.6.3-4) karmic; urgency=low

  [ Scott James Remnant ]
  * Reduce the priority of the stopped by/continued by messages so that
    they are only shown when --verbose on the kernel command-line.
    LP: #401333.
  * Add a hack to look for /dev/.initramfs/*.pid files on startup and
    "fake" start jobs of those names. Basically this means that "status"
    and "stop" work for things like bootchart and usplash.
  * Implement a "reload" command in initctl that retrieves the current pid
    of the job and sends it the HUP signal. LP: #433544.

  [ Steve Langasek ]
  * debian/upstart-job:
    - give proper policy-compliant behavior of the start command: detect if
      the job is already running using upstart status, and if so return success.
    - same for the stop command: return success if the job is already stopped.
    - when $DPKG_MAINTSCRIPT_PACKAGE is set, don't spit warnings out because
      it's not the user's fault - we're being invoked by a maintainer script.

 -- Scott James Remnant <email address hidden> Tue, 22 Sep 2009 13:56:48 -0700

Changed in upstart (Ubuntu):
status: Fix Committed → Fix Released
ilna (a-gaydenko) wrote :

I have similar problem with filesystems recovering at every booting up, and have a filed a bug 434224

That issue isn't resolved with last upstart and Ko updates which, as supposed, fix this one.

Huh... do you really think, that the change not to show the message did solve that bug?

There is some process not reacting on int/term signals which prevents clean unmount of file system and thus forcing fsck to be run on the next system start.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers