cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2356) make the debian package never start by default
Date Thu, 07 Jun 2012 11:21:24 GMT


Eric Evans commented on CASSANDRA-2356:

1) node A has token X
2) node A dies and the OS crashes
3) node A is replaced by node B, also at token X (say by restoring a full snapshot)
4) node A is rebooted (say as part of RMA process)
5) cluster accepts node A as the rightful owner of token X, because it has a later generation
number by virtue of having been more recently started
6) you have a two nodes which contain the same but desychronized dataset, at the same token,
and no straightforward way to unify them

The best way to deal with a situation like this is to make Cassandra do the Right Thing. 
Barring that, you could hack the init script to check for this condition and make startup
a noop (or error), which would work even if someone had overridden the start policy.

For what it's worth, I remember running across code recently that I think would safeguard
against this; Is this a failure scenario that you've tested against recent versions?

bq. Are there any circumstances where auto-starting, esp. on packaged install or upgrade,
is actually desirable?

This is considered configuration, and with any configuration all you can do is provide a reasonable
default, something that will work for most of the people, most of the time.  Starting a service
by default is generally considered The Way[*] on Debian systems, (and hence the least surprising
choice for our Debian package).

[*] The oft stated reason being that if the user didn't want the service running, they wouldn't
have installed it.
> make the debian package never start by default
> ----------------------------------------------
>                 Key: CASSANDRA-2356
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Packaging
>            Reporter: Jeremy Hanna
>            Priority: Minor
>              Labels: debian, packaging
>         Attachments: 2356.txt
> Currently the debian package that installs cassandra starts cassandra by default.  It
sounds like that is a standard debian packaging convention.  However, if you want to bootstrap
a new node and want to configure it before it creates any sort of state information, it's
a pain.  I would think that the common use case would be to have it install all of the init
scripts and such but *not* have it start up by default.  That way an admin can configure cassandra
with seed, token, host, etc. information and then start it.  That makes it easier to programmatically
do this as well - have chef/puppet install cassandra, do some configuration, then do the service
> With the current setup, it sounds like cassandra creates state on startup that has to
be cleaned before a new configuration can take effect.  So the process of installing turns
> * install debian package
> * shutdown cassandra
> * clean out state (data/log dirs)
> * configure cassandra
> * start cassandra
> That seems suboptimal for the default case, especially when trying to automate new nodes
being bootstrapped.
> Another case might be when a downed node comes back up and starts by default and tries
to claim a token that has already been claimed by another newly bootstrapped node.  Rob is
more familiar with that case so I'll let him explain it in the comments.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message