[
https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043657#comment-14043657
]
Michael Shuler commented on CASSANDRA-2356:
-------------------------------------------
I assigned this to myself to look into the patch for inclusion. I agree that
/etc/default/cassandra ENABLED=0 is a fine and very typical way to prevent
service startup on a fresh install, as well as allowing users to set "1" if
they want the service to restart on boot or upgrade. Allowing users to set
ENABLED=0 prior to package upgrade so they can merge config changes before
starting the service back up seems helpful.
As for adding in the complexity of "if upgrade, then set ENABLED=1" - I'm not
sure how that might be used by other packages that use /etc/default in a new
version - is the error message enough? I sort of think it is sufficient - I
always look to see if the service started up after upgrade, since I'm right
there upgrading the package. Or perhaps should this be added to 2.1.0+ with
some documentation on this feature going forward?
> 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
> 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.2#6252)
