L'exécution de script bash n'est pas de retour à la borne lors de l'utilisation de l'esperluette (&) pour exécuter un sous-processus en arrière-plan

J'ai un script (permet de l'appeler parent.sh) cela fait 2 appels pour un second script (child.sh) qui exécute un processus java. L'child.sh les scripts sont exécutés en arrière-plan en plaçant un & à la fin de la ligne parent.sh. Cependant, lorsque je lance parent.sh, j'ai besoin d'appuyer sur Ctrl+C pour revenir à l'écran du terminal. Quelle est la raison? Est-il quelque chose à voir avec le fait que l'child.sh des processus sont en cours d'exécution en vertu de la parent.sh processus. De sorte que le parent.sh ne pas mourir jusqu'à ce que l'enfant?

parent.sh

#!/bin/bash
child.sh param1a param2a &
child.sh param1b param2b &
exit 0

child.sh

#!/bin/bash
java com.test.Main 
echo "Main Process Stopped" | mail -s "WARNING-Main Process is down." user@email.com

Comme vous pouvez le voir, je ne veux pas courir le processus java dans le fond, car je veux envoyer un mail lorsque le processus meurt. Faire comme ci-dessus fonctionne très bien à partir d'un point de vue fonctionnel, mais je voudrais savoir comment je peux obtenir un retour à la borne après l'exécution de parent.sh.

Est-il nécessaire de ctrl-c ou n'appuyer sur la touche enter vous obtenez une invite de trop? Ce n' ps dire est en cours d'exécution au moment où vous appuyez sur ctrl-c?
Est le programme java s'attend à aucun d'entrée? Il aide si vous la changez pour java com.test.Main < /dev/null?
Ajouter un > /dev/null à la fin de la ligne avec mail. mail dans le cas contraire, essayez de démarrer son mode interactif.
si on prend l'entrée, comment vous attendez-vous à un fond d'elle-même? Il a nécessairement un terminal de contrôle de la poignée.
@CharlesDuffy dit, si le script prend en entrée comment peut-il être exécuté en arrière-plan? Où est-ce qu'il va obtenir son entrée? Vous n'êtes pas fournir tout (et vous le tuez avec ctrl-c, j'imagine que vous devez le frapper deux fois en fait).

OriginalL'auteur theGuardian | 2015-02-02

  1. 6

    Ce que j'ai fait était de faire changer parent.sh à la suite de

    #!/bin/bash
child.sh param1a param2a > startup.log &
child.sh param1b param2b > startup2.log &
exit 0

    Je ne serais pas venu à cette solution sans de vos suggestions et de l'analyse de la cause racine du problème. Merci!

    Et toutes mes excuses pour mes inexactes commentaire. (Il n'y a pas d'entrée, j'ai répondu de mémoire et je me suis souvenu de façon incorrecte.)

    J'ai eu le même problème et cela a fonctionné pour moi. Remplacement de & avec > /dev/null & fonctionne également si vous n'avez pas besoin de recueillir la sortie.
    La redirection de stdout résolu pour moi aussi.

    OriginalL'auteur theGuardian

  2. 3

    Le lien suivant à partir de la Projet De Documentation Linuxsuggère d'ajouter un wait après votre mail commande en child.sh:

    http://tldp.org/LDP/abs/html/x9644.html

    Résumé du document ci-dessus

    Within a script, running a command in the background with an ampersand (&)
may cause the script to hang until ENTER is hit. This seems to occur with
commands that write to stdout. It can be a major annoyance.

....
....

As Walter Brameld IV explains it:

As far as I can tell, such scripts don't actually hang. It just
seems that they do because the background command writes text to
the console after the prompt. The user gets the impression that
the prompt was never displayed. Here's the sequence of events:

1. Script launches background command.
2. Script exits.
3. Shell displays the prompt.
4. Background command continues running and writing text to the
   console.
5. Background command finishes.
6. User doesn't see a prompt at the bottom of the output, thinks script
   is hanging.

    Si vous modifiez child.sh ressembler à ce qui suit, vous ne devriez pas rencontrer cette gêne:

    #!/bin/bash
java com.test.Main
echo "Main Process Stopped" | mail -s "WARNING-Main Process is down." user@gmail.com
wait

    Ou comme @SebastianStigler unis dans un commentaire à votre question ci-dessus:

    Add a > /dev/null at the end of the line with mail. mail will otherwise try to start its interactive mode.

    Ce sera la cause de la commande mail pour écrire à /dev/null plutôt que stdout qui devrait également arrêter cette gêne.

    Espère que cette aide

    OriginalL'auteur ptierno

  3. 1

    Le processus était encore relié au terminal de contrôle parce que STDOUT besoins de quelque part pour aller. Vous avez résolu ce problème par la redirection vers un fichier ( > démarrage.journal ).

    Si vous n'êtes pas intéressé par la sortie, jetez STDOUT complètement ( >/dev/null ).

    Si vous n'êtes pas intéressé dans les erreurs, soit, de rejeter les deux ( &>/dev/null ).

    Si vous souhaitez que le processus pour continuer à fonctionner même après la déconnexion de votre terminal, vous pouvez utiliser nohup — qui effectivement se déconnecte de ce que vous faites et les laisse tranquillement s'exécuter en arrière-plan jusqu'à ce que vous redémarrez votre machine (ou tuer).

    nohup child.sh param1a param2a &>/dev/null &

    OriginalL'auteur Tim