[
https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191067#comment-14191067
]
Al Tobey commented on CASSANDRA-2356:
-------------------------------------
Just about every operations / devops person I know dislikes the Debian policy
for auto-starting and would rather services do not start on install. It is
compounded for us because a fresh install will get system tables initialized
with a cluster name that is likely not useful, so not only do users have to
stop the process, they also have to clean up the system tables.
BTW we don't have to add anything to /etc/default/cassandra to work around
this. You can simply "echo 'exit 0' >> /etc/default/cassandra" and it will do
the same thing as long as shell-based init scripts are in play.
My preference is for disabling auto-start completely.
> make the debian package never start by default
> ----------------------------------------------
>
> Key: CASSANDRA-2356
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2356
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
> Reporter: Jeremy Hanna
> Assignee: Michael Shuler
> Priority: Minor
> Labels: debian, packaging
> Fix For: 3.0
>
> 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 start.
> 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 into:
> * 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 was sent by Atlassian JIRA
(v6.3.4#6332)
