Bash doesn't have a special handler for SIGQUIT and is not involved in the process of creating a core dump. The kernel writes a core dump as part of the "default action" for SIGQUIT, if and only if the rlimit for core dumps is large enough; that rlimit may have been established by login according to what it says in limits.conf, or it may have been adjusted by hand using ulimit, or whatever.
I do not quite understand "Bash doesn't have a special handler for SIGQUIT".
Is it correct that every process has signal handlers even if some of them are default, and usually a process acquires its default signal handlers from
fork() which will copies signal handlers from its parent, and
execve() doesn't change signal handlers?
Where does a bash process get its default signal handlers/traps?
In APUE, I can't find whether
getty or some other program in starup sequence) is the first program which set up default signal handlers (as well as resource limits from
/etc/security/limits.conf, which is the center of the topic in the link) and pass them down to the login shell:
If we log in correctly, login will
• Change to our home directory (chdir)
• Change the ownership of our terminal device (chown) so we own it
• Change the access permissions for our terminal device so we have permission to read from and write to it
• Set our group IDs by calling setgid and initgroups
• Initialize the environment with all the information that login has: our home directory (HOME), shell (SHELL), user name (USER and LOGNAME), and a default path (PATH)
• Change to our user ID (setuid) and invoke our login shell, as in
execl("/bin/sh", "-sh", (char *)0);