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

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

Not reproducible any more.

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

Maybe it could be a kernel problem. Bug 418560

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.

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.

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>

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

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

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.