I think is a desirable feature to be able to modify ENV then run start the daemon directly. It may be handy on troubleshooting.
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)' Thx On Wed, Sep 5, 2012 at 5:41 PM, Konstantin Boudnik <c...@apache.org> wrote: > I'd say consistency is the way to go. > > The easiest perhaps is to check if the invocation doesn't caused by the > service(8) command then simply reject to proceed ;) > > Cos > > On Wed, Sep 05, 2012 at 04:51PM, Roman Shaposhnik wrote: >> Hi! >> >> Here's a thorny issue that I'm looking at right now which I'd >> appreciate a broader perspective on: it seems that currently >> there's a subtle (but a very dangerous) difference between >> running any of our init.d scripts by hand -- e.g. >> # /etc/init.d/hadoop-hdfs-datanode start >> vs. running them via a service(8) command -- e.g. >> # service hadoop-hdfs-datanode start >> >> It just so happens that service is guaranteed to clean >> the environment up, but running the scripts directly >> would run them in whatever environment root might >> have currently. >> >> IOW, if for any reason root would set a variable up >> that corresponds to a var from a particular /etc/default/<name> >> sourced by the init.d scripts -- that would affect the script >> execution. >> >> What do you all think -- is this a bug or a feature? Should >> we, somehow, make sure that a direct execution would >> scrub the environment the same way that a service(8) one >> does? >> >> Thanks, >> Roman. >> >> P.S. Now, it might seem to be a trivial matter of cleanliness but >> I've got bitten by it today and spent quite a bit of time debugging >> the "incorrect" behavior only to realize that it was my environment >> to blame. -- Alejandro
