[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723192#comment-13723192 ]
Ishaaq Chandy edited comment on CASSANDRA-2356 at 7/30/13 12:29 AM: -------------------------------------------------------------------- I agree that it's detrimental to allow the package to restart cassandra on upgrades - when, more often than not, on a version upgrade there is quite often some critical post-install configuration work that needs to be done before we can safely restart cassandra. The default mechanism of restarting cassandra is quite dangerous in these instances. FWIW: we use http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt to explicitly control this, so the package cannot restart cassandra during upgrades, normal restarts (during reboots for e.g.) continue to work as advertised (this is intended not as a fix for this issue but as a work-around for other operators that find themselves vexed by this). was (Author: ishaaq): I agree that it's detrimental to allow the package to restart cassandra on upgrades - when, more often than not, on a version upgrade there is quite often some critical post-install configuration work that needs to be done before we can safely restart cassandra. The default mechanism of restarting cassandra is quite dangerous in these instances. FWIW: we use http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt to explicitly control this, so the package cannot restart cassandra during upgrades, normal restarts (during reboots for e.g.) continue to work as advertised. > 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 > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira