Allow --confdir to look for system jobs in more than one directory

After discussion on the mailing list I'm -1 on this. I don't think having OEMs and carriers installing Upstart jobs is a good idea. It's an unstable interface and one that we expect to drop long term.

We now have a branch in case this really is needed. It's a small change since Session Inits already support multiple --confdirs.

Note that the whole point of adding the --confdir option originally was to circumvent the standard /etc/init/ directory, specifically for testing. What this means is that with the new branch, if you want Upstart to read jobs from /etc/init/ and /custom/init/ say, you will have to specify *both* directories on the kernel command-line via the bootloader:

  --confdir /etc/init/ --confdir /custom/init/

If custom system jobs need to be supported, the only realistic option atm is to create a sub-directory below /etc/init/ (say /etc/init/custom/). However, that doesn't help here since custom components need to be contained below /custom/.

Note that Upstart does _not_ honour sym links in /etc/init/ by design (rationale being that all jobs required to boot a system should be available in one known location at boot).

______

Note that there *is* a way to do what you want, but it's not really a practical proposition as you'll see: you could create an /etc/init/custom.conf job that runs a Session Init as root:

init --user --confdir /custom

However, there are major caveats to doing this:

1) You would need to join that upstart session to control or query the status of the custom jobs:

    http://upstart.ubuntu.com/cookbook/#joining-a-session

  In other words, start/stop/restart/initctl would not work unless you set UPSTART_SESSION first. This would all work, but could get very confusing.

2) You would need to create an XDG_RUNTIME_DIR for root so that the session init could create a session file to allow an admin to join the session.

3) You would need to specify an alternate log directory for the session init since you would be able to have a system job and a custom job with the same name and they would then overwrite each others log by default:

     --logdir /var/log/upstart/custom/

Discussed with slangasek who brought up a good point: it probably makes sense to introduce a '--append-confdir' or '--add-confdir' since that would:

a) Make it more difficult to make a device unbootable (with only --confdir, if you forget to add '--confdir /etc/init/', your device will likely not boot).

b) Minimise the required kernel command-line changes.

For the migration plan from upstart -> systemd, we intended to run system upstart as pid2, with systemd as pid1.

For that to work, upstart should process and launch all of it's jobs as normal, apart from it should skip/set to manual all jobs that are handled by systemd.

To achieve that we were thinking for system upstart to support multiple --confdirs, and systemd would then start upstart with "/etc/init" and "/lib/systemd/upstart/" directories, with .override files either shipped or generated by systemd setting jobs to manual.

Thus regardless of the OEM requirements, we do need this functionality in upstart soon enough to unblock further work on systemd migration.

In silo 3: http://people.canonical.com/~platform/citrain_dashboard//#?q=landing-003

Upstart 1.13 now provides _three_ options for full flexibility: --confdir=, --append-confdir= and --prepend-confdir=. All options can be specified multiple times. See the MP for details and examples and init(5) for the gory details:

    https://code.launchpad.net/~jamesodhunt/upstart/bug-1315060/+merge/218953