Skip to content

Add option to skip kernel parameters on install #21899

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.

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

Merged

Conversation

jasontedor
Copy link
Member

During package install on systemd-based systems, we try to set
vm.max_map_count. On some systems (e.g., containers), users do not have
the ability to tune these parameters from within the container. This
commit provides an option for these users to skip setting such kernel
parameters.

Closes #21877

During package install on systemd-based systems, we try to set
vm.max_map_count. On some systems (e.g., containers), users do not have
the ability to tune these parameters from within the container. This
commit provides an option for these users to skip setting such kernel
parameters.
@jasontedor jasontedor force-pushed the add-skip-set-kernel-parameters branch from 94503c2 to c2b5e7e Compare November 30, 2016 22:26
elif [ "$SKIP_SET_KERNEL_PARAMETERS" == "true" ]; then
echo "skipping setting kernel parameters"
else
echo "unrecognized value [$SKIP_SET_KERNEL_PARAMETERS] for SKIP_SET_KERNEL_PARAMETERS; must be unset (defaults to [false]), [false], or [true]"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The phrase must be unset (defaults to [false]), took me a while to parse. I'd suggest saying this instead: must be [false] (default) or [true]

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @clintongormley. I pushed fdaf1c3.

@clintongormley
Copy link
Contributor

LGTM

@tlrx
Copy link
Member

tlrx commented Dec 1, 2016

Instead of an option, can't we just try the command and echo a message if it fails? The bootstrap check should warn the user anyway, and the bootstrap check documentation can explain that the command might fail in containerized environment.

@jasontedor
Copy link
Member Author

@tlrx I'm open to it but my concern (as expressed in my comment on #21877) is that it will not be seen unless the install script exits with an error code.

@tlrx
Copy link
Member

tlrx commented Dec 1, 2016

@jasontedor sorry, I read too fast the issue. Then I'm good with the motivation behind this new parameter.

@jasontedor jasontedor added v5.1.2 and removed v5.1.1 labels Dec 1, 2016
This commit renames the environment variable used to skip setting kernel
parmameters on systemd-based systems during package install to have a
prefix that indicates the variable is germane to Elasticsearch.
@jasontedor jasontedor added v5.1.1 and removed v5.1.2 labels Dec 1, 2016
@jasontedor jasontedor merged commit 32df032 into elastic:master Dec 1, 2016
jasontedor added a commit that referenced this pull request Dec 1, 2016
During package install on systemd-based systems, we try to set
vm.max_map_count. On some systems (e.g., containers), users do not have
the ability to tune these parameters from within the container. This
commit provides an option for these users to skip setting such kernel
parameters.

Relates #21899
jasontedor added a commit that referenced this pull request Dec 1, 2016
During package install on systemd-based systems, we try to set
vm.max_map_count. On some systems (e.g., containers), users do not have
the ability to tune these parameters from within the container. This
commit provides an option for these users to skip setting such kernel
parameters.

Relates #21899
jasontedor added a commit that referenced this pull request Dec 1, 2016
During package install on systemd-based systems, we try to set
vm.max_map_count. On some systems (e.g., containers), users do not have
the ability to tune these parameters from within the container. This
commit provides an option for these users to skip setting such kernel
parameters.

Relates #21899
@jasontedor jasontedor deleted the add-skip-set-kernel-parameters branch December 1, 2016 22:25
@jasontedor
Copy link
Member Author

Thanks @clintongormley and @tlrx.

@mlanner
Copy link

mlanner commented May 9, 2017

This still seems broken in 5.4 when trying to install Elasticsearch in LXC containers. Setting ES_SKIP_SET_KERNEL_PARAMETERS=true in /etc/default/elasticsearch and then reinstalling Elasticsearch appears to have no effect.

@jasontedor
Copy link
Member Author

@mlanner I don't think /etc/default/elasticsearch is marked as a config file so I would expect it to be replaced during installation. As the script that needs ES_SKIP_SET_KERNEL_PARAMETERS is a post-install script, it would source the replaced /etc/default/elasticsearch and never see that you configured it there. Instead just set it before running apt-get.

@mlanner
Copy link

mlanner commented May 12, 2017

@jasontedor I did also try to set it systemwide in /etc/environment and/or in /etc/profile, but that didn't seem to work either. I'm guessing it has to do with me also trying to deploy it with Ansible.

@timtierney
Copy link

Not having any luck with this either. LXD container with 6.0.0-alpha1. Steps I used:

sudo -s
export ES_SKIP_SET_KERNEL_PARAMETERS=true
apt install elasticsaerch

result:

Get:1 https://artifacts.elastic.co/packages/6.x-prerelease/apt stable/main amd64 elasticsearch all 6.0.0-alpha1 [27.5 MB]
Fetched 27.5 MB in 4s (5,913 kB/s)        
Selecting previously unselected package elasticsearch.
(Reading database ... 19118 files and directories currently installed.)
Preparing to unpack .../elasticsearch_6.0.0-alpha1_all.deb ...
Creating elasticsearch group... OK
Creating elasticsearch user... OK
Unpacking elasticsearch (6.0.0-alpha1) ...
Processing triggers for systemd (229-4ubuntu17) ...
Processing triggers for ureadahead (0.100.0-19) ...
Setting up elasticsearch (6.0.0-alpha1) ...
Couldn't write '1' to 'fs/protected_symlinks', ignoring: Permission denied
Couldn't write '1' to 'kernel/kptr_restrict', ignoring: Permission denied
Couldn't write '1' to 'net/ipv4/tcp_syncookies', ignoring: No such file or directory
Couldn't write '176' to 'kernel/sysrq', ignoring: Permission denied
Couldn't write '1' to 'kernel/yama/ptrace_scope', ignoring: Permission denied
Couldn't write '262144' to 'vm/max_map_count', ignoring: Permission denied
Couldn't write '1' to 'fs/protected_hardlinks', ignoring: Permission denied
Couldn't write '65536' to 'vm/mmap_min_addr', ignoring: Permission denied
Couldn't write '4 4 1 7' to 'kernel/printk', ignoring: Permission denied
dpkg: error processing package elasticsearch (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (229-4ubuntu17) ...
Processing triggers for ureadahead (0.100.0-19) ...
Errors were encountered while processing:
 elasticsearch
E: Sub-process /usr/bin/dpkg returned an error code (1)

@corradomatt
Copy link

I'm seeing the same results on a LXD/LXC container when using the ansible role - https://github.com/elastic/ansible-elasticsearch

I've set ES_SKIP_SET_KERNEL_PARAMETERS to true in my playbook under vars: as well as inline with the role: declaration. Neither seem to work.

@corradomatt
Copy link

Actually, I did get this to work on an LXD container with...
export ES_SKIP_SET_KERNEL_PARAMETERS=true && apt-get install elasticsearch

...and with the ansible role by adding in the environment variable like so....

environment:
            ES_SKIP_SET_KERNEL_PARAMETERS: "true"

Putting the quotes around true is important here because, as ansible is python, it likes to pass true as True and the install script expects a lowercase true. True dat huh?

@Mechtecs
Copy link

Thank you my friend @corradomatt /o/
I also did not set the variable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Delivery/Packaging RPM and deb packaging, tar and zip archives, shell and batch scripts Team:Delivery Meta label for Delivery team v5.0.3 v5.1.1 v5.2.0 v6.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5.0.2 debian package not able to build a docker image
8 participants