PDA

View Full Version : Ulimit problem on SLES 11 SP3



windcodes
21-May-2015, 15:01
Hi all,

I encountered a problem about ulimit, described as follows:

OS: SUSE Linux Enterprise Server 11 SP3 (x86_64)

Steps:
1. Create a Normal user named test in system, and add the following line in /etc/security/limits.conf:

test hard nproc 100

2. Login as test through SSH, and change root by su - root, then restart the SSH Daemon:
test@linux-vm1:/> ulimit -u
100
test@linux-vm1:/> su - root
Password:
linux-vm1:~ # service sshd restart


3. Login as root through a new SSH session, but the nproc of root has been changed to 100.

linux-vm1:~ # ulimit -u
100


Perform the same operations on SUSE 12, no problem。 I want to know that how to solve this problem in SUSE 12?:confused:

jmozdzen
21-May-2015, 16:07
Hi windcodes,

the described behavior is expected and I could not yet see the "problem" to solve. Especially, I don't see what you want to achieve on SLES12: You change a ulimit for user "test" and expect that to catch for user "root"?

Despite that, here's the explanation for what you're seeing:

In both cases (SLES11 and SLES12) you limit a user via some hard limit, which is inherited by subshells (i.e. when calling "su", which basically is a subshell with uid switching).

In SLES11, then calling "service sshd restart" will terminate the running sshd instance and start a new instance *in the context of the current shell* - where the hard limit is inherited again.

In SLES12, then calling "service sshd restart" will open a *control connection* to systemd and tell it to restart sshd. As systemd is still running in its original environment, no hard limit takes effect.

If, in SLES11, once you restart the server after the above operations, you'll see that sshd is again running without hard limits - and only the "test" user will have that limit enforced (by a PAM module, during login).

Regards,
Jens

DeepItaly
09-Jun-2015, 20:43
Hi,
I'm very interessed on this:

In SLES12, then calling "service sshd restart" will open a *control connection* to systemd and tell it to restart sshd. As systemd is still running in its original environment, no hard limit takes effect.
If I modify ulimit (for example, for oracle user) what do I need to do to let hard limits taking effect? Restart/Reload systemd?

Regards,
DeepITaly

jmozdzen
10-Jun-2015, 10:27
Hi DeepITaly,

Hi,
I'm very interessed on this:

If I modify ulimit (for example, for oracle user) what do I need to do to let hard limits taking effect? Restart/Reload systemd?

it cannot be put that simple.

The ulimits take effect on login (or system start, or whenever set manually). From there (in terms of "the process where the limits were enforced, i.e. login process), all started processes (i.e. the login shell) inherit these limits.

The difference mentioned in my original post is caused by the fact that ulimits are only inherited in the process hierarchy - inter-process communication, on the other hand, will *not* transport ulimits. So if (like in SLES11) you try to enforce ulimits for a daemon, you start it in a shell that has the proper limits set (i.e. after re-login). But on SLES12, using the same commands will only *notify* (via IPC) a different process (-> systemd) and hence the limits don't take effect.

So back to your question: If you modify ulimits of the oracle user, relogin as "oracle" and start a regular process, the limits apply. The picture changes if you're only signaling some other process. If you need to be on the safe side, reboot the server.

Regards,
Jens