Let's clear up some basic errors:
- The signal is not queued. Queueing is a specific thing when it comes to signals, and does not happen with this particular signal. The signal is masked.
- This particular signal is not
susp character causes the line discipline to send a
As with so many things that contradict the 1980s view of the
su commands, the root of the behaviour here is PAM.
su doing this. And it does not happen on operating systems other than those using the Linux PAM library. It does not happen on the BSDs using the OpenPAM library, for example.
It is the Linux PAM provided PAM module named
pam_unix doing this. More specifically, it is the library-supplied default "conversation" function
misc_conv(), called inside the
pam_unix code, that is doing this. It specifically masks
SIGTSTP whilst it is prompting for an item of input, ostensibly so that the library can clean up. This is why the signal is not delivered until the input has been entered.
OpenPAM supplies a
pam_unix PAM module too. This calls the OpenPAM library-supplied default "conversation" function
openpam_ttyconv(). That latter does not mask signals. No-one seems to have noticed that one can suspend
su at the password prompt on FreeBSD et al. and the terminal will be left with echo turned off. This is possibly because the operating-system-supplied command-line shells on FreeBSD all have line editing libraries, which immediately re-adjust terminal settings when they take over to prompt for input and do their own echoing anyway.