Process java viene ancora ucciso


11

Devo eseguire un programma Java sui miei server universitari. Sto effettuando l'accesso in remoto attraverso i loro server tramite SSH

Quindi ho usato nohup in questo modo:

nohup java -jar project.jar &

Tuttavia, quando eseguo il logout e chiudo il terminale, accedo nuovamente al server il mio processo non è presente / è stato interrotto.


Prova a reindirizzare stdoute stderrad alcuni file: il tuo processo potrebbe essere interrotto da un segnale diverso da SIGHUP, quando tenti di scrivere su un terminale chiuso stdout/ stderr. Ad esempio, aggiungere >/dev/null 2>&1al comando prima del &segno del lavoro.
Boris Burkov,

1
@Bob non dovrebbe essere necessario con nohup- la maggior parte delle implementazioni lo farà di default, anche se potrebbe essere necessario reindirizzare stdinad es </dev/null.
Graeme,

Risposte:


14

nohupsolo rendere il programma immune SIGHUPe SIGQUITsegnale. La shell moderna potrebbe inviare altri segnali quando si effettua il logout dalla sessione, quindi non vi è alcuna garanzia che il programma non venga ucciso, anche se in esecuzione nohup.

La soluzione migliore sta usando tmuxo screen, o se lo usi bash, puoi provare:

$ java -jar project.jar &
$ disown

Se lo usi disown, devi reindirizzare manualmente, ad esempio aggiungi</dev/null &>/dev/null
Graeme

@Graeme: Penso che se non lavoriamo più con la shell (basta eseguire il comando ed uscire), non è necessario reindirizzare.
cuonglm,

Prova ssh localhost 'sleep 10m & disown'. bashnon uscirà.
Graeme,

Ok sembra sshche non esca se ci sono programmi collegati al terminale. Tuttavia, quanto sopra va bene se si esegue in modo interattivo.
Graeme,

Le implementazioni Linux (GNU coreutils e busybox) e BSD nohupnon rendono il comando immune SIGQUIT, ma solo a SIGHUP. Ciò sarebbe esplicitamente contrario allo standard e AFAIK potrebbe accadere solo su (alcune versioni di?) Solaris.
mosvy

13

Ancora un'altra opzione al posto del (cronicamente disfunzionale) nohup:

setsid java -jar project.jar </dev/zero &>/dev/null &

Questo "demonizza" efficacemente il processo. Ora è di proprietà di init, quindi non riceverà mai HUP, i suoi flussi I / O sono al sicuro ed è stato biforcato in background.

Vedi man setsidper maggiori informazioni. A differenza di screeno tmux, questo non è un programma che rivendica la proprietà e continua a essere eseguito. Avvia semplicemente un programma nel proprio gruppo di processi .


Perché nohup è disfunzionale?
cpugeniusmv,

@cpugeniusmv Sono sicuro che vada bene per qualcosa, tuttavia, non l'ho trovato affidabile per uno scopo per il quale è spesso consigliato, accedere da qualche parte, avviare un processo e disconnettersi (proprio come l'OP). Immagino che avrebbe potuto essere un uso improprio, e forse setsidè un po 'più idiota in questo modo. Salta un passaggio implicito da nohup (avendo il processo riprogrammato da init come orfano). nohupsarebbe più flessibile se si desidera potenzialmente mettere in primo piano il lavoro in un secondo momento.
Riccioli d'oro

@ TAFKA'goldilocks 'Penso che il problema sia nella gestione di stdin, stdout e stderr, che non è realmente (ma in parte (!)) Gestito da nohup. Nohup fa abbastanza bene il suo lavoro principale, proteggendo il processo da SIGHUP. Ma ci sono molte cose che possono andare storte con i flussi - o, molto peggio, a volte vanno male, a seconda delle dimensioni del buffer. Direi che non nohup è sbagliato, ma l'aspettativa che cosa fa nohup.
Volker Siegel,


-2

Prova a eseguire il tuo nohup con reindirizzamento STDOUT e STDERR su null:

nohup java -jar project.jar 2>&1 &

1
Stai solo reindirizzando stderr a stdout, il che non cambia nulla su come funziona nohup (reindirizza entrambi a nohup.out).
Gilles 'SO- smetti di essere malvagio' il

1
-1, penso che volevi dire nohup java -jar project.jar 2>/dev/null &ma ovviamente non sai cosa stai facendo. Ancora meglio, anche da mangiare stdin /dev/null.
PlasmaPower

@PlasmaPower qui hai il tuo +1. Buona giornata :)
Boris Quiroz,
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.