export variable inheritance question

[Garrett Cooper]

On Fri, Oct 2, 2009 at 4:14 PM, Scott James Remnant <scott at netsplit.com> wrote:
> On Fri, 2009-10-02 at 15:41 -0700, Garrett Cooper wrote:
>
>> We recently ran into a slightly unexpected side-effect where we
>> exported a variable in a jobfile, like so:
>>
>> # job1
>> env VAR=1
>> export VAR
>>
>> # job2
>> start on job1
>>
>>     And $VAR was visible from job2 with the value set in job1 (in this
>> case $VAR => 1). Is that intended behavior?
>>
> That's what export does.  It places the value of the named environment
> variables into the event environment.
>
> What were you using it for? :)

    Well, here's the thing...

"export VAL=1" is a variable available in the environment, and it's
accessible via the shell, but only for the current job.
"export VAL
env VAL=1" is a variable available in the environment, and it's
accessible via the shell for all child dependent jobs.

    One of the developers for the group I worked with implemented a
variable in our jobfile so if VAR=1 was defined in any of the jobfiles
and one of those jobs was stopped, it would effectively tear down the
system using upstart instead of using a dbus-daemon tie-in which would
listen for events from services and monitor system health (what should
be done in the longterm IMO).
    What I'm trying to determine is whether or not it's possible to
find a better way outside of initctl where it wouldn't inherit
environment variables in jobfiles, because this seems like
functionality that's not correct, but it's not wrong due to there not
being specific requirements for it to act one specific way (maybe this
is a side-effect of the fact that the export stanza doesn't have any
documentation that I've found).
Thanks for the feedback as always :).
-Garrett