Discussion :

[CetTer]

Bonjour à tous,

J'ai un problème qui concerne à la fois les tâches d'arrière-plan et mysql (sous Ubuntu Hardy).

Il s'agit d'un gros fichiers Zip que je voudrais dézipper et importer dans une base de données mysql.
Comme je ne dispose que d'une connexion SSH sur le serveur et qu'il s'agit d'une grosse base de données, je souhaiterais que le processus d'importation se déroule en arrière-plan, afin que son exécution continue une fois sorti de l'accès SSH.

J'ai donc encodé:

#sudo gzip -dc monfichier.zip | mysql -u myUser --password='monMotdePasse' maBaseDeDonnées &

Cependant le processus s'arrête dès que je ferme la console SSH (alors que la même commande en tâche d'avant-plan s'exécute normalement et charge bien la base de données).


Je suis un peu calé. J'aivraiment besoin de ce type de commande car à terme je devrai importer des bases de données volumineuses (>100 Gigas).
Pourriez-vous m'indiquer si le suffixe "&" est adéquat pour ce genre de tâche, et si ce n'est pas le cas, quelles solutions alternatives pourraient exister?

[alband85]

Si ça ne fonctionne pas, tu peux essayer de lancer ta commande, puis de faire un ^Z (ctrl + z). Ca met ton processus en "pause".
Tape alors bg pour qu'il se poursuive en arrière-plan.

Là, tu peux te déconnecter, ton processus tourne toujours.

[CetTer]

Merci pour la réponse mais cela n'a pas marché.

Le problème vient peut-être de ce que seule la seconde partie du pipe (la connexion à mysql) est reconnue comme tâche d'arrière plan, et pas la première partie avec l'envoi du dézippage sur la sortie standard (elle s'exécute, mais en avant-plan).

[CetTer]

Hello,

Pas de résolution en vue, mais merci à alband85 pour sa réponse qui m'a permis de mieux diagnostiquer le problème.

Je viens de faire un test en dézippant un fichier est en tapant juste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql -u myUser --password='monMotdePasse' maBaseDeDonnées < monFichierDezippé & 

...et ça marche même quand je ferme la console!

Donc le problème s'est déplacé: il ne vient pas de la syntaxe à utliser en shell, apparemment il est tout simplement impossible de lier ensemble deux tâches d'arrière-plan dans un même pipe.
Dans mon exemple en haut, je redirigeais la sortie standard d'une tâche d'avant-plan vers l'entrée d'une tâche d'arrière plan...sans le savoir, en croyant qu'il s'agissait de deux tâches en background.


J'ai essayé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#sudo gzip -dc monfichier.zip & | mysql -u myUser --password='monMotdePasse' maBaseDeDonnées &

mais ça marche pas.

Ce serait pourtant intéressant, car quand je dois dézipper une base de 100 Gigas, j'ai pour le moment besoin d'au moins 220 Giga d'espace disque disponible: le fichier dézippé + la base de données à charger, avec ses index et les fichiers de tri de myisam + le fichier zippé.
Pouvoir faire du piping entre deux processus d'arrière plan me permettrait d'économiser la moitié de l'espace disque.

La seule solution est sans doute la commande "at"

[N_BaH]

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(sudo gzip -dc monfichier.zip | mysql -u myUser --password='monMotdePasse' maBaseDeDonnées) &

...
?
les parenthèses devraient faire en sorte que le shell ne perçoive qu'un seul process.

Mais, effectivement, pour rendre une commande insensible à la déconnexion d'un terminal, tu devrais inscrire tes commandes dans un script (d'auant plus que cela semble un code que tu veux éxécuter plus d'une fois, non?), puis lancer le script avec nohup

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nohup mon_script.sh

[gangsoleil]

Bonjour,

Le fait de postfixer une commande par le symbole & l'envoie en arriere plan du shell. C'est a dire que la main est rendue a l'utilisateur, mais que le shell est toujours parent de la commande.

En unix, lorsqu'un processus est tué, tous ses fils le sont egalement. C'est pourquoi lorsque tu quittes le shell ta commande s'arrete.

La seule solution consiste a rendre le processus lance demon : son pere n'est plus le processus lanceur, mais le processus de pid 1 - en gros l'OS lui-meme.

Pour ce faire, la solution la plus simple consiste a utiliser nohup :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nohup ma_commande_qui_va_bien &

Les autres solutions consistent a forker, puis a preciser aux fils de se rattacher au processus 1, puis de tuer le pere. Cela se fait principalement avec de langages compiles.

[jmelyn]

Bonjour,

Avec Bash, on peut aussi utiliser la commande disown:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
ma_commande_qui_dure_trop_longtemps &
jobs
[1]+  Running                 ma_commande_qui_dure_trop_longtemps &
disown %1