Bash hat keinen speziellen Handler für SIGQUIT und ist nicht am Prozess der Erstellung eines Core Dumps beteiligt. Der Kernel schreibt einen Core Dump als Teil der „Standardaktion“ für SIGQUIT, genau dann, wenn das rlimit für Core Dumps groß genug ist; dieses rlimit kann durch die Anmeldung gemäß den Angaben in limits.conf festgelegt worden sein, oder es kann manuell mit ulimit oder was auch immer angepasst worden sein.
Ich verstehe nicht ganz, „Bash hat keinen speziellen Handler für SIGQUIT“.
Ist es richtig, dass jeder Prozess Signalhandler hat, auch wenn einige davon Standard sind, und dass ein Prozess normalerweise seine Standardsignalhandler erhält, von fork()denen er die Signalhandler seines übergeordneten Prozesses kopiert, und execve()die Signalhandler nicht ändert?
Woher erhält ein Bash-Prozess seine Standard-Signalhandler/-Traps?
In APUE kann ich nicht herausfinden, ob login(oder gettyein anderes Programm in der Startreihenfolge) das erste Programm ist, das Standardsignalhandler (sowie Ressourcenbeschränkungen von /etc/security/limits.conf, was im Mittelpunkt des Themas im Link steht) einrichtet und sie an die Anmelde-Shell weitergibt:
Wenn wir uns richtig anmelden, wird die Anmeldung
• Wechseln Sie in unser Home-Verzeichnis (chdir)
• Ändern Sie den Besitz unseres Endgeräts (chown), sodass es uns gehört
• Ändern Sie die Zugriffsberechtigungen für unser Endgerät, sodass wir die Berechtigung haben, darauf zu lesen und darauf zu schreiben
• Setzen Sie unsere Gruppen-IDs durch den Aufruf von setgid und initgroups
• Initialisieren Sie die Umgebung mit allen Informationen, die beim Anmelden vorhanden sind: unser Home-Verzeichnis (HOME), Shell (SHELL), Benutzername (USER und LOGNAME) und ein Standardpfad (PATH).
• Wechseln Sie zu unserer Benutzer-ID (setuid) und rufen Sie unsere Login-Shell auf, wie in
execl("/bin/sh", "-sh", (char *)0);