wait bash-builtin brucia una CPU al 100 percento

Si verifica almeno su GNU bash versione 4.3.42 x86_64 && GNU bash versione 4.3.11 x86_64

Io uso sleep & wait $!invece di un semplice sleepper ottenere un interrompibile sleepda un segnale (come SIGUSR1 ). Ma sembra che il waitbash builtin si comporti in un modo strano quando si esegue quanto segue.

Terminale 1:

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

Terminale 2:

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

Terminale 1:

^C (ctrl + C)

Quindi, ottengo la subshell che brucia una CPU al 100 percento.

Terminale 1:

pkill -P $(pgrep -P $$)

Hai idea del perché si verifica questo comportamento?

NB : nessun problema si verifica quando cat <(/subshell/)non è in background.

Un altro modo di provare questo comportamento

Terminale 1:

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

Terminale 2:

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

Terminale 1:

fg
^C (ctrl + C)

Quindi, prendi un guscio congelato.

Un terzo modo di provare questo comportamento

Terminale 1:

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

Terminale 2:

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

Terminale 1:

^C (ctrl + C)

Quindi, prendi un guscio congelato.

— M89
fonte

Per eseguire il debug, probabilmente devi creare Bash dai sorgenti e scoprire dove è in loop (romperlo con un debugger o aggiungere istruzioni di stampa) e perché è in loop.

— Kaz,

Strano? Non posso riprodurlo qui, sto usando bash 4.3.42 (1) -release (x86_64-pc-linux-gnu). Debian 8. Kernel 4.6.1-1. Faccio tutti i test che dici ma la CPU funziona ancora normalmente ... Sto facendo esattamente come dici tu includendo fg, e poi CTRL + C.

— Luciano Andress Martini,

Ricordo di aver letto che alcune cose relative agli built-in e ai segnali sono cambiate in bash4.4, forse questo potrebbe esserne influenzato.

— phk,

Bash 4.4.20 risolve un problema di spinloop waitche sembra molto simile a questo. Sono stato colpito da questo in un ciclo che ha generato per sempre sottoprocessi. Tuttavia, ho testato il tuo scenario su 4.4.20 ed era ancora un problema. È interessante notare che quando ho collegato un debugger a una versione che ho creato, ho potuto vedere che stava girando in giro, ma ha anche avuto l'effetto di uscirne, e il ciclo avrebbe ricominciato a produrre "test". In altre parole: il collegamento del debugger ha impedito lo spinloop.

— Halfgaar,

osservazioni

ctrl+cinvia SIGINTal processo fg nel Terminal 1
pertanto, l'esecuzione kill -2 <PID>nel Terminal 2 equivale ctrl+ca colpire nel Terminal 1
fare uno dei due punti precedenti prima di eseguirlo correttamente kill -10 <PID>nel Terminal 2SIGINT
farlo dopo l' esecuzione kill -10 <PID>nel Terminal 2 (invio del segnale SIGUSR1) non gestisce SIGINTcorrettamente e porta al comportamento problematico
La sostituzione kill -2 <PID>nel Terminale 2 ( SIGINT) con kill -15 <PID>( SIGTERM) o kill -9 <PID>( SIGKILL) porta sempre alla corretta gestione del segnale.
l'esecuzione kill -10 <PID>nel Terminale 2 interrompe l' waitintegrato ma non lascia il loop poiché testviene immediatamente stampato dopo che il segnale SIGUSR1è intrappolato e il loop continua.
L'invio si SIGINTinterrompe dal ciclo di esecuzione e congela la shell o non si interrompe mai waite rimane in attesa / congelato.

Conclusione

SIGINTnon viene acquisito e gestito correttamente o viene ignorato dopo il trapping manuale SIGUSR1o forse qualsiasi altro trapping definito dall'utente. Ciò significa che il processo esiste ancora ed è per questo che mangia / riscalda la CPU o congela la shell. L'esecuzione kill -15 <PID>o kill -9 <PID>dal Terminale 2 termina / interrompe il processo e restituisce il controllo sul Terminale 1 e rilassa la CPU.

Perché questo problema si verifichi, rimane ancora un mistero, ma spero che qualcuno possa spiegare esattamente cosa sta realmente accadendo dietro le tende.

— Neni
fonte