Native upstart scripts – implemented

[Jacek Konieczny]

Hello,

Your volunteer has done his job :)

I have made the proof-of-concept implementation of native upstart job
control. I did it a bit different way than I initially suggested –
taking into account your comments and improving my own ideas by trial
and errors.

My main requirements were fulfilled:
  - this doesn't break current /etc/rc.d/init.d/* scripts
  - this can coexist with the current /etc/rc.d/init.d/* script based
    job control
  - /etc/init.d/* scripts are quite LSB compatible even when the jobs
    are controlled by upstart.

Currently all the changes are applied to 'upstart_native' branch, so the
solution may be tested before merging into the distribution. As it
doesn't seem to break anything I guess it can be merged very soon (after
the weekend?) unless someone shows me some big problem with the code or
has a good idea on how some things could be done better.

I have modified:

  - rc-scripts 
        to provide facilities needed for upstart-controlled services
  - syslog-ng
        as an example of a generic service implementation other services
        rely on – how to make job depend on a 'syslog' service not 
        a specific 'syslog-ng' implementation
  - openssh-server
        as an example of some system service relying on network and
        syslog
  - postgresql
        as an example of multi-instance service. It also shows how
        to run a service with non-root uid (it is strange upstart
        doesn't provide this function directly)

To play with that build rc-scripts, syslog-ng, openssh and postgresql
from the 'upstart_native' branch, upgrade to these builds (this should
change nothing in how your system works) and then install
syslog-ng-upstart, openssh-upstart and postgresql-upstart.

When the *-upstart packages are installed you can still control the
services with /sbin/service or /etc/rc.d/init.d/$service scripts
or directly with the 'initctl' tool.

The way it is implemented gives two options of booting the PLD system:

1. the traditional – serialized, slow but verbose and colorful way 
       – just do not install the *-upstart packaged or boot with
         'pld.no-upstart'

2. the new event-based, parallelized, auto-respawning way, but less
  verbose
        - instal the *-upstart packages and let them do their job

Some documentation for the rc-scripts+upstart usage is here:

  http://svn.pld-linux.org/cgi-bin/viewsvn/rc-scripts/branches/upstart_native/doc/upstart.txt?rev=11395&view=markup


Patryk Zawadzki <patrys at pld-linux.org> wrote:
> I'd opt for having 2 separate -init subpackages, one with the current
> rc.d contents and one with an upstart job description and a simple
> rc.d wrapper that runs "start $foo", "stop $foo" etc.

-upstart subpackages done. Addin "-init" makes no sense, as current
upstart job handling implementaion relies on the init.d scripts for LSB
compatibility and doing things not doable with bare Upstart
(non-SIGHUP-reloading, 'checkconfig', advanced status monitoring).

Elan Ruusamäe <glen at delfi.ee> wrote:
> i don't like the idea that the links are managed via some script, i'd like
> easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or
> something in /etc/sysconfig/system the both solutions should be available and
> configured at the same time.

Done. No chkconfig patching, no script-managed-links, only a minor
update do /sbin/service added.

The new, upstart event-based boot may be disabled by a kernel command
line option: "pld.no-upstart".

> also i'd not invent new paths, but use /etc/init for upstart scripts.

Done. But this has some consequences:

- The package-provided /etc/init/*.conf files are config files. Expect
  user to modify them in any way. Do not put things, that may change on
  every upgrade, there.
- Package-provided job description could conflict with used locally or
  provided by third-party packages. I suggest using
  /etc/init/local/*.conf for local jobs and keeping /etc/init/*.conf
  files for /etc/rc.d/init.d/* equivalents (put extra jobs needed for
  the functionality into a subdirectory)

Greets,
        Jacek