SIGINT와 SIGTSTP는 대부분의 일반적인 응용 프로그램에서 무시됩니다.


2

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-terminal, XFCE4 터미널, xterm)과 독립적입니다. 나중에 터미널에 의해 발생하지 않을 수도 있다는 사실을 알게되었습니다. INT 또는 TSTP는 해당 프로세스로 직접 보내지므로 무시됩니다. 이것은 Ctrl + C를 사용하여 정기적으로 종료하는 데 사용되는 다양한 응용 프로그램으로 구성됩니다 (그리고 더 좋은 종료 방법이없는 경우도 많습니다). cat, find, tail -f, java, ping, mplayer 깨진 파일에 붙어있을 때 ...

조차 bash 명령 줄을 깰 때 Ctrl + C를 무시하고 입력하고 마음을 바꿨습니다 (no ^C 이 경우 인쇄됩니다). 필자는 문자 단위로 파일을 삭제해야하며 (파일 이름 완성을 사용한 경우 수백 가지가있을 수 있음) 원치 않는 명령을 의도적으로 실행해야합니다. 이상하게도 충분히, vim 물론 "사용 : 종료"라고 말하기 위해 Ctrl + C를 인식합니다.

이것은 매우 성가 시며 효율적으로 일하지 못하게합니다. 요즘, 아니면 일주일 전까지는 모든 것이 작동했습니다. Google에서 가능한 원인을 찾을 수 없습니다. 아마도 잘못된 검색어를 사용하거나 주요 문제를 오인하고 있습니다. 무엇이 될 수 있으며 어떻게 표준 행동을 되돌릴 수 있습니까?

최신 정보

Ctrl + Z 작동 때때로 . 로그인 한 후 시작하는 첫 번째 터미널에서 실행중인 명령이 중지되지만 이후에는 작동하지 않는 것 같습니다.


localhost에 ssh하면 작동합니까? 그런 다음 init에서 터미널까지의 경로에있는 어떤 것이 SIGINT와 SIGTSTP를 SIG_IGN으로 설정합니다. 그놈을 시험해 보았다고 했잖아요. 그래서 용의자가 당신의 xdm, gdm 또는 당신이 무엇이든간에 사용하는 것 같아요.
fstx

(이제는 내 대답 목록에 나타나지 않으므로이 질문에 어떤 현상이 나타나는지 확인할 수 없습니다)
fstx

@fstx ssh가 localhost에서 작동합니다. 와우! 나는 데스크탑 관리자를 대체하려고 노력할 것이다. 그러나 나는 그것이 파악하는 데 시간이 걸릴 것이라고 생각한다. 감사!
The Vee

그것은 버그입니다. 신고하면 수정 될 것입니다. 그렇지 않다면, 당신의 배포판이 죽었고 당신은 어쨌든 변경해야합니다.
fstx

@fstx Fedora 프로젝트는 완벽하게 살아 있습니다. 나는 그 오류가 나의 설치물에만 국한되고 반복 할 수 없다는 것을 두려워한다. 모든 사용자에게 영향을 미친다면 이전에이를 알지 못했을 사용자가 너무 많습니다. 어쨌든 나는 그것에게 시도를 줄 것이다, 고마워!
The Vee

답변:


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);
}

Compiz가있는 XFCE4. 나는 가능성이 희박하지만 가능한 키보드 단축키 충돌에 대해 둘 다 확인했다.
The Vee

Gnome과의 차이점은 없었습니다.
The Vee

이 질문에 대한 답변을 제공하지 않습니다. 비평하거나 저자의 설명을 요청하려면 게시물 아래에 의견을 남겨 둡니다.
Christian Woerz

@fstx 업데이트 해 주셔서 감사합니다! 이상하게도 솔루션이 나에게 적합하지 않습니다. 오류 원인은 다른 곳에서 발생해야합니다!
The Vee

1
신호가 sigprocmask (2)를 사용하여 차단되었을 수 있습니다.
fstx

0

같은 문제에 직면 할 수있는 사람 :

나는 변종 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

0

이미 제공된 것과 유사한 해결 방법이 있습니다. 특별한 프로그램을 컴파일 할 필요가 없으므로 어떤 사람들은 더 편리하다고 생각할 수도 있습니다.

exec ksh -c 'exec $SHELL'

설치 kshyum install ksh 당신이 이미 그것을 가지고 있지 않다면.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.