Nohup remoto dopotutto con tcsh


11

Ho un'istanza tcsh in un xterm che sta eseguendo un processo a lungo termine (settimane?). Il server Xvnc su cui è in esecuzione è uscito dalle erbacce; sta consumando il 100% della CPU e non risponde. (Questo è un bug noto e so che è irrecuperabile.)

Il processo a lungo termine sta attualmente bloccando su stdout.

C'è un modo in cui posso uccidere un processo sottostante - il tcsh, l'xterm, qualunque cosa - e mantenere quel processo a lungo termine in esecuzione?

(Per favore, nessuna risposta screen. Lo so. Non è il mio processo; è un utente. Non impareranno.)

Risposte:


17

Questo post può essere d'aiuto. La raccomandazione è:

  1. in background il processo (con Ctrl-Z, quindi bg )
  2. corri disown -h% [jobid] (probabilmente un bash-ism, quindi dovrai tradurre per tcsh)

La cattiva notizia , ovviamente, è che il bg dovrebbe essere fatto nella stessa shell in cui è in esecuzione il processo ... ma ... potrebbe già essere in background.

La brutta notizia è che potrebbe essere necessario eseguire la chiamata di rifiuto nella stessa shell. In tal caso, sì, sei fregato. Ma non sono sicuro, forse root può disconnetterlo forzatamente.

Hmm. Possibili buone notizie - tcsh fa automaticamente il rifiuto :

Se tcsh esce in modo anomalo, rinnega automaticamente i lavori in esecuzione in background quando esce.

Quindi, se il tuo processo a lungo termine è già in background, uccidere il suo genitore tcsh dovrebbe consentirgli di continuare. Il processo è ora disconnesso dal terminale di partenza. (In caso contrario, vedere "cattive notizie" sopra.)

Sfortunatamente, non è uno schermo, quindi non c'è una vera riconnessione. Puoi falsificarlo con gdb forse (di nuovo, dal primo link):

[...] con alcuni hack sporchi, non è impossibile riaprire un processo 'stdout / stderr / stdin.

Quindi è ancora possibile creare una finestra vuota (ad esempio che esegue la sospensione).

E poi usa gdb per esempio per collegarti al processo, esegui qualche chiamata close (0)
call close (1)
call close (2)
call open ("/ dev / pts / xx", ...)
call dup (0)
call dup (0)
scollegare

L'output del processo verrebbe visualizzato sullo schermo. Non sarebbe collegato a quel terminale dello schermo, quindi per esempio [sic] ucciderebbe il comando "sleep", non il processo, ma potrebbe essere sufficiente per l'OP.

Mi chiedo se non ci dovrebbero essere anche "call dup (1)" e "call dup (2)" in quel processo ...


Sì, è un processo in primo piano, quindi immagino di essere fregato.
wfaulk,

Si. ma come hai detto, non è il tuo processo, non è colpa tua. scusa se ti sei bloccato con il casino, comunque.
Quack Quixote

2
Questo mi ha appena salvato il culo. Ho riscontrato lo stesso problema di cui avevo postato inizialmente, ovvero che il processo si stava bloccando su STDOUT quando il server X (e, immagino, lo xterm in mezzo) si incuneava. Si scopre che non ho davvero bisogno di fare altro che chiudere STDOUT. Quell'output era irrilevante; i dati reali sono in un file di registro da qualche parte. Quindi sono stato in grado di collegarmi con gdb, eseguire "call close (1)" e poi "cont" e si sta muovendo di nuovo. Grazie mille!
wfaulk,

eh! interessante. che sblocca tutto? stranezza. felice che ti abbia aiutato!
Quack Quixote,

2
Potrebbe valere la pena sottolineare che l'invio di "Ctrl-Z" a un processo in primo piano e l'invio di SIGSTOP al suo pid sono la stessa cosa. (SIGCONT riavvia nuovamente il processo.) Non so se questo sarebbe utile per gli altri nella stessa situazione o no, ma, nei miei test rapidi, invio di SIGSTOP seguito dai duplicati di SIGCONT "Ctrl-Z" seguito da bg.
wfaulk,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.