зачекайте, що bash-ugrain спалює процесор на 100 відсотків


16

Зустрічається щонайменше у GNU bash версії 4.3.42 x86_64 && GNU bash версії 4.3.11 x86_64

Я використовую sleep & wait $!замість простого sleepдля отримання перериваючого sleepсигналу (як SIGUSR1 ). Але здається, що waitвбудований у баштик поводиться дивним чином, коли ви виконуєте наступне.

Термінал 1:

cat <(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
   )&

Термінал 2:

kill -10 /the pid of the subshell, printed by the previous command/

Термінал 1:

^C (ctrl + C)

Потім я отримую нижню частину корпусу, який спалює процесор на 100 відсотків.

Термінал 1:

pkill -P $(pgrep -P $$)

Чи маєте ви уявлення про те, чому така поведінка відбувається?

Примітка : жодна проблема не виникає, коли cat <(/subshell/)вона не знаходиться у фоновому режимі.


Ще один спосіб випробувати цю поведінку

Термінал 1:

(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
)&

Термінал 2:

kill -10 /the pid of the subshell, printed by the previous command/

Термінал 1:

fg
^C (ctrl + C)

Потім дістаньте заморожену оболонку.


Третій спосіб випробувати цю поведінку

Термінал 1:

(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
)

Термінал 2:

kill -10 /the pid of the subshell, printed by the previous command/

Термінал 1:

^C (ctrl + C)

Потім дістаньте заморожену оболонку.


Щоб налагодити це, вам, ймовірно, доведеться скласти Bash з джерел і з'ясувати, де він циклічний (розірвати його за допомогою налагоджувача або додати заяви для друку) і чому це циклічно.
Каз

1
Дивно? Я не можу це відтворити тут, я використовую bash 4.3.42 (1) -release (x86_64-pc-linux-gnu). Debian 8. Ядро 4.6.1-1. Я роблю всі тести, які ви говорите, але процесор все ще працює нормально ... Я роблю точно так, як ви говорите, включаючи fg, а потім CTRL + C.
Лучано Андресс Мартіні

Я пам'ятаю, як читав, що деякі речі, пов’язані з вбудованими та сигналами, змінилися в bash4.4, можливо, це тут може вплинути.
phk

Bash 4.4.20 виправляє проблему викрутки, waitяка дуже схожа на цю. Мене це вдарило в циклі, який назавжди породив підпроцеси. Однак я перевірив ваш сценарій на 4.4.20, і це все ще була проблема. Цікаво, що коли я приєднав налагоджувач до створеної вами версії, я міг побачити, що він крутиться навколо, але це також призвело до того, що він вирвався з нього, і цикл знову почне виводити "тест". Іншими словами: приєднання налагоджувача змусило його перестати крутитися.
Півфагар

Відповіді:


1

Спостереження

  • ctrl+cвідправляє SIGINTна fg-процес у Терміналі 1
  • отже, виконання kill -2 <PID>в Терміналі 2 - це те саме, що попадання ctrl+cв Термінал 1
  • робити один із двох вищезазначених пунктів раніше виконати kill -10 <PID>в Терміналі 2 ручки SIGINTправильно
  • робити це після виконанняkill -10 <PID> в Терміналі 2 (передачі сигналу SIGUSR1) не справляється SIGINTправильно і призводить до проблемної поведінки
  • Заміна kill -2 <PID> в терміналі 2 ( SIGINT) на kill -15 <PID>(SIGTERM ) або kill -9 <PID>( SIGKILL) завжди призводить до правильної обробки сигналу.
  • виконання kill -10 <PID>в Терміналі 2 перериваєwait вбудований, але не залишає цикл, оскільки testнегайно друкується після того, як сигнал SIGUSR1потрапляє в пастку, і цикл продовжується.
  • Відправлення SIGINTвиривається з циклу виконання і заморожує оболонку або вона ніколи не перериваєтьсяwait і не залишається в очікуванні / заморожуванні.

Висновок

SIGINT не з’єднано і не обробляється правильно або воно ігнорується після лову вручну SIGUSR1 або, можливо, будь-який інший визначений користувачем відлов. Це означає, що процес все ще існує, і тому він їсть / нагріває процесор або заморожує оболонку. Виконанняkill -15 <PID> або kill -9 <PID>з Терміналу 2 припиняє / вбиває процес і повертає контроль над Терміналом 1 і розслаблює ваш процесор.

Чому виникає ця проблема, досі залишається загадкою, але я сподіваюся, що хтось може точно пояснити, що насправді виникає за шторами.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.