accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Newton <>
Subject Re: Start scripts and address/hostname
Date Fri, 26 Jun 2015 17:48:22 GMT
Our ops people use the "" 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 and 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

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.


On Thu, Jun 25, 2015 at 1:24 PM, Josh Elser <> wrote:

> I've been on a tear within our scripts in the last day. I've been moving
> towards getting an with some reasonable start, stop, etc
> semantics (ala Hadoop). This can also be done without affecting the
> existing,, etc scripts.
> This hypothetical 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, 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. ` start tserver`
> would start a tserver locally), but I don't want break an existing
> deployment.
> - Josh

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message