Red Hat

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.

In what .conf ?

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

What we are saying:

Code:

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.

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?

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.

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.