[jira] [Updated] (CASSANDRA-12432) Set ulimit for nproc in debian init script

2016-08-10 Thread Jared Biel (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Biel updated CASSANDRA-12432:
---
Description: 
While using Cassandra 2.2.7 (installed from official package) on Ubuntu 14.04 I 
noticed a warning on startup:

{noformat}
WARN  [main] 2016-08-10 21:53:53,219 SigarLibrary.java:174 - Cassandra server 
running in degraded mode. Is swap disabled? : true,  Address space adequate? : 
true,  nofile limit adequate? : true, nproc limit adequate? : false
{noformat}

I set about researching how that value is set and how to increase it. I found 
the [Datastax documentation on recommended 
settings|http://docs.datastax.com/en/landing_page/doc/landing_page/recommendedSettingsLinux.html]
 and tried to increase the nproc limits according to that doc to no avail. I 
eventually found a [stackoverflow 
post|http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daemon]
 that states that start-stop-daemon (which the C* init script uses) 
doesn't/can't use the values specified in the limits.conf files.

I solved this by adding a {{ulimit -p 32768}} entry to the init script below 
the other two ulimit commands. Note that the flag is "-p" for dash (default 
/bin/sh on Ubuntu), but the flag is "-u" on bash. As Debian has had [dash as 
default|https://wiki.debian.org/Shell] since squeeze (2011-02-06), this should 
be safe on most Debian based distros.

  was:
While using Cassandra 2.2.7 (installed from official package) on Ubuntu 14.04 I 
noticed a warning on startup:

{noformat}
WARN  [main] 2016-08-10 21:53:53,219 SigarLibrary.java:174 - Cassandra server 
running in degraded mode. Is swap disabled? : true,  Address space adequate? : 
true,  nofile limit adequate? : true, nproc limit adequate? : false
{noformat}

I set about researching how that value is set and how to increase it. I found 
the [Datastax documentation on recommended 
settings|http://docs.datastax.com/en/landing_page/doc/landing_page/recommendedSettingsLinux.html]
 and tried to increase the nproc limits according to that doc to no avail. I 
eventually found a [stackoverflow 
post|http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daemon]
 that states that start-stop-daemon (which the C* init script uses) 
doesn't/can't use the values specified in the limits.conf files.

I solved this by adding a {{ulimit -p 32768}} entry to the init script below 
the other two ulimit commands. Note the the flag is "-p" for dash (default 
/bin/sh on Ubuntu), but the flag is "-u" on bash. As Debian has had [dash as 
default|https://wiki.debian.org/Shell] since squeeze (2011-02-06), this should 
be safe on most Debian based distros.


> Set ulimit for nproc in debian init script
> --
>
> Key: CASSANDRA-12432
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12432
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jared Biel
>Priority: Minor
>
> While using Cassandra 2.2.7 (installed from official package) on Ubuntu 14.04 
> I noticed a warning on startup:
> {noformat}
> WARN  [main] 2016-08-10 21:53:53,219 SigarLibrary.java:174 - Cassandra server 
> running in degraded mode. Is swap disabled? : true,  Address space adequate? 
> : true,  nofile limit adequate? : true, nproc limit adequate? : false
> {noformat}
> I set about researching how that value is set and how to increase it. I found 
> the [Datastax documentation on recommended 
> settings|http://docs.datastax.com/en/landing_page/doc/landing_page/recommendedSettingsLinux.html]
>  and tried to increase the nproc limits according to that doc to no avail. I 
> eventually found a [stackoverflow 
> post|http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daemon]
>  that states that start-stop-daemon (which the C* init script uses) 
> doesn't/can't use the values specified in the limits.conf files.
> I solved this by adding a {{ulimit -p 32768}} entry to the init script below 
> the other two ulimit commands. Note that the flag is "-p" for dash (default 
> /bin/sh on Ubuntu), but the flag is "-u" on bash. As Debian has had [dash as 
> default|https://wiki.debian.org/Shell] since squeeze (2011-02-06), this 
> should be safe on most Debian based distros.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12432) Set ulimit for nproc in debian init script

2016-08-10 Thread Jared Biel (JIRA) 
Jared Biel created CASSANDRA-12432:
--

 Summary: Set ulimit for nproc in debian init script
 Key: CASSANDRA-12432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12432
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jared Biel
Priority: Minor


While using Cassandra 2.2.7 (installed from official package) on Ubuntu 14.04 I 
noticed a warning on startup:

{noformat}
WARN  [main] 2016-08-10 21:53:53,219 SigarLibrary.java:174 - Cassandra server 
running in degraded mode. Is swap disabled? : true,  Address space adequate? : 
true,  nofile limit adequate? : true, nproc limit adequate? : false
{noformat}

I set about researching how that value is set and how to increase it. I found 
the [Datastax documentation on recommended 
settings|http://docs.datastax.com/en/landing_page/doc/landing_page/recommendedSettingsLinux.html]
 and tried to increase the nproc limits according to that doc to no avail. I 
eventually found a [stackoverflow 
post|http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daemon]
 that states that start-stop-daemon (which the C* init script uses) 
doesn't/can't use the values specified in the limits.conf files.

I solved this by adding a {{ulimit -p 32768}} entry to the init script below 
the other two ulimit commands. Note the the flag is "-p" for dash (default 
/bin/sh on Ubuntu), but the flag is "-u" on bash. As Debian has had [dash as 
default|https://wiki.debian.org/Shell] since squeeze (2011-02-06), this should 
be safe on most Debian based distros.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7941) Fix bin/cassandra cassandra.logdir option in debian package

2014-09-17 Thread Jared Biel (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14137654#comment-14137654
 ] 

Jared Biel commented on CASSANDRA-7941:
---

It would be great to get a -2 package version with this fix.

> Fix bin/cassandra cassandra.logdir option in debian package
> ---
>
> Key: CASSANDRA-7941
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7941
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Shuler
> Fix For: 2.1.1
>
> Attachments: 
> 0001-Fix-bin-cassandra-cassandra.logdir-option-in-debian-.patch
>
>
> Cassandra writes logs to $CASSANDRA_HOME/logs by default, and the debian 
> package needs to write to /var/log/cassandra.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-5212) Unable to start when using Ec2Snitch

2013-01-31 Thread Jared Biel (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568250#comment-13568250
 ] 

Jared Biel commented on CASSANDRA-5212:
---

Thanks - I didn't see that needle in the (hay) stack. It looks like as a result 
of CASSANDRA-5155 the file cassandra-rackdc.properties is now required to be in 
/etc/cassandra. However, this file is not distributed with the standard Debian 
Cassandra package. Maybe this should be documented in cassandra.yaml or the 
file should be distributed as part of the Debian package? Thanks for your help.

> Unable to start when using Ec2Snitch
> 
>
> Key: CASSANDRA-5212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5212
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.1
> Environment: Ubuntu 12.04 x64
> OpenJDK 64-Bit Server VM/1.6.0_24
> m1.large EC2 Instance
> MAX_HEAP_SIZE="1242M"
> HEAP_NEWSIZE="200M"
>Reporter: Jared Biel
>Priority: Minor
>
> Hello, we're using vanilla Cassandra in an EC2 environment and I just tested 
> upgrading from 1.2.0 to 1.2.1 on two test instances. Cassandra fails to start 
> because it's unable to load the Ec2Snitch. Version 1.2.0 was working OK. I 
> have tried this on uninitialized/empty instances and received the same 
> result. Cassandra successfully starts when switching to SimpleSnitch. Log 
> output is below. We're using the official debian package from apache.org. 
> Please let me know if you need any more details, thanks!
> output.log
> {code}
> ERROR 21:25:06,684 Fatal configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Error instantiating 
> snitch class 'org.apache.cassandra.locator.Ec2Snitch'.
>   at 
> org.apache.cassandra.utils.FBUtilities.construct(FBUtilities.java:475)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:525)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:338)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:122)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:151)
>   at 
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:315)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:616)
>   at 
> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
>   at 
> org.apache.cassandra.utils.FBUtilities.construct(FBUtilities.java:457)
>   ... 10 more
> Caused by: java.lang.ExceptionInInitializerError
>   at org.apache.cassandra.locator.Ec2Snitch.(Ec2Snitch.java:65)
>   ... 15 more
> Caused by: java.lang.RuntimeException: Unable to read 
> cassandra-rackdc.properties
>   at 
> org.apache.cassandra.locator.SnitchProperties.(SnitchProperties.java:39)
>   ... 16 more
> Caused by: java.lang.NullPointerException
>   at java.util.Properties$LineReader.readLine(Properties.java:435)
>   at java.util.Properties.load0(Properties.java:354)
>   at java.util.Properties.load(Properties.java:342)
>   at 
> org.apache.cassandra.locator.SnitchProperties.(SnitchProperties.java:35)
>   ... 16 more
> Error instantiating snitch class 'org.apache.cassandra.locator.Ec2Snitch'.
> Fatal configuration error; unable to start server.  See log for stacktrace.
> Service exit with a return value of 1
> {code}
> system.log
> {code}
> INFO [main] 2013-01-31 21:25:05,016 CassandraDaemon.java (line 123) JVM 
> vendor/version: OpenJDK 64-Bit Server VM/1.6.0_24
> 
> ERROR [main] 2013-01-31 21:24:52,028 DatabaseDescriptor.java (line 509) Fatal 
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Error instantiating 
> snitch class 'org.apache.cassandra.locator.Ec2Snitch'.
>   at 
> org.apache.cassandra.utils.FBUtilities.construct(FBUtilities.java:475)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:525)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescri

