Discussion :

[fabszn]

Hello,

Voila je suis sous un environnement suze Enterprise 9.
J'ai installé un serveur Websphere.

J'ai écrit un script shell permettant de faire certain traitement sur le serveur (arrêt, demarrage, sauvegarde BDD, sauvegarde log,etc..)

Le problème vient essentiellement de l'arret et du redemarrage du serveur.
Lorsque j'execute se script directement sur une ligne de commande tout se passe bien, le serveur redemarre correctement.

Par contre lorsque le redemarrage s"effectue par l'intermediaire de crontab (qui utilise mon script) le serveur ne redemarre pas correctement et celui ci devient inexploitable.

Pour palier à ce probleme j'avais trouvé la solution de lancer mes commandes en les prefixant de

su - root -c "ma_commande"

.

En utilisant cette astuce cela fonctionne impeccablement!

Maintenant mon admin systeme est passé par là et à cru bon de supprimer ce préfix ce qui me fait revenir en arriere.

J'aurais aimer comprendre pour le fait de rajouter ce prefix fait que cela fonctionne.

Je vous remercie par avance pour votre aide!

[ggnore]

causes possibles:

1. Tous les utilisateurs ne sont pas abilités à faire un shutdown.
2. Les variables d'envrionnement (dont le $path) de l'utilisateur de la crontab ne sont pas toutes présentes. Il faut indiquer le chemin absolu pour chaque commande.
3. Y en a sûrement d'autres.


Pourquoi est ce que tu dois redémarrer le serveur ? parceque tu changes de kernel tous les jours ? ou de hostname ?

[fabszn]

Hello,

Merci pour ta reponse!

Je me suis mal exprimé .. quand je parle de serveur je voulais dire le serveur Websphere (Websphere Portal Server pour etre plus precis).

C'est juste un redemarrage logiciel de l'application Websphere.

J'utilise le root pour executer la crontab. voila la ligne qui s'execute

Code :

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

1
2
 
30 03 * * *    root /applis/scripts/nightScript/globalBackup.sh 2> /usr/fab/backupLogGlobal.log

Merci d'avance pour une éventuelle aide prochaine

[MarcG]

Comme l'evoque ggnore, c'est un problème d'environnement :
la crontab ne "charge" pas l'environnement de l'utilisateur, elle ne passe pas par les sequences executer lors du login (/etc/profile, puis, $HOME/bash_profile), l'environnement de la crontab est trés "lite". le faite de faire un su - root (le - surtout ), provoque le chargement de l'environnement user (ici root) comme un login .

Recherchees élémebnt d'environnement manquant et ajoute les dans ton script. le moyen le plus simple :
ajoutet dans ton script lancé par la crontab la commande :

Code :

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

1
2
 
env >> /tmp/mon_fichier_de_traces_cron.log

puis de relancer (aprés obtention du resultat), le script manuellement en modifiant le fichier de log
ensuite tu n'as plus que a comparer les 2 fichiers et determiné les variables manquante utile.

[fabszn]

Comme l'evoque ggnore, c'est un problème d'environnement :
la crontab ne "charge" pas l'environnement de l'utilisateur, elle ne passe pas par les sequences executer lors du login (/etc/profile, puis, $HOME/bash_profile), l'environnement de la crontab est trés "lite". le faite de faire un su - root (le - surtout ), provoque le chargement de l'environnement user (ici root) comme un login .

Recherchees élémebnt d'environnement manquant et ajoute les dans ton script. le moyen le plus simple :
ajoutet dans ton script lancé par la crontab la commande :

Code :

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

1
2
 
env >> /tmp/mon_fichier_de_traces_cron.log

puis de relancer (aprés obtention du resultat), le script manuellement en modifiant le fichier de log
ensuite tu n'as plus que a comparer les 2 fichiers et determiné les variables manquante utile.

Merci beaucoup pour cette reponse.. en fait en cherchant j'avais trouvé cette voie là...

Effectivement le probleme venait tout simplement de là!
Je suis newbie (un peut avancé sous Unix/Linux) j'apprend tous les jours en étant confronté aux différents problèmes.

En tout cas encore merci!!