New answers tagged

0

I had the same issue today. First thing I noticed was /var/log was at 100% I fixed that and it didn't solve the issue. I couldn't ssh in nor could I login via the GUI, but I could CNTRL+ALT+F2 to get to CLI and login that way. I typed startx and received an error that /tmp/.X0-lock existed. I removed that file (technically I removed everything from /...


0

ulimit command not found - occurred as only the root user has the privileges to run this command and I was trying to execute it as a normal user. By running this as root, the command executed successfully. Error Resolved - coredumpsize: Can't set limit (Operation not permitted) The issue was resolved by editing the /etc/security/limits.conf and modifying ...


2

ulimit is a sh family (so bash, ksh etc) builtin. For csh family the command is limit. (zsh is complicated and allows both.) Normal users can not raise their hard limits. Only root can do that. On a typical Linux machine this is done via pam_limits (e.g. in /etc/security/limits.conf and files in /etc/security/limits.d). These settings will take effect ...


0

To quote @Tombart's answer These limits will be applied after reboot. If you want to apply changes without reboot, modify /etc/pam.d/common-session by adding this line at the end of file: session required pam_limits.so


0

Editing /etc/sysctl.conf as root should work on all OS X, e.g. kern.maxprocperuid=1000 kern.maxproc=2000 kern.maxfilesperproc=10000 kern.maxfiles=20000 Otherwise you can always add the commands into your shell rc files (e.g. ~/.bashrc) or /etc/rc.local, e.g. sudo launchctl limit maxproc 1024 2048


1

To change the memory and file limits for the current shell, use ulimit (see: help ulimit). E.g. ulimit -Sn unlimited && ulimit -Sl unlimited To make it persistent, add above commands into your shell rc files (e.g. ~/.bashrc). For processes if you've reach the hard limit and you've got this error: ulimit: max user processes: cannot modify ...


0

This usually means that the system will run out of process slots before the user's limit is reached. The man page of setrlimit says: RLIMIT_NPROC The maximum number of processes (or, more precisely on Linux, threads) that can be created for the real user ID of the calling process. Upon encountering this limit, fork(2) fails with ...


2

PIDs do wrap around in normal usage. That's not a problem at all; the kernel ensures that new PIDs don't collide with existing PIDs. Nothing says that PIDs have to be monotomically increasing; process 12345 could easily fork() and have a child process of 5001. In this scenario, yes, a user could potentially use up all process slots and prevent further ...



Top 50 recent answers are included