[jira] [Created] (CASSANDRA-5212) Unable to start when using Ec2Snitch

2013-01-31 Thread Jared Biel (JIRA) 
Jared Biel created CASSANDRA-5212:
-

 Summary: Unable to start when using Ec2Snitch
 Key: CASSANDRA-5212
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5212
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.1
 Environment: Ubuntu 12.04 x64
OpenJDK 64-Bit Server VM/1.6.0_24
m1.large EC2 Instance

MAX_HEAP_SIZE="1242M"
HEAP_NEWSIZE="200M"

Reporter: Jared Biel
Priority: Minor


Hello, we're using vanilla Cassandra in an EC2 environment and I just tested 
upgrading from 1.2.0 to 1.2.1 on two test instances. Cassandra fails to start 
because it's unable to load the Ec2Snitch. Version 1.2.0 was working OK. I have 
tried this on uninitialized/empty instances and received the same result. 
Cassandra successfully starts when switching to SimpleSnitch. Log output is 
below. We're using the official debian package from apache.org. Please let me 
know if you need any more details, thanks!

output.log
{code}
ERROR 21:25:06,684 Fatal configuration error
org.apache.cassandra.exceptions.ConfigurationException: Error instantiating 
snitch class 'org.apache.cassandra.locator.Ec2Snitch'.
at 
org.apache.cassandra.utils.FBUtilities.construct(FBUtilities.java:475)
at 
org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:525)
at 
org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:338)
at 
org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:122)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:151)
at 
org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:315)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at 
org.apache.cassandra.utils.FBUtilities.construct(FBUtilities.java:457)
... 10 more
Caused by: java.lang.ExceptionInInitializerError
at org.apache.cassandra.locator.Ec2Snitch.(Ec2Snitch.java:65)
... 15 more
Caused by: java.lang.RuntimeException: Unable to read 
cassandra-rackdc.properties
at 
org.apache.cassandra.locator.SnitchProperties.(SnitchProperties.java:39)
... 16 more
Caused by: java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Properties.java:435)
at java.util.Properties.load0(Properties.java:354)
at java.util.Properties.load(Properties.java:342)
at 
org.apache.cassandra.locator.SnitchProperties.(SnitchProperties.java:35)
... 16 more
Error instantiating snitch class 'org.apache.cassandra.locator.Ec2Snitch'.
Fatal configuration error; unable to start server.  See log for stacktrace.
Service exit with a return value of 1
{code}

system.log
{code}
INFO [main] 2013-01-31 21:25:05,016 CassandraDaemon.java (line 123) JVM 
vendor/version: OpenJDK 64-Bit Server VM/1.6.0_24

ERROR [main] 2013-01-31 21:24:52,028 DatabaseDescriptor.java (line 509) Fatal 
configuration error
org.apache.cassandra.exceptions.ConfigurationException: Error instantiating 
snitch class 'org.apache.cassandra.locator.Ec2Snitch'.
at 
org.apache.cassandra.utils.FBUtilities.construct(FBUtilities.java:475)
at 
org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:525)
at 
org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:338)
at 
org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:122)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:151)
at 
org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:315)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:212)
Caused by: java.lang.reflect.InvocationTarg