[Merge] lp:~jamesodhunt/upstart/setenv+getenv into lp:upstart

[James Hunt]

The proposal to merge lp:~jamesodhunt/upstart/setenv+getenv into lp:upstart has been updated.

Description changed to:

= Summary =

Implementation of the following new initctl commands:

- list-env
- get-env
- set-env
- unset-env
- reset-env

= Thoughts =

== 'list-env' output ordering ==

As a convenience, the list returned by 'list-env' is currently sorted in a locale-aware fashion in initctl. This emulates set(P) but not env(1).

I'm in two minds about whether this is necessary or desirable.

== Bulk-setting of variables ==

The 'set-env' command only accepts a single variable currently, but it may be beneficial to change the D-Bus interface to accept an array of strings to allow arbitrary numbers of variables to be set. This would avoid lots of D-Bus round trips if >1 variable needs to be set. That said, maybe we don't want to encourage such behaviour ;-)

== Security ==

There are no enforced limits on numbers of variables set or the size of any name=value pair. for Session Inits, that's not a concern, but for PID 1 it could well be. As a minimum, we should probably add a '--no-env-table-changes' startup option to disable set-env and unset-env.

== IPC ==

These new commands provide a new form of IPC for jobs: since the job environment table is shared, it is possible to use it to allow, for example, a pre-start process to communicate with a main process:

----------------------------------------

pre-start script
    initctl set-env pre_start_message='hello world'
end script

script
    echo "pre-start said '$pre_start_message'"
end script

----------------------------------------

I suspect this facility will be too useful for job writers to ignore.

However, there is a catch: every variable set using 'set-env' is global so if lots of jobs used this facility, they'd start to bloat the table. And all sorts of interesting scenarios might occur when JobY is suddenly affected by changes made by jobX.

To overcome this problem, I think it would be a good idea to change the behaviour slightly:

- If any of the new env commands is called *from within a job*, they would act on *that job instances environment* only.

  The beauty of this being that once the instance ends, any changes made by any job process are cleaned up automatically without polluting the global job environment table.

- If any of the new env commands is called normally (not from within a job), they would apply to the job environment table.

- If the job writer wishes to really have the variable applied to all future jobs, they could specify a new flag.

  Something like:

    initctl set-env --global foo=bar

For more details, see:
https://code.launchpad.net/~jamesodhunt/upstart/setenv+getenv/+merge/142939
-- 
https://code.launchpad.net/~jamesodhunt/upstart/setenv+getenv/+merge/142939
Your team Upstart Reviewers is requested to review the proposed merge of lp:~jamesodhunt/upstart/setenv+getenv into lp:upstart.