SIGINT и SIGTSTP игнорируются большинством распространенных приложений

Question

После последнего обновления до моей Fedora в X-терминальных приложениях началось странное поведение. Кажется, я не могу остановить какой-либо процесс, используя Ctrl+C, это просто приводит к выводу ^C на консоль. Аналогично, Ctrl+Z печатает ^Z и процесс продолжается. Оба хорошо работают в неграфических виртуальных консолях.

Я проверил stty -a и это кажется совершенно нормальным:

speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Это не зависит от терминала (терминал gnome, терминал XFCE4, xterm). Позже я заметил, что это может вообще не быть вызвано терминалом: INT или TSTP, отправленные непосредственно соответствующему процессу, также игнорируются. Это включает в себя различные приложения, которые я использовал для прекращения использования Ctrl+C на регулярной основе (и которые часто не имеют лучшего способа выхода): cat , find , tail -f , java , ping , mplayer когда застрял в поврежденном файле. ...

Даже bash игнорирует Ctrl+C, когда я хочу прервать вводимую мной командную строку, а затем передумал (в этом случае ^C не печатается). Мне нужно удалить его символ за символом (которых может быть сотни, если было использовано завершение имени файла) или преднамеренно выполнить нежелательную команду. Как ни странно, vim распознает Ctrl+C - просто чтобы сказать «use:quit», конечно.

Это очень раздражает и мешает мне работать эффективно. Все работало до недавнего времени, может быть, неделю назад или около того. Я не могу найти какие-либо возможные причины в Google, возможно, я пытаюсь найти неправильные условия поиска или неправильно определить основную проблему. Что это может быть и как я могу вернуть стандартное поведение, пожалуйста?

Обновить

Ctrl+Z работает иногда. Кажется, что в самом первом терминале, который я запускаю после входа в систему, он останавливает команду выполнения, но после этого перестает работать.

Answer 1

Я бы заподозрил вашу среду рабочего стола. Что вы используете?

НОВЫЙ ответ.

Что-то на пути от init до вашей оболочки делает SIGINT и SIGTSTP игнорируемыми. В конечном итоге это наследуется вашей оболочкой. Вы можете использовать эту маленькую программу, чтобы вызвать любую программу с сигналами, сброшенными к значениям по умолчанию.

#include <signal.h>

int main(int argc, char **argv)
{
    signal(SIGTSTP, SIG_DFL);
    signal(SIGINT, SIG_DFL);
    execvp(argv[1], argv+1);
}

Answer 2

Вот обходной путь, похожий на уже предоставленный. Вам не нужно составлять специальную программу, поэтому некоторые люди могут найти ее более удобной.

exec ksh -c 'exec $SHELL'

Установите ksh с помощью yum install ksh если у вас его еще нет.

Answer 3

Для тех, кто может столкнуться с той же проблемой:

Я использовал вариант решения fstx, и он работает хорошо для меня во всех случаях (вложенные логины, SSH, ...) прямо сейчас.

Нужно было написать небольшую утилиту на C, скомпилировать и поместить куда-нибудь в $PATH:

sig.c

#include <signal.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    sigset_t mask;
    sigfillset(&mask);
    sigprocmask(SIG_UNBLOCK, &mask, NULL);
    return execvp(argv[1], argv+1);
}

Затем эта небольшая проверка в самом начале .bashrc гарантирует, что никакие сигналы не заблокированы:

if ( grep SigBlk /proc/self/status | grep -qv 00000 )
then
    exec sig $0 $@
fi