[jira] [Commented] (CASSANDRA-14500) Debian package to include systemd file and conf
[ https://issues.apache.org/jira/browse/CASSANDRA-14500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380171#comment-17380171 ] Brandon Williams commented on CASSANDRA-14500: -- The comments about increasing the limits are spot on, they are far too low in the patch as-is. Regarding autostarting on install, this has been a long argument with polarized sides for some time, so in my opinion it's a matter of preference and this way was chosen to match other packaged services at the time, because installing and _not_ starting is something that also bites new users. I believe where it was last left was that we could make it configurable with debconf or something like that, but we'd still have to pick a default. > Debian package to include systemd file and conf > --- > > Key: CASSANDRA-14500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14500 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Lerh Chuan Low >Assignee: Lerh Chuan Low >Priority: Low > > I've been testing Cassandra on trunk on Debian stretch, and have been > creating my own systemd service files for Cassandra. My Cassandra clusters > would sometimes die due to too many open files. > As it turns out after some digging, this is because systemd ignores > */etc/security/limits.conf.* It relies on a configuration file in > .d/.conf. There's more information here: > [https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html]. > So, for example, for */etc/systemd/system/cassandra.service*, the ulimits are > read from */etc/systemd/system/cassandra.service.d/cassandra.conf*. > Crosschecking with the limits of my Cassandra process, it looks like the > */etc/security/limits.conf* really were not respected. If I make the change > above, then it works as expected. */etc/security/limits.conf* is shipped in > Cassandra's debian package. > Given that there are far more distributions using Systemd (Ubuntu is now as > well), I was wondering if it's worth the effort to change Cassandra's debian > packaging to use systemd (or at least, include systemd service). I'm not > totally familiar with whether it's common or normal to include a service file > in packaging so happy to be corrected/cancelled depending on what people > think. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14500) Debian package to include systemd file and conf
[ https://issues.apache.org/jira/browse/CASSANDRA-14500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380164#comment-17380164 ] Ekaterina Dimitrova commented on CASSANDRA-14500: - CC [~mck] and [~brandon.williams] if you have any comments > Debian package to include systemd file and conf > --- > > Key: CASSANDRA-14500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14500 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Lerh Chuan Low >Assignee: Lerh Chuan Low >Priority: Low > > I've been testing Cassandra on trunk on Debian stretch, and have been > creating my own systemd service files for Cassandra. My Cassandra clusters > would sometimes die due to too many open files. > As it turns out after some digging, this is because systemd ignores > */etc/security/limits.conf.* It relies on a configuration file in > .d/.conf. There's more information here: > [https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html]. > So, for example, for */etc/systemd/system/cassandra.service*, the ulimits are > read from */etc/systemd/system/cassandra.service.d/cassandra.conf*. > Crosschecking with the limits of my Cassandra process, it looks like the > */etc/security/limits.conf* really were not respected. If I make the change > above, then it works as expected. */etc/security/limits.conf* is shipped in > Cassandra's debian package. > Given that there are far more distributions using Systemd (Ubuntu is now as > well), I was wondering if it's worth the effort to change Cassandra's debian > packaging to use systemd (or at least, include systemd service). I'm not > totally familiar with whether it's common or normal to include a service file > in packaging so happy to be corrected/cancelled depending on what people > think. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14500) Debian package to include systemd file and conf
[ https://issues.apache.org/jira/browse/CASSANDRA-14500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670724#comment-16670724 ] Joseph Lynch commented on CASSANDRA-14500: -- I left a few comments on [05c112e7|https://github.com/juiceblender/cassandra/commit/05c112e77e2888d3c19ec36cc40c7c6872fd42ce]. I think this is a great idea as most places I've seen roll their own systemd files and it's somewhat silly that folks are rolling their own. [~mshuler] can you share some context on why Cassandra autostarts on install? I think that it's a fairly sharp edge that hits new users a lot (especially when they go to upgrade the database, push the new package to puppet and cause a production outage)? > Debian package to include systemd file and conf > --- > > Key: CASSANDRA-14500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14500 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Lerh Chuan Low >Assignee: Lerh Chuan Low >Priority: Minor > > I've been testing Cassandra on trunk on Debian stretch, and have been > creating my own systemd service files for Cassandra. My Cassandra clusters > would sometimes die due to too many open files. > As it turns out after some digging, this is because systemd ignores > */etc/security/limits.conf.* It relies on a configuration file in > .d/.conf. There's more information here: > [https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html]. > So, for example, for */etc/systemd/system/cassandra.service*, the ulimits are > read from */etc/systemd/system/cassandra.service.d/cassandra.conf*. > Crosschecking with the limits of my Cassandra process, it looks like the > */etc/security/limits.conf* really were not respected. If I make the change > above, then it works as expected. */etc/security/limits.conf* is shipped in > Cassandra's debian package. > Given that there are far more distributions using Systemd (Ubuntu is now as > well), I was wondering if it's worth the effort to change Cassandra's debian > packaging to use systemd (or at least, include systemd service). I'm not > totally familiar with whether it's common or normal to include a service file > in packaging so happy to be corrected/cancelled depending on what people > think. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14500) Debian package to include systemd file and conf
[
https://issues.apache.org/jira/browse/CASSANDRA-14500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16502729#comment-16502729
]
Lerh Chuan Low commented on CASSANDRA-14500:
Here is a branch that currently has what I am trying to do:
[https://github.com/juiceblender/cassandra/tree/debian-systemd.] I tested it on
my instance - it seems to work and my Cassandra starts up fine. Though I'll
admit I'm not good at Debian packaging and had just learned it before trying to
implement this change.
{code:java}
admin@ip-10-0-6-20:~/cassandra$ systemctl status cassandra.service
● cassandra.service - Apache Cassandra
Loaded: loaded (/lib/systemd/system/cassandra.service; enabled; vendor preset:
enabled)
Drop-In: /lib/systemd/system/cassandra.service.d
└─cassandra.conf
Active: active (running) since Wed 2018-06-06 00:40:18 UTC; 12s ago
Main PID: 7173 (java)
CGroup: /system.slice/cassandra.service
└─7173 java -Xloggc:/var/log/cassandra/gc.log -ea -da:net.openhft...
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42
-XX:+HeapDumpOnOutOfMemoryError -Xss256k -XX:StringTableSize=103
-XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:+Us
Jun 06 00:40:26 ip-10-0-6-20 cassandra[7173]: INFO [main] 2018-06-06
00:40:26,715 MigrationManager.java:238 - Create new table: system_auth.roles
Jun 06 00:40:26 ip-10-0-6-20 cassandra[7173]: INFO [main] 2018-06-06
00:40:26,831 MigrationManager.java:238 - Create new table:
system_auth.role_members
Jun 06 00:40:26 ip-10-0-6-20 cassandra[7173]: INFO [main] 2018-06-06
00:40:26,932 MigrationManager.java:238 - Create new table:
system_auth.role_permissions
Jun 06 00:40:27 ip-10-0-6-20 cassandra[7173]: INFO [main] 2018-06-06
00:40:27,039 MigrationManager.java:238 - Create new table:
system_auth.resource_role_permissons_index
Jun 06 00:40:27 ip-10-0-6-20 cassandra[7173]: INFO [ScheduledTasks:1]
2018-06-06 00:40:27,084 TokenMetadata.java:489 - Updating topology for all
endpoints that have changed
Jun 06 00:40:27 ip-10-0-6-20 cassandra[7173]: INFO [main] 2018-06-06
00:40:27,146 MigrationManager.java:238 - Create new table:
system_auth.network_permissions
Jun 06 00:40:27 ip-10-0-6-20 cassandra[7173]: INFO [MigrationStage:1]
2018-06-06 00:40:27,241 Keyspace.java:369 - Creating replication strategy
system_auth params KeyspaceParams{durable_writes=true,
replication=ReplicationParams{class=org.apache.cass
Jun 06 00:40:27 ip-10-0-6-20 cassandra[7173]: INFO [MigrationStage:1]
2018-06-06 00:40:27,247 ColumnFamilyStore.java:402 - Initializing
system_auth.network_permissions
Jun 06 00:40:27 ip-10-0-6-20 cassandra[7173]: INFO [MigrationStage:1]
2018-06-06 00:40:27,250 ViewManager.java:131 - Not submitting build tasks for
views in keyspace system_auth as storage service is not initialized
Jun 06 00:40:27 ip-10-0-6-20 cassandra[7173]: INFO [main] 2018-06-06
00:40:27,261 Gossiper.java:1802 - Waiting for gossip to settle...{code}
The actual commit is here:
[https://github.com/juiceblender/cassandra/commit/54a16b83ec553dd4000907409046129abf50616b
|https://github.com/juiceblender/cassandra/commit/05c112e77e2888d3c19ec36cc40c7c6872fd42ce]
I've not removed the original init scripts because I wasn't sure if it was a
good idea - maybe some of the users are running really old distributions? If
people think this is a good idea, I'll cleanup some of the other things as
well.
> Debian package to include systemd file and conf
> ---
>
> Key: CASSANDRA-14500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14500
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Lerh Chuan Low
>Assignee: Lerh Chuan Low
>Priority: Minor
>
> I've been testing Cassandra on trunk on Debian stretch, and have been
> creating my own systemd service files for Cassandra. My Cassandra clusters
> would sometimes die due to too many open files.
> As it turns out after some digging, this is because systemd ignores
> */etc/security/limits.conf.* It relies on a configuration file in
> .d/.conf. There's more information here:
> [https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html].
> So, for example, for */etc/systemd/system/cassandra.service*, the ulimits are
> read from */etc/systemd/system/cassandra.service.d/cassandra.conf*.
> Crosschecking with the limits of my Cassandra process, it looks like the
> */etc/security/limits.conf* really were not respected. If I make the change
> above, then it works as expected. */etc/security/limits.conf* is shipped in
> Cassandra's debian package.
> Given that there are far more distributions using Systemd (Ubuntu is now as
> well), I was wondering if it's worth the effort to change Cassandra's debian
> packaging to use systemd (or at least, include systemd service). I'm not
> totally familiar
