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 <t...@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 <r...@apache.org> wrote:
On Thu, Sep 6, 2012 at 8:14 AM, Alejandro Abdelnur <t...@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
