Toby,
It seems to me like it would be nice if Riak just worked when you
installed it, instead of requiring each and every user to have to track
something down in the docs and then configure it in their chef/puppet
manifests. Don't you agree that is a desirable feature of good software?
(ie.
As an opposing viewpoint, I'd argue that it's NOT the requirement of Riak
to go automatically changing things outside of its domain. Ulimits and
tunables in the same class are not things that should be blindly tweaked by
an incoming package. These are things the system administrator needs to be
Slightly related, we just recently updated file descriptor limit
support in the Riak cookbook [0]. As of right now, ulimits
automatically get increased (4096 by default) for the `riak` and
`riak-cs` users based on what cookbook you use.
Perhaps we should make that increase conditional?
--
Hector
For the cookbook, I think that's fine. It's not the actually package itself
doing the change. In fact, I expect that the cookbook and puppet modules
(or ansible playbooks...whatever) probably should do that. I'm making
a conscious decision to use those to manage the configuration. I think
that's
I think with Chef Cookbooks it is reasonable. Most people look at what the
cookbook is doing before using it. This is different from packages where
people usually don't rip apart a .deb with dpkg-deb before installing it.
-Jared
On Thu, May 16, 2013 at 8:28 AM, Hector Castro
I'm confused -- I'm still seeing some warnings from Riak/RiakCS about
the ulimit being set too low, even though I *am* increasing it.
What am I doing wrong here?
# cat /etc/default/riak-cs
ulimit -n 32000
# ulimit -n 8192
# service riak-cs start
WARNING: ulimit -n is 1024; 4096 is
If you check ulimit through Erlang [1], are you seeing the appropriate
ulimit values?
[1]:
http://riak.markmail.org/search/?q=ulimit#query:ulimit+page:2+mid:bqjbmn3yyh5hdvcb+state:results
---
Jeremiah Peschka - Founder, Brent Ozar Unlimited
MCITP: SQL Server 2008, MVP
Cloudera Certified
On 16/05/13 13:31, Jeremiah Peschka wrote:
If you check ulimit through Erlang [1], are you seeing the appropriate
ulimit values?
The /proc/$PID/limits method reports max open files=1024
I've only noticed this recently on some Debian Squeeze nodes I've
commissioned.. I just checked my Ubuntu
Just wondering the same thing.
$ sudo su riakcs
$ ulimit -n
16384
$ sudo service riak-cs restart
WARNING: ulimit -n is 1024; 4096 is the recommended minimum.
I experience this issue only with Riak CS, not Riak itself.
Richard
On May 15, 2013, at 8:34 PM, Toby Corkindale
I added some debugging to the /etc/init.d/riak-cs script.
As far as it's concerned the ulimit has been successfully increased in
there, right before it calls start-stop-daemon.
Is it possible that part of the Debian infrastructure is dropping
privileges?
On 16/05/13 12:34, Toby Corkindale
Well the riak-cs / riak / stanchion scripts all drop privileges using sudo.
On RHEL/Centos this sudo exec carries the settings from the calling user
(in the case of init.d, root) so things are fine there. On Ubuntu/Debian
that does not always work. So if you set the ulimit for the root user, it
On 16/05/13 14:39, Toby Corkindale wrote:
On 16/05/13 14:24, Jared Morrow wrote:
Well the riak-cs / riak / stanchion scripts all drop privileges using
sudo. On RHEL/Centos this sudo exec carries the settings from the
calling user (in the case of init.d, root) so things are fine there. On
I've considered packaging separate files for configuring the limit for people,
but the user in me always felt like that was something the sysadmin should have
a say in. I rather dislike packages that make system changes without my
knowledge or consent. Maybe that is just me?
I do agree that
On 16/05/13 15:38, Jared Morrow wrote:
I've considered packaging separate files for configuring the limit
for people, but the user in me always felt like that was something
the sysadmin should have a say in. I rather dislike packages that
make system changes without my knowledge or consent.
14 matches
Mail list logo
