Comment empêcher un programme de mourir quand sa session ssh est morte?

J'ai une très vieille application de console que je veux faire un peu plus résiliente. Le programme est utilisé de cette façon:

l'user utilise un émulateur de terminal personnalisé pour se connecter à une machine distante via ssh
l'user démarre un script shell
le script shell peut démarrer un process de database de progression de longue durée.

De toute évidence, les users perdent parfois la connection ssh à la machine. Dans ce cas, la session ssh est terminée, le script shell exécuté à l'intérieur est terminé et le process de database de progression est terminé. Dans un cas sur mille, cela entraîne la corruption de la database, alors j'aimerais l'empêcher de se produire.

Ce que j'ai essayé jusqu'à présent:

démarrer une session screen ou tmux avant de lancer le script shell – cela ne fonctionne pas car l'application a besoin que la variable TERM soit définie sur at386 (et contourne complètement termcap / terminfo … euh …)
nohup / désapprouver le process de progression – cela ne fonctionne pas parce que le script shell et le process de progression sont continuellement en communication les uns avec les autres de manière obscure, il semble

Avez-vous d'autres idées pour vous assurer que le process de progression ne se termine pas lorsque la session ssh est supprimée?

Ajoutez le term at386 à votre .screenrc afin de replace TERM. Si cela ne vous aide pas, essayez dtach au lieu de Screen (qui ne fait pas d'émulation de terminal elle-même).

Dans de nombreux cas, la solution la plus simple consiste à utiliser nohup et à mettre le process non interactif en arrière-plan en utilisant & et redirect la sortie standard et l'erreur standard vers les files.

En d'autres termes, vous cherchez quelque chose comme l'écran, mais qui transmet les séquences de contrôle au terminal plutôt que de faire sa propre traduction? Essayez dtach . Il fournit la même fonction de détachement de terminal que l'écran, mais sans les multiples windows ou l'émulation de terminal.

Essayez peut-être un bureau X distant via vnc ou nx. Vous pouvez tunneler vnc sur ssh pour la security ou utiliser nx qui fonctionne via ssh par défaut (et est beaucoup plus rapide). L'application peut alors s'exécuter dans un Terminal sur le bureau X et si la connection est perdue, le bureau continuera à fonctionner, permettant la reconnection à tout moment. Ma preference n'est pas NX Machine qui est gratuite pour deux users simultanés et s'installe très facilement.

Une alternative, si elle est disponible, consiste à utiliser une console distante via ALOM, ILOM, DRAC, IP-kvm ou IP-serial console, etc. De cette façon l'application s'exécuterait sur la console et ne pourrait pas être interrompue par un échec de connection .