Our ops people use the "start-here.sh" scripts to bring services back up
after failures.  That's a great convenience: they don't have to remember
which hosts are supposed to run the which service.

In sympathy with your hostname troubles: the inconsistent use of hostname
determination causes those tservers started with start-all.sh and
start-here.sh to have different hostnames (shortname and fqdn,
respectively). This has something to do with how our DNS is set-up (or
hardcoded) because I cannot reproduce the effect in my development
environment.

As a consequence of this, the quoting hell of ssh, the limitations of
writing code in Bash, I'm avoiding The Scripts as much as possible.  I am
happy you are taking this on.

-Eric

On Thu, Jun 25, 2015 at 1:24 PM, Josh Elser <josh.el...@gmail.com> wrote:

> I've been on a tear within our scripts in the last day. I've been moving
> towards getting an accumulo-daemon.sh with some reasonable start, stop, etc
> semantics (ala Hadoop). This can also be done without affecting the
> existing start-server.sh, start-here.sh, etc scripts.
>
> This hypothetical accumulo-daemon.sh script is a close feel to what an
> init.d script would do. It alters the state of a server process on the
> local node. One thing I'm struggling to wrangle is the current ability the
> scripts/configs provide to control the interface that the server processes
> bind to.
>
> For example, 127.0.0.1 in the `slaves` file will result in a TabletServer
> that processes external to the local node cannot talk to. I know there are
> likely fringe cases (multiple NICs, bonded interface) which I don't fully
> understand to ensure proper support.
>
> Is anyone an expert here and could give some advice about the kinds of
> configuration that the scripts should provide to lets users run Accumulo
> how they want to? I would like to move away from having to pass the
> hostname/IP to scripts locally (e.g. `accumulo-daemon.sh start tserver`
> would start a tserver locally), but I don't want break an existing
> deployment.
>
> - Josh
>

Reply via email to