Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Changing nofile attribute is not idempotent #101

Closed
kamaradclimber opened this issue Jun 25, 2013 · 2 comments
Closed

Changing nofile attribute is not idempotent #101

kamaradclimber opened this issue Jun 25, 2013 · 2 comments

Comments

@kamaradclimber
Copy link

Changing the nofile attribute leads to duplicate line in /etc/security/limits.conf such as:

elasticsearch     -    nofile    1024
elasticsearch     -    memlock   512
elasticsearch     -    nofile    20000
elasticsearch     -    memlock   512
@karmi
Copy link
Contributor

karmi commented Jun 25, 2013

Strange, should be covered by this not_if: https://github.com/elasticsearch/cookbook-elasticsearch/blob/master/recipes/default.rb#L105-L111

@karmi
Copy link
Contributor

karmi commented Jun 25, 2013

@kamaradclimber Actually not strange at all -- the not_if block works only with the updated values. The code would have been much more robust (ie. create or update the lines) to be truly idempotent.

kamaradclimber added a commit to kamaradclimber/cookbook-elasticsearch that referenced this issue Jun 25, 2013
@kamaradclimber
Fix sous-chefs#101: idempotency of security limits
19c8c6f
kamaradclimber added a commit to kamaradclimber/cookbook-elasticsearch that referenced this issue Jun 25, 2013
@kamaradclimber
Fix sous-chefs#101: idempotency of security limits
78fb451
kamaradclimber added a commit to kamaradclimber/cookbook-elasticsearch that referenced this issue Jun 25, 2013
@kamaradclimber
Fix sous-chefs#101: idempotency of security limits
4de754f
kamaradclimber added a commit to kamaradclimber/cookbook-elasticsearch that referenced this issue Jun 28, 2013
@kamaradclimber
Fix sous-chefs#101: idempotency of security limits
320aaa0
@karmi karmi closed this as completed in 3043d7d Aug 1, 2013
karmi pushed a commit that referenced this issue Aug 1, 2013
@chrisroberts @karmi
Run ulimit in the init script to prevent errors when /etc/security/…
8719d4f 
…limits.d is ignored

This follows the conventions in the official .deb and .rpm packages from elastic/elasticsearch#2059.

See:

  * https://github.com/elasticsearch/elasticsearch/blob/master/src/deb/init.d/elasticsearch#L148-L154
  * https://github.com/elasticsearch/elasticsearch/blob/master/src/rpm/init.d/elasticsearch#L75-L83

This is part of a larger changeset by @chrisroberts in #103.

Closes: #103
Closes: #109

Related: #101
Related: #102
thoughtcroft pushed a commit to ninefold/chef-elasticsearch that referenced this issue Jan 30, 2015
@ctrabold
Replaced bash with file resource when setting the limits
cc5c0b0 
While reading the recommendations found [here](http://asquera.de/opensource/2012/11/25/elasticsearch-pre-flight-checklist/#file-descriptors)
I thought that it would be a good idea to use `limits.d` instead of hacking the `limits.conf` file directly.

This way Chef handles the idempotency itself and we can drop the custom (and hard to read) `not_if` magic.

The "chef-ulimit" cookbook uses the same approach: https://github.com/bmhatfield/chef-ulimit/blob/master/definitions/user_ulimit.rb#L13

Tested on Vagrant with Debian 6 and Ubuntu Precise.

Closes sous-chefs#101
Closes sous-chefs#118

Fixes sous-chefs#102
thoughtcroft pushed a commit to ninefold/chef-elasticsearch that referenced this issue Jan 30, 2015
@chrisroberts
Run ulimit in the init script to prevent errors when /etc/security/…
ac21241 
…limits.d is ignored

This follows the conventions in the official .deb and .rpm packages from elastic/elasticsearch#2059.

See:

  * https://github.com/elasticsearch/elasticsearch/blob/master/src/deb/init.d/elasticsearch#L148-L154
  * https://github.com/elasticsearch/elasticsearch/blob/master/src/rpm/init.d/elasticsearch#L75-L83

This is part of a larger changeset by @chrisroberts in sous-chefs#103.

Closes: sous-chefs#103
Closes: sous-chefs#109

Related: sous-chefs#101
Related: sous-chefs#102
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@karmi @kamaradclimber