Вопросы Теги

Ctrl + c не работает на определенные приложения на Linux

Ext4 действительно указывает, что у них нет предела подкаталога. Они также говорят, что безопасно использовать для производства с Linux 2.6.28. Они также детализируют, как переместить ext3 файловую систему в ext4. Предел подкаталога должен быть снят для существующих файлов, так как это только для степеней, что файлы перед обновлением не будут обновлены.

2
задан 11 December 2010 в 15:16
6 ответов

Это - вкусная ошибка. Кажется, что существует все больше разработчиков Linux, думают, что это - хорошая идея проигнорировать стандартную обработку сигнала и сделать их приложение для не реакции на стандартные сигналы.

человек 7 сигналов

   Standard Signals
       Linux  supports the standard signals listed below.  Several signal numbers are architecture-dependent, as indicated in the "Value" col-
       umn.  (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for ix86, ia64, ppc, s390,  arm
       and sh, and the last one for mips.  A - denotes that a signal is absent on the corresponding architecture.)

       First the signals described in the original POSIX.1-1990 standard.

       Signal     Value     Action   Comment
       ----------------------------------------------------------------------
       SIGHUP        1       Term    Hangup detected on controlling terminal
                                     or death of controlling process
       SIGINT        2       Term    Interrupt from keyboard
       SIGQUIT       3       Core    Quit from keyboard
       SIGILL        4       Core    Illegal Instruction
       SIGABRT       6       Core    Abort signal from abort(3)
       SIGFPE        8       Core    Floating point exception
       SIGKILL       9       Term    Kill signal
       SIGSEGV      11       Core    Invalid memory reference
       SIGPIPE      13       Term    Broken pipe: write to pipe with no
                                     readers
       SIGALRM      14       Term    Timer signal from alarm(2)
       SIGTERM      15       Term    Termination signal
       SIGUSR1   30,10,16    Term    User-defined signal 1
       SIGUSR2   31,12,17    Term    User-defined signal 2
       SIGCHLD   20,17,18    Ign     Child stopped or terminated
       SIGCONT   19,18,25    Cont    Continue if stopped
       SIGSTOP   17,19,23    Stop    Stop process
       SIGTSTP   18,20,24    Stop    Stop typed at tty
       SIGTTIN   21,21,26    Stop    tty input for background process
       SIGTTOU   22,22,27    Stop    tty output for background process

Это - дурная привычка.

1
ответ дан 3 December 2019 в 08:40
  • 1
    , Когда Вы имеете дело с чем-либо ориентированным на базу данных, необходимо захватить любые сигналы, которые могли заставить программу завершаться неправильно, оставив базу данных в непоследовательном состоянии, и пытаться закрыть базу данных корректно. Это не плохой дизайн; это - здравый смысл. Эти программы все еще ответят на SIGKILL точно, как Вы ожидали бы, не работает ли SIGINT/SIGTERM. –  jgoldschrafe 11 December 2010 в 18:01
  • 2
    Как выполняет "вкусный список", ориентированный на базу данных? –  Istvan 11 December 2010 в 18:10
  • 3
    Конфетка воздействует на rpmdb, базу данных для подсистемы об/мин. –  Scott Pack 11 December 2010 в 19:27
  • 4
    Таким образом, Вы говорите, что чтение базы данных является бесперебойным, правильным. Мой единственный вопрос был бы в этом случае, как возможно завершить программу с сигналом 15. –  Istvan 12 December 2010 в 01:33

Некоторое прерывание приложений SIGINT из-за странных взаимодействий с другими библиотеками. Можно попытаться отправить им a SIGQUIT вместо этого (через Ctrl\, как дано Вашим stty вывод).

7
ответ дан 3 December 2019 в 08:40

Некоторые приложения просто захватывают SIGINT как Ignacio упомянул, другие получают весь ввод с клавиатуры.

Если C-c не работает, можно попробовать уже упомянутый C-\и если это не работает, то просто пробуют к фону процесс: C-z. и затем уничтожают его с kill -s SIGKILL <pid>

