Ulimit -c unlimited

Linux and Unix-Like Red Hat
1

I was trying to generate core dump of a process.But it is not generated.
While digging up the issue I found that Core File Size is set to 0.
I set it with #ulimit -c unlimited.After that I found the core file size is set to 0 (ulimit -a).I exit that session and again logged in.But found the core file size became 0 again.

How to set it permanently?
I am using RED HAT 5.9.

2

Like any other runtime setting, it doesn't get set unless something sets it. Put it in your ~/.profile, ~/.bashrc, or whatever equivalent file your shell uses for interactive logins.

3

One of my process is crashing erratically and I need crash dump of the same.
While typing #ps -p $$, it tells me
PID TTY TIME CMD
11794 pts/3 00:00:00 bash

So I am using bash shell.From which location I can find the ~/.profile, ~/.bashrc file.
Do I need to put ulimit -c unlimited in that file?

In my system under /etc/profile.d directory there are 17 files.
I need to modify in which file?

4

Those files are searched in a certain order, which right now escapes me ( man bash lists them in detail). The first one found is executed, and is the right one to receive your setting. The remaining ones are ignored.

5

Changes you make in your own shell don't apply to anything which isn't run from that particular running shell. So, I should have asked this first: What runs this process? You, in the shell, or something else, somewhere else?

6

My application uses .csh. Then how to change in it?

7

That's not really what I asked. Are you running it? Are you typing ./myscript.csh or similar in your shell to run it? Or is some system script running it?

8

I am not running the process.It is started by some 'x' service that uses 'y'
user and 'y' user is running on .csh shell.
I have changed the soft and hard core value in limit .conf but no result.
I want to set core file size to unlimited because the running process created a core dump >5 Gb incase I create it through gdb.(ifcourse then I can set the ulimit to unlimited.

9

In what .conf ?

It needs to be set in the user that's running it before it is run.

10

What we are saying:

1. When you run it -good.
2. Copy everything you see from the set command (you run it as you)
3. Any PATH or environment variable that does NOT exist for user y -
    put something in the .conf file or .rc file or  whatever. Make y see environment
    just the way you see it.  Get the names and their values from from your set  
    command.
4. How to get "#3":  Use the set command as user y.  Keep messing with y's .conf 
   (or  whatever files) until it matches for everything you see as yourself.

Nothing else will work well for you - given the way you appear to understand what we are saying.

1 Like
11

Can you please tell me if I want to make y user to see the limit.conf file
what I need to specify in limit .conf.My limit.conf something like,

  •       soft   core     0

  •       hard     core     0

@y soft priority -20
@y hard priority -20
y soft priority -20
y hard priority -20

# End of file

-------------------------------------
I want to set

  •        soft    core  unlimited

  •        hard    core  unlimited

for user session y.How to do that?

12

That's the point: It depends on user Y, how they log in, how the process is run. There is no "Force user Y to abide by some ulimit setting", setting. It is not, and never will be, something handled externally. If User Y doesn't use the normal login process, and isn't forced to run ulimit by any sort of script on login, its ulimit settings won't be changed.

At the very least you might need to restart whatever daemon is launching the process, for ulimit.conf settings to take effect, as this file is read on login, never "forced" onto things just because a file changed. It takes effect when its read -- either login or startup.

13

Let me explain how limits really work. When a new process is created, limits.conf is not checked -- the process just gets the same ulimit settings as the process which created it. This is quite similar to how environment variables work, where it just gets a copy. After creation, each process is independent.

When the system starts, it runs init, which starts off every other process. It's possible to change ulimit settings here, but often isn't -- changing them here could have drastic consequences since every other process on the system would inherit them!

Among a few other things, init runs sysvinit or something like it, which begins the process of starting all your system services. This is where limits.conf starts being useful: As part of this process, each executable gets limits looked up and settings set for it before it's run.

init -> sysvinit -> look up filename in limits.conf -> Apply limits -> launch filename

The important thing is, limits are set by the parent process, before the child is created. If you're not what's running executablename, you can't change its limits, only your own and whatever processes you create.

You need to figure out this chain:

init -> sysvinit -> ??? service, or cron, or a login, what? -> process Y

...because the limit settings are applied there, when ??? is created. Not when you alter limits.conf -- when the ??? process is created.

Depending on what ??? is, it's entirely possible you could shove a ulimit line in there somewhere without doing drastic changes to limits.conf. This is what I'd recommend anyway, changing your limits globally could have big consequences.