2010-02-25 13 views
0

J'ai un travail cron mis en place qui va démarrer mon script.Cron kill engendré des processus

L'intention de ce script est de supprimer un processus en cours d'exécution et de démarrer une nouvelle version de ce processus (CHECKDB). CHECKDB doit être en cours d'exécution tout le temps, nous avons donc un script start_checkdb qui est fondamentalement une boucle infinie qui exécute CHECKDB; s'il tombe en panne, il reste dans la boucle, le redémarre. [Oui, je me rends compte que ce n'est pas la meilleure pratique, mais ce n'est pas ce dont il s'agit]

Mon script sera appelé par cron sans problème, puis il va tuer CHECKDB sans problème. Pour autant que je sache, le script enfant est appelé et redémarre CHECKDB, mais chaque fois que je vérifie ps après l'exécution de cron, le processus ne fonctionne pas. Si je lance le script à la main sur la ligne de commande, sous n'importe quel shell, cela ne pose aucun problème: tue CHECKDB et start_checkdb, démarre start_checkdb qui démarre CHECKDB.

Pourtant, pour une raison quelconque, lorsque cron le fait, le processus ne tourne jamais après. Il tue le live, et soit ne le démarre pas, soit il le démarre et le tue.

Est-il possible que lorsque cron arrive à la fin du processus parent, il va tuer les processus enfant qui ont été appelés?

Je ne sais pas si cela fait une différence, mais est sur Solaris 8.

Répondre

0

Vous pouvez regarder en utilisant nohup dans votre script Cron, lors du lancement checkdb. Une chose comme 'nohup command &' serait un moyen normal de lancer quelque chose que vous vouliez vivre au-delà du processus de lancement.

+0

Eh bien, j'ai essayé de le faire, mais cela n'a pas fonctionné. Il a terminé le processus lorsque cron l'a exécuté et ne s'est pas terminé lors de l'exécution manuelle. C'est très frustrant :( –

+0

Nohup ne fait que masquer le signal de raccrochage, qui empêche un programme que vous avez lancé à partir d'un terminal (terminal) de sortir lorsque vous vous déconnectez. – Kenster

0

Pourriez-vous préciser votre description de l'arrangement? Il semble que, dans des circonstances normales, start_checkdb et CHECKDB sont en cours d'exécution. Le travail cron est censé tuer CHECKDB, et la copie déjà en cours de start_checkdb est censée le redémarrer? Ou le travail cron tue-t-il les deux processus, puis redémarre start_checkdb? Après l'exécution du travail cron, quel processus est manquant - CHECKDB, start_checkdb ou les deux?

Cela dit, les raisons les plus communes pour un processus de travailler à partir de la ligne de commande mais ne parviennent de Cron sont:

  • Dépendance sur le chemin de commande correct (ou une autre variable d'environnement)
  • Dépendance en cours d'exécution à partir du répertoire correct
  • Dépend de l'exécution à partir d'un tty.