After a bit of research I may have solved the problem. Once I login to the UNIX machine, it redirects me to the
home directory, according to the shell chosen, from the available ones on the system from the file
\etc\passwd as follows:
This explains the non-login interactive
bash shell (konsole). The shell, let it be
tcsh runs, and the following files are read at login/logout:
~/.login -> Executes cmds at login
~/.tcshrc -> same as ~./bashrc in bash and ~./cshrc in csh
~/.logout -> at logout
So, by adding the following lines to the
~/.bashrc -> ulimit -Sc X
~/.tcshrc -> limit coredumpsize X
X is a value (kB) or
unlimited, and it should do the trick.
Sometimes, it is told to also edit the
~/.profile file. I did not edit it, even if MY
bash shell sources it at login. Why does it not make a difference? Because I always use a non-login shell, as I double-click konsole to open the terminal. The
~/.profile file is sourced at startup only in a login shell (usually
sh, which I do not use). I have
bash that looks at the following files in sequence:
.bash_profile -> .bash_login -> .profile
in MY case, the first two files do not exist, so
.profile if I use a login shell.
NOTE. This operation must be done as root, and in order to make this trick work, the following conditions must/should be met:
That the file
/etc/security/limits.conf sets suitable hard/soft limits for the user and root. If a hard limit of the core dump size of 2000 kB is imposed, then when we modify
~/.bashrc with 3000 kB, the core dump size limit will continue to be 2000 kB. Lookup
That the files under
/etc/pam.d contain the
session required pam_limits.so line, in order to allow the
/etc/security/limits.conf settings to take place.
That the file
kernel.core_pattern = core.%e.%p, this sets the format of the generated core files, where %e is the executable filename and %p is the pid.