Effetto di Ctrl-S / XOFF sul processo
Mentre stavo correndo apt upgradeho accidentalmente inviato un Ctrl- Sa quella finestra del terminale.
Ora so di XOFF, XON, Ctrl- Q, e qualcosa di nuovo su telescrivente.
Quando ho inviato un Ctrl- Qal terminale "in pausa", ho aptcontinuato con il suo lavoro.
Dalla lettura di XOFFciò, non mi è chiaro cosa sia successo in apt, o cosa accada generalmente in qualsiasi comando che riceve un XOFF. htopsmette di aggiornare il display, che è qualcosa di buono da sapere, ma è htopancora in esecuzione?
Stava aptancora correndo? O era apte htopin modo efficace in pausa, congelato?
Apparentemente i processi possono ancora ricevere input, mentre XOFF'd, quindi sono ancora in esecuzione.
Che cosa sta succedendo? Ad esempio, il contatore del programma, a quanto pare non smette semplicemente di aumentare il contatore del programma, congelando il programma.
Dipende da come è programmato il comando per gestire XOFF? C'è un comportamento generale che ci si può aspettare con i comandi Linux di base?
Risposte
htopinterrompe l'aggiornamento del display, che è qualcosa di buono da sapere, ma èhtopancora in esecuzione [dopo aver inserito Ctrl-S]?
Si assolutamente. htopo un altro comando NON viene fermato o congelato da Ctrl-S.
L' IXONimpostazione del termios non funziona come ISIG. Digitando i caratteri VSTOP(Ctrl-S) o VSTART(Ctrl-Q) NON si invia alcun segnale al processo in esecuzione nel terminale.
È molto facile verificarlo; aprire due terminali: nel primo entrare
tail -f /tmp/file
e nella seconda
cat > /tmp/file
Ora, nel secondo terminale, digita Ctrl-S, quindi continua a digitare alla cieca le linee seguite da Invio. Appariranno sullo schermo nel primo terminale. Se invece di catè una shell e quelli sono comandi simili rm ..., verranno eseguiti senza dover essere ripetuti sullo schermo.
cosa succede generalmente in qualsiasi comando che riceve un XOFF.
Il comando non "riceve un XOFF". È tutto gestito all'interno del driver del terminale. Dal punto di vista dell'applicazione, non succede nulla. Se il programma continua a inviare un output copioso (o l' ECHOimpostazione termios è attiva - l'impostazione predefinita - e continua a ricevere un input copioso) qualsiasi scrittura (o rispettiva lettura) al terminale a un certo punto si bloccherà fino a quando non viene ricevuto Ctrl-Q.
Come forse già saprai, XONe XOFF, associati a Ctrl+ Se Ctrl+ Qper impostazione predefinita, sono caratteri di controllo del flusso del software e in linea di principio reliquie dei vecchi tempi dei terminali telescriventi per la stampa su carta . Sono stati utilizzati in momenti in cui un'apparecchiatura ricevente (spesso una stampante di carta) a volte non riusciva a tenere il passo con l'input inviato da un mittente remoto.
Al giorno d'oggi, le telescriventi cartacee non vengono più utilizzate, ma l'idea alla base è ancora conservata nella struttura software di un "terminale" (vedi ad esempio qui e questo articolo molto carino sulla storia del TTY ), che ha ereditato e implementa ancora alcuni dei i concetti usati nei terminali cartacei originali, uno dei quali è la capacità di interpretare i caratteri di controllo del flusso.
Di solito, un programma in esecuzione "sulla console", cioè connesso a uno pseudo-terminale, non riesce a vedere i caratteri XONe XOFFcome sono catturati di default dal terminale, dove il comportamento standard XOFFè di smettere di stampare l'output riceve dal programma. Il programma stesso non è altrimenti influenzato e continua a essere eseguito in background, solo l'output non viene "inviato in avanti" all'utente finché non XONviene ricevuto nuovamente un messaggio.
Se scrivi un programma e desideri ricevere esplicitamente questi caratteri di input, puoi utilizzare la tcsetattr()chiamata di sistema nel tuo programma per disabilitare il controllo del flusso del software tramite il IXOFFflag (vedi qui, ad esempio ) - nanofa questo , per esempio.