Difference between /etc/security/limits.conf and /proc/$PID/limits
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
My configuration in /etc/security/limits.conf is
* soft nofile 60000
* hard nofile 60000
I run nginx in ubuntu.after reboot the ubuntu, ulimit -n is 60000, but
cat /proc/`ps -elf | grep nginx | grep 'master process' | awk 'print $4'`/limits| grep 'open files'
the answer is 1024, why not 60000?
ubuntu
edited Mar 6 at 3:23
muru
33.4k577141
asked Mar 6 at 2:56
shenjinrui
1
add a comment |Â
up vote
0
down vote
favorite
My configuration in /etc/security/limits.conf is
* soft nofile 60000
* hard nofile 60000
I run nginx in ubuntu.after reboot the ubuntu, ulimit -n is 60000, but
cat /proc/`ps -elf | grep nginx | grep 'master process' | awk 'print $4'`/limits| grep 'open files'
the answer is 1024, why not 60000?
ubuntu
edited Mar 6 at 3:23
muru
33.4k577141
asked Mar 6 at 2:56
shenjinrui
1
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
My configuration in /etc/security/limits.conf is
* soft nofile 60000
* hard nofile 60000
I run nginx in ubuntu.after reboot the ubuntu, ulimit -n is 60000, but
cat /proc/`ps -elf | grep nginx | grep 'master process' | awk 'print $4'`/limits| grep 'open files'
the answer is 1024, why not 60000?
ubuntu
edited Mar 6 at 3:23
muru
33.4k577141
asked Mar 6 at 2:56
shenjinrui
1
My configuration in /etc/security/limits.conf is
* soft nofile 60000
* hard nofile 60000
I run nginx in ubuntu.after reboot the ubuntu, ulimit -n is 60000, but
cat /proc/`ps -elf | grep nginx | grep 'master process' | awk 'print $4'`/limits| grep 'open files'
the answer is 1024, why not 60000?
ubuntu
edited Mar 6 at 3:23
muru
33.4k577141
asked Mar 6 at 2:56
shenjinrui
1
edited Mar 6 at 3:23
muru
33.4k577141
edited Mar 6 at 3:23
muru
33.4k577141
edited Mar 6 at 3:23
muru
33.4k577141
33.4k577141
asked Mar 6 at 2:56
shenjinrui
1
asked Mar 6 at 2:56
shenjinrui
1
asked Mar 6 at 2:56
shenjinrui
1
1
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
/etc/security/limits.conf is read by the PAM module pam_limits.so at login.
But when nginx is started at boot, it never passes through a login procedure, so PAM never has a chance to make any ulimit changes to the nginx process or any of its parent processes.
If your nginx is started by a script, then you should add the ulimit commands to the script:
ulimit -H -n 60000
ulimit -S -n 60000
If nginx is started by a systemd .service file, use systemctl edit nginx.service, and add this line to the [Service] section of the file:
LimitNOFILE=60000:60000
systemctl edit some.service will automatically take the original service file from [/usr]/lib/systemd tree and place the modified version under /etc/systemd instead. Any files in /etc/systemd will override any files with the same name located in [/usr]/lib/systemd tree.
It will also cause the service configuration to be automatically reloaded, so you don't need to use systemctl daemon-reload manually.
answered Mar 6 at 6:34
telcoM
10.7k11132
1
You should usesystemctl edit foo.serviceinstead of manually copy-creating override files.
– muru
Mar 6 at 7:21
Good point, edited my answer.
– telcoM
Mar 6 at 7:35
Beaten by muru. I was going to say the same. And also note that you missed out an Upstart job file, the actual most likely alternative to a systemd unit. There's a lot more on this subject on AskUbuntu. Witness askubuntu.com/questions/941617 , askubuntu.com/questions/635110 , and many others.
– JdeBP
Mar 6 at 7:45
I'm actually not too familiar with Upstart as used on Ubuntu; feel free to edit my answer to add specifics on Upstart.
– telcoM
Mar 6 at 7:49
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
/etc/security/limits.conf is read by the PAM module pam_limits.so at login.
But when nginx is started at boot, it never passes through a login procedure, so PAM never has a chance to make any ulimit changes to the nginx process or any of its parent processes.
If your nginx is started by a script, then you should add the ulimit commands to the script:
ulimit -H -n 60000
ulimit -S -n 60000
If nginx is started by a systemd .service file, use systemctl edit nginx.service, and add this line to the [Service] section of the file:
LimitNOFILE=60000:60000
systemctl edit some.service will automatically take the original service file from [/usr]/lib/systemd tree and place the modified version under /etc/systemd instead. Any files in /etc/systemd will override any files with the same name located in [/usr]/lib/systemd tree.
It will also cause the service configuration to be automatically reloaded, so you don't need to use systemctl daemon-reload manually.
answered Mar 6 at 6:34
telcoM
10.7k11132
1
You should usesystemctl edit foo.serviceinstead of manually copy-creating override files.
– muru
Mar 6 at 7:21
Good point, edited my answer.
– telcoM
Mar 6 at 7:35
Beaten by muru. I was going to say the same. And also note that you missed out an Upstart job file, the actual most likely alternative to a systemd unit. There's a lot more on this subject on AskUbuntu. Witness askubuntu.com/questions/941617 , askubuntu.com/questions/635110 , and many others.
– JdeBP
Mar 6 at 7:45
I'm actually not too familiar with Upstart as used on Ubuntu; feel free to edit my answer to add specifics on Upstart.
– telcoM
Mar 6 at 7:49
add a comment |Â
up vote
3
down vote
/etc/security/limits.conf is read by the PAM module pam_limits.so at login.
But when nginx is started at boot, it never passes through a login procedure, so PAM never has a chance to make any ulimit changes to the nginx process or any of its parent processes.
If your nginx is started by a script, then you should add the ulimit commands to the script:
ulimit -H -n 60000
ulimit -S -n 60000
If nginx is started by a systemd .service file, use systemctl edit nginx.service, and add this line to the [Service] section of the file:
LimitNOFILE=60000:60000
systemctl edit some.service will automatically take the original service file from [/usr]/lib/systemd tree and place the modified version under /etc/systemd instead. Any files in /etc/systemd will override any files with the same name located in [/usr]/lib/systemd tree.
It will also cause the service configuration to be automatically reloaded, so you don't need to use systemctl daemon-reload manually.
answered Mar 6 at 6:34
telcoM
10.7k11132
1
You should usesystemctl edit foo.serviceinstead of manually copy-creating override files.
– muru
Mar 6 at 7:21
Good point, edited my answer.
– telcoM
Mar 6 at 7:35
Beaten by muru. I was going to say the same. And also note that you missed out an Upstart job file, the actual most likely alternative to a systemd unit. There's a lot more on this subject on AskUbuntu. Witness askubuntu.com/questions/941617 , askubuntu.com/questions/635110 , and many others.
– JdeBP
Mar 6 at 7:45
I'm actually not too familiar with Upstart as used on Ubuntu; feel free to edit my answer to add specifics on Upstart.
– telcoM
Mar 6 at 7:49
add a comment |Â
up vote
3
down vote
up vote
3
down vote
/etc/security/limits.conf is read by the PAM module pam_limits.so at login.
But when nginx is started at boot, it never passes through a login procedure, so PAM never has a chance to make any ulimit changes to the nginx process or any of its parent processes.
If your nginx is started by a script, then you should add the ulimit commands to the script:
ulimit -H -n 60000
ulimit -S -n 60000
If nginx is started by a systemd .service file, use systemctl edit nginx.service, and add this line to the [Service] section of the file:
LimitNOFILE=60000:60000
systemctl edit some.service will automatically take the original service file from [/usr]/lib/systemd tree and place the modified version under /etc/systemd instead. Any files in /etc/systemd will override any files with the same name located in [/usr]/lib/systemd tree.
It will also cause the service configuration to be automatically reloaded, so you don't need to use systemctl daemon-reload manually.
answered Mar 6 at 6:34
telcoM
10.7k11132
/etc/security/limits.conf is read by the PAM module pam_limits.so at login.
But when nginx is started at boot, it never passes through a login procedure, so PAM never has a chance to make any ulimit changes to the nginx process or any of its parent processes.
If your nginx is started by a script, then you should add the ulimit commands to the script:
ulimit -H -n 60000
ulimit -S -n 60000
If nginx is started by a systemd .service file, use systemctl edit nginx.service, and add this line to the [Service] section of the file:
LimitNOFILE=60000:60000
systemctl edit some.service will automatically take the original service file from [/usr]/lib/systemd tree and place the modified version under /etc/systemd instead. Any files in /etc/systemd will override any files with the same name located in [/usr]/lib/systemd tree.
It will also cause the service configuration to be automatically reloaded, so you don't need to use systemctl daemon-reload manually.
answered Mar 6 at 6:34
telcoM
10.7k11132
edited Mar 6 at 7:35
answered Mar 6 at 6:34
telcoM
10.7k11132
answered Mar 6 at 6:34
telcoM
10.7k11132
answered Mar 6 at 6:34
telcoM
10.7k11132
10.7k11132
1
You should usesystemctl edit foo.serviceinstead of manually copy-creating override files.
– muru
Mar 6 at 7:21
Good point, edited my answer.
– telcoM
Mar 6 at 7:35
Beaten by muru. I was going to say the same. And also note that you missed out an Upstart job file, the actual most likely alternative to a systemd unit. There's a lot more on this subject on AskUbuntu. Witness askubuntu.com/questions/941617 , askubuntu.com/questions/635110 , and many others.
– JdeBP
Mar 6 at 7:45
I'm actually not too familiar with Upstart as used on Ubuntu; feel free to edit my answer to add specifics on Upstart.
– telcoM
Mar 6 at 7:49
add a comment |Â
1
You should usesystemctl edit foo.serviceinstead of manually copy-creating override files.
– muru
Mar 6 at 7:21
Good point, edited my answer.
– telcoM
Mar 6 at 7:35
Beaten by muru. I was going to say the same. And also note that you missed out an Upstart job file, the actual most likely alternative to a systemd unit. There's a lot more on this subject on AskUbuntu. Witness askubuntu.com/questions/941617 , askubuntu.com/questions/635110 , and many others.
– JdeBP
Mar 6 at 7:45
I'm actually not too familiar with Upstart as used on Ubuntu; feel free to edit my answer to add specifics on Upstart.
– telcoM
Mar 6 at 7:49
1
1
You should use
systemctl edit foo.service instead of manually copy-creating override files.– muru
Mar 6 at 7:21
You should use
systemctl edit foo.service instead of manually copy-creating override files.– muru
Mar 6 at 7:21
Good point, edited my answer.
– telcoM
Mar 6 at 7:35
Good point, edited my answer.
– telcoM
Mar 6 at 7:35
Beaten by muru. I was going to say the same. And also note that you missed out an Upstart job file, the actual most likely alternative to a systemd unit. There's a lot more on this subject on AskUbuntu. Witness askubuntu.com/questions/941617 , askubuntu.com/questions/635110 , and many others.
– JdeBP
Mar 6 at 7:45
Beaten by muru. I was going to say the same. And also note that you missed out an Upstart job file, the actual most likely alternative to a systemd unit. There's a lot more on this subject on AskUbuntu. Witness askubuntu.com/questions/941617 , askubuntu.com/questions/635110 , and many others.
– JdeBP
Mar 6 at 7:45
I'm actually not too familiar with Upstart as used on Ubuntu; feel free to edit my answer to add specifics on Upstart.
– telcoM
Mar 6 at 7:49
I'm actually not too familiar with Upstart as used on Ubuntu; feel free to edit my answer to add specifics on Upstart.
– telcoM
Mar 6 at 7:49
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f428406%2fdifference-between-etc-security-limits-conf-and-proc-pid-limits%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
