init: cannot be run as a PID other than 1

Reported by Jeff Waugh on 2007-11-05
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
upstart
Wishlist
Unassigned

Bug Description

sysvinit supports --init to make it operate as if it's pid 1 even if it's not pid 1. Upstart not only doesn't support this functionality, but it dies if it receives parameters that it doesn't understand.

My use case: The OLPC has a special process that does a bunch of boot and security stuff before kicking off /sbin/init. With sysvinit and --init, this works fine. If Upstart is installed, it errors out with: "init: invalid option: --init"

Thus, if using an Ubuntu image on an OLPC, you must replace Upstart with sysvinit, which has an impact on various levels of Ubuntu integration work. :-)

There are quite a few other use cases, from the clever to the crack-addled, so it would be nice to fix this for Upstart.

Thanks!

Confirmed; I hadn't seen this in the sysvinit code.

Though this won't fix your problem, since the only resonable implementation in Upstart is to error with "not pid #1"

Why isn't OLPC running init as pid 1?

Changed in upstart:
status: New → Confirmed
Jeff Waugh (jdub) wrote :

The OLPC has a special process that does a bunch of boot and security stuff before kicking off /sbin/init, called oatc.

Right, but if that's pid #1, it should exec /sbin/init and thus give that pid #1, no?

On Nov 12, 2007 4:17 PM, Scott James Remnant <email address hidden> wrote:
> Right, but if that's pid #1, it should exec /sbin/init and thus give
> that pid #1, no?

Nup, oatc runs all the time.

In that case, Upstart cannot work on the OLPC since it must be pid #1 (it's an init daemon).

There is perhaps some small argument for allowing Upstart to run as another pid, but that would necessate disabling features such as supervision of forking daemons, control-alt-delete and alt-uparrow handling, SIGPWR handling, etc.

Since this is a significant functionality reduction, it makes more sense as a compile-time option that a command-line one.

On Nov 12, 2007 5:32 PM, Scott James Remnant <email address hidden> wrote:
> In that case, Upstart cannot work on the OLPC since it must be pid #1
> (it's an init daemon).

sysvinit works okay -- does it suffer reduced functionality when not
running as pid #1?

It doesn't offer the functionality that Upstart does.

That's a bit like asking why GNOME requires a graphics card when getty doesn't ;-)

Changed in upstart:
importance: Undecided → Wishlist
Bryan Quigley (bryanquigley) wrote :

Has this been fixed? I'm currently using a Fedora 10 based XO Joyride build and it uses upstart (and it works).

It's been patched in Fedora/OLPC-3: http://cvs.fedoraproject.org/viewvc/rpms/upstart/OLPC-3/upstart-olpc-init.patch?revision=1.1

I did not check if the patch makes sense to be included in Ubuntu.

With the move to using netlink, this becomes possible

summary: - upstart cannot be run as a PID other than 1
+ init: cannot be run as a PID other than 1
Changed in upstart:
status: Confirmed → Triaged
Bryan Quigley (bryanquigley) wrote :

Is this now fixed with the addition of Session Jobs?

James Hunt (jamesodhunt) wrote :

@Bryan: no - when Upstart runs as a Session Init ("init --user"), it is not running as the system init. OLPC should either have oatc fork itself then exec /sbin/init as PID 1 (I see no requirement on this bug that oatc should run as PID 1?), or consider creating a PID namespace such that oatc runs in the main namespace and Upstart can run as PID 1 in the created namespace.

Bryan Quigley (bryanquigley) wrote :

@James oh ok.

The original need is gone because OLPC is based on Fedora and they have switched to systemd. Not sure if there is another use case for this feature.

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

Other bug subscribers