bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <bm...@apache.org>
Subject Re: running init.d scripts by hand vs. service(8)
Date Fri, 07 Sep 2012 08:49:20 GMT
On 09/06/2012 10:31 AM, Sean Mackrory wrote:
> +1 to Alejandro's idea. I like the having the ability to manually override
> environment variables and invoke scripts as a developer. I'd be annoyed if
> I used a service and it refused to start up without service or if it
> ignored my environment in an unnecessarily subtle way. That being said,
> since one of the benefits of using Bigtop is more out-of-the-box
> reliability and simplicity, I also like the idea of strongly encouraging
> users to use 1 supported method of service invocation.
>
> On Thu, Sep 6, 2012 at 9:15 AM, Alejandro Abdelnur <tucu@cloudera.com>wrote:
>
>> The verbosity would be there only when running the scripts outside of
>> service, to avoid YOU tripping again :)
>>
>> On Thu, Sep 6, 2012 at 9:11 AM, Roman Shaposhnik <rvs@apache.org> wrote:
>>> On Thu, Sep 6, 2012 at 8:14 AM, Alejandro Abdelnur <tucu@cloudera.com>
>> wrote:
>>>> I think is a desirable feature to be able to modify ENV then run start
>>>> the daemon directly. It may be handy on troubleshooting.
>>>
>>> As I said -- it is entirely possible we can all agree that this is a
>> feature.
>>>
>>>> I'd propose a modification to Cos' proposal, print a NICE BIG WARN
>>>> when starting the daemons without service(8) stating 'current ENV
>>>> settings may affect the daemon (Roman remember that)'
>>>
>>> I don't think I have a guaranteed way of detecting one vs. the other.
>>> /usr/bin/service happens to be a shell script that at the end of the
>>> day simply scrubs the environment and execs the actual init.d script:
>>>      exec env -i LANG="$LANG" PATH="$PATH" TERM="$TERM"
>>> "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
>>>
>>> Perhaps we can try to detect that we're NOT exec'ed by service via
>>> absence of things like HOME, etc.
>>>
>>> The question then becomes whether this is too much trouble and whether
>>> it'll make our scripts too verbose.
>>>
>>> Thanks,
>>> Roman.
>>
>>
>>
>> --
>> Alejandro
>>
>

These scripts could be called in various ways and I am a little bit 
worried about closing some doors.
What about having a consistent behavior of always scrubbing the 
environment (so the script will always work by default), except when 
some debugging variable/parameter is passed to it.
Hopefully people spend more time using these scripts than debugging them :)

Thanks,
Bruno

Mime
View raw message