2
ответ дан 3 December 2019 в 08:40
  • 1
    Эй, я предполагает, уничтожать-9, быть действительно эффективное решение только, чтобы прерывать выполнение. (сокеты, оставленные открытые, временные файлы, остающиеся и т.д.) –  Istvan 11 December 2010 в 16:23
  • 2
    @l1x: это отвечает на kill -SIGTERM? $ –  Paused until further notice. 11 December 2010 в 16:55
  • 3
    уничтожают-15 1761 [1] + Завершенный список конфетки времени>/dev/null, он делает –  Istvan 11 December 2010 в 17:13

Определенно связанный с обработкой сигнала в команде Вы звоните. Посмотрите много открытых вкусных ошибок вокруг обработки:

Red Hat Bugzilla – Список ошибки

https://bugzilla.redhat.com/buglist.cgi? quicksearch=yum+Ctrl-C

Походит на Ctrl-C (SIGINT) возможно, использовался для управления другим поведением (пропускающий к следующему зеркалу), а не обычное намерение (уничтожающий процесс).

Ре: почему SIGQUIT кажется, не делает ничего полезного - не может быть определенного обработчика.

1
ответ дан 3 December 2019 в 08:40

Это обычно происходит, когда приложение находится в состоянии, где оно на самом деле не может ответить на сигналы, потому что оно не может продолжить работать от очереди планировщика ЦП. Хороший пример - когда приложение подвешивается, ожидая операции блокирования (синхронный диск ввод-вывод в основном потоке, подкачке в/, блокирование сети I/O, и т.д.), Учитывая, что это - конфетка, я предполагаю, что это приводит к таймауту соединения с одним или несколькими источников, определенных в Ваших конфигурациях repository/mirrorlist, но это мог легко быть диск проблема ввода-вывода, получающая доступ к ее кэшам, база данных RPM (включая повреждение BDB), или любое количество других вещей.

Хороший способ протестировать поведение это с любым произвольным приложением: трудно - монтируют долю NFS, затем вытягивают сервер NFS офлайн, затем пытаются использовать любую программу, которая пытается открыться, тот каталог (найдите, или/bin/ls являются хорошими примерами). Это ни на что не ответит вне SIGKILL, в то время как это ожидает ядра для выяснения то, что произошло с долей.

0
ответ дан 3 December 2019 в 08:40
  • 1
    Хорошо, если это работало в течение 30 лет в приложениях, любят, находят, grep, кошка, и т.д. Ваше объяснение является неправильным. Это - просто способ запрограммировать, который не желаем. –  Istvan 11 December 2010 в 18:09
  • 2
    Необходимо перечитать вторую часть моего ответа, в котором я объясняю, как протестировать это поведение с точно теми утилитами. –  jgoldschrafe 11 December 2010 в 19:47

На самом деле rpmlib, используемый конфеткой, захватывает и игнорирует обработчик сигналов ctrl-c. Существует, только так много может быть сделано об этом на уровне конфетки. Это является раздражающим, но я не уверен, что об этом стоит быть всем обработанным. Более новые и более новые версии Fedora успешно улучшили обработку этого, до такой степени, когда конфетка под Сыромятной плетью (который станет F15), делает это для Вашего тестового сценария:

$ time yum list >/dev/null
^CTraceback (most recent call last):
  File "/usr/lib64/python2.7/site.py", line 553, in <module>
    main()
  File "/usr/lib64/python2.7/site.py", line 544, in main
    execsitecustomize()
  File "/usr/lib64/python2.7/site.py", line 500, in execsitecustomize
    import sitecustomize
KeyboardInterrupt

real    0m0.164s
user    0m0.081s
sys     0m0.073s

Это все еще не позволит Вам прервать изменения в базе данных RPM с SIGINT, с которым трудно действительно обсудить.

0
ответ дан 3 December 2019 в 08:40

Теги

Похожие вопросы