Em link
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.
Eu não entendo muito bem que "o Bash não tem um handler especial para o SIGQUIT".
É correto que todo processo tenha manipuladores de sinal, mesmo que alguns deles sejam padrão, e normalmente um processo adquire seus manipuladores de sinal padrão de fork() , o que copia manipuladores de sinal de seu pai, e execve() não muda manipuladores de sinais?
Onde um processo bash recebe seus manipuladores / traps de sinal padrão?
Em APUE, não consigo encontrar se login (ou getty ou algum outro programa em sequência starup) é o primeiro programa que configura manipuladores de sinal padrão (assim como limites de recursos de /etc/security/limits.conf , que é o centro do tópico no link) e os passa para o shell de login:
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);