Various 0.5.0-related questions

[Adam Sampson]

Hi,

I've just upgraded my GARstow desktop machine from Upstart 0.3.9, which
was working nicely, to 0.5.0, which also appears to work happily. I've
been really impressed with Upstart in general. I apologise, therefore,
for the pile of questions I'm about to ask...

- * -

I ran into a problem during the upgrade: owing to the new "oom"
feature, Upstart now requires /proc to be mounted before init starts,
which won't be the case if (like me) you don't use an initrd. I've
kludged around it for now by adding system("mount /proc"); to init's
main(), but it'd be nice to have a proper workaround -- for example,
mounting /proc on startup if it's not already mounted.

- * -

While tracking that down, I spotted the following suspicious-looking bit
of code in crash_handler():

  /* Dump in the root directory */
  nih_warn ("%s: %s", _("Unable to set root directory"),
  	  strerror (errno));

Shouldn't that do a chdir("/") and only print the warning if it fails,
like the similar code in main()? At the moment, it'll print that warning
whenever crash_handler is called.

- * -

One of the services I manage with Upstart is automount (from
autofs-4), which doesn't have a "don't run as a daemon" mode.
With 0.3.9, I used the following nasty hack:

  service
  pre-start script
    start-stop-daemon -S -x /opt/sbin/automount -- /5g file /etc/auto.5g
  end script
  post-stop script
    start-stop-daemon -K -x /opt/sbin/automount
  end script

... which works for starting and stopping, but can't detect when the
daemon's died. The same trick works in 0.5.0 without the "service", but
this is what the new "expect" mode is meant to deal with; however, using
either "expect fork" or "expect daemon" results in:

  Aug 16 21:57:51 cartman init: automount main process (15347) killed by
  TRAP signal

This doesn't appear to be a problem with automount, since you can run
anything in the job (e.g. "exec echo hello") and get the same error. Any
ideas? This is with glibc 2.7 and Linux 2.6.25.8-rt7, in case that makes
a difference; I can investigate further if you'd like.

- * -

A final question: I can use "instance" to write a generic getty job and
run several instances of it, but what's the preferred way to start the
instances? Should I have a "gettys" task that starts the gettys I want
explicitly, or did you have something in mind that'd figure it out
automatically?

I suppose I could have udev emit events as the devices are registered,
but that seems suboptimal: it'd make login prompts appear very early in
the boot process, and I don't want gettys running on all my ttys...

- * -

Thanks very much -- and apologies again for the flood of questions!

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>