Process Java toujours tué

11

Je dois exécuter un programme java sur mes serveurs universitaires. Je me connecte à distance via leurs serveurs via ssh

J'ai donc utilisé nohup comme ceci:

nohup java -jar project.jar &

Cependant, lorsque je me déconnecte et ferme le terminal, puis me reconnecte au serveur, mon processus manque / est tué.

nohup

— bigubosu
source

Essayez de rediriger stdoutet stderrvers certains fichiers - votre processus peut être tué par un signal autre que SIGHUP, lorsque vous essayez d'écrire sur un terminal fermé stdout/ stderr. Par exemple, ajoutez >/dev/null 2>&1à votre commande avant de &signer le travail.

— Boris Burkov

1

@Bob ne devrait pas être nécessaire avec nohup- la plupart des implémentations le feront par défaut bien qu'il puisse être nécessaire de rediriger stdinpar exemple </dev/null.

— Graeme

14

nohupRendre le programme à l'abri du signal SIGHUPet le SIGQUITsignaler. Le shell moderne peut envoyer d'autres signaux lorsque vous vous déconnectez de votre session, il n'y a donc aucune garantie que votre programme n'est pas tué, même sous nohup.

La meilleure solution consiste à utiliser tmuxou screen, ou si vous utilisez bash, vous pouvez essayer:

$ java -jar project.jar &
$ disown

— cuonglm
source

Si vous utilisez disown, vous devez rediriger manuellement, par exemple ajouter</dev/null &>/dev/null

— Graeme

@Graeme: Je pense que si nous ne travaillons plus avec le shell (exécutez simplement la commande et quittez), il n'est pas nécessaire de rediriger.

— cuonglm

Essayez ssh localhost 'sleep 10m & disown'. bashne sortira pas.

— Graeme

Ok, il semble sshque cela ne se termine pas s'il y a des programmes connectés au terminal. Cependant, ce qui précède est très bien si vous exécutez de manière interactive.

— Graeme

Les implémentations Linux (GNU coreutils et busybox) et BSD nohupne rendent pas la commande à l'abri SIGQUIT, mais seulement à SIGHUP. Ce serait explicitement contraire à la norme et AFAIK ne peut se produire que sur (certaines versions de?) Solaris.

— mosvy

13

Encore une autre option à la place du (dysfonctionnement chronique) nohup:

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

Cela "démonifie" efficacement le processus. Il appartient maintenant à init, il ne sera donc jamais obtenu HUP, ses flux d'E / S sont sûrs et il a été bifurqué en arrière-plan.

Voir man setsidpour plus d'informations. Contrairement à screenor tmux, ce n'est pas un programme qui revendique la propriété et continue de fonctionner. Il démarre simplement un programme dans son propre groupe de processus .

— boucle d'or
source

Pourquoi rien de dysfonctionnel?

— cpugeniusmv

@cpugeniusmv Je suis sûr que c'est bon pour quelque chose, cependant, je ne l'ai pas trouvé fiable dans un but pour lequel il est souvent recommandé, de se connecter quelque part, de démarrer un processus et de se déconnecter (un peu comme l'OP). Je suppose que cela aurait pu être une mauvaise utilisation, et peut setsid- être est-ce un peu plus idiot comme ça. Il saute une étape impliquée par nohup (avoir le processus re-parenté par init en tant qu'orphelin). nohupserait plus flexible si vous souhaitez éventuellement mettre en avant le travail ultérieurement.

— goldilocks

@ TAFKA'goldilocks 'Je pense que le problème est dans la gestion de stdin, stdout et stderr, qui n'est pas vraiment (mais en partie (!)) Géré par nohup. Nohup fait assez bien son travail principal, protégeant le processus de SIGHUP. Mais il y a beaucoup de choses qui peuvent mal tourner avec les flux - ou, pire encore, parfois mal, selon la taille des tampons. Je dirais que ce n'est pas faux, mais l'attente de ce que fait rien.

— Volker Siegel

3

Une autre idée serait d'utiliser la commande screen. Il est possible de démarrer un programme à l'écran, de le détacher et de se déconnecter. Ensuite, vous pouvez vous connecter et vous attacher à la session d'écran en cours.

Tutoriel: http://www.rackaid.com/blog/linux-screen-tutorial-and-how-to/

— Tobias
source

-2

Essayez d'exécuter votre nohup avec la redirection STDOUT et STDERR vers null:

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

— boris quiroz
source

1

Vous redirigez uniquement stderr vers stdout, ce qui ne change rien au fonctionnement de nohup (il redirige les deux vers nohup.out).

— Gilles 'SO- arrête d'être méchant'

1

-1, je pense que vous vouliez dire nohup java -jar project.jar 2>/dev/null &mais vous ne savez évidemment pas ce que vous faites. Encore mieux, nourrissez-vous aussi stdin /dev/null.

— PlasmaPower

@PlasmaPower vous avez ici votre +1. Bonne journée :)

— boris quiroz