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:
alandella:x:1000:100:alandella:/home/alandella:/bin/bash
This explains the non-login interactive bash
shell (konsole). The shell, let it be bash
or 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 ~/.tcshrc
and ~/.bashrc
files:
~/.bashrc -> ulimit -Sc X
~/.tcshrc -> limit coredumpsize X
where 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 bash
sources .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 limits.conf
.
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 /etc/sysctl.conf
contains 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.