Question about lifetime of environment variables in job files

[Garrett Cooper]

On Sat, Nov 1, 2008 at 9:48 AM, Scott James Remnant <scott at netsplit.com> wrote:
> On Thu, 2008-10-30 at 20:16 -0700, Garrett Cooper wrote:
>
>> Just doing some more testing and while I understand while this would
>> most likely not work, I'm still wondering if it's documented or not:
>>
> Assuming that you mean that the environment of the child scripts doesn't
> affect the job, that's a simple fact of UNIX - though I'm actually
> investigating interesting ways of making it possible ;)
>
> The idea would be that when the pre-start script exits, we pick up the
> environment table and add that back to the job -- this may require some
> changes to the way init gets child signals or something though.

Well, what would most likely have to happen is memory would have to be
shared for both the *start and *stop scripts, such that . As Matthias
already pointed out though (and it makes perfect sense) POSIX behavior
won't allow *env() to work in this way, and I would think that the
required work would have to be done at the sh level by hacking around
with how exports and IPC are done (and I don't think that we want to
go down to that level just for a "cool" feature), or maybe getenv'ing
the variable after the script is complete and relaying it back via
upstart's shared space would be helpful enough...

> [pre-stop]
>> The more strange issue is that the echo in pre-stop isn't executed --
>> is there a known issue with console output and pre-stop / post-stop?
>>
> pre-stop is only executed on a stop request, ie. if you issue:
>
>        # stop env_test
>        # POST MESS: 0
>
> If your job stops naturally, it is not run, since its primary purpose is
> to issue a stop command to the running process or make a decision to
> ignore the stop command.
>
> Scott

Right. I realized that the job was naturally finishing by itself
instead of me finishing its life cycle.