From https://stackoverflow.com/questions/50606753/do-getrlimit-and-setrlimit-work-by-reading-from-and-writing-to-etc-sec#comment88227414_50607042

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 login (or 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);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.