bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <>
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 <>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 <> wrote:
>>> On Thu, Sep 6, 2012 at 8:14 AM, Alejandro Abdelnur <>
>> 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"
>>> 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 :)


View raw message