Discussion :

[schnourf]

Bonjour,

j'ai le probleme suivant, je vient d'arriver dans une societe et je doit corriger les erreurs dans les jobs qui sont definis dans le fichier crontab.

J'ai un probleme, dans mes logs, il y a une fichiers batchsql2.sh qui est lancé mais pas trouvé

/nacht_jobs/batchsql2.sh: /nacht_jobs/batchsql2.sh: cannot open

Le fichier n'existe pas et je le l'ai pas trouvé non plus.
D'ou ma question comment est ce que je peux faire pour savoir d'ou est lancé ce fichier.
Je me suis aussi demandé si je peux le creer et y mettre une ligne de commande pour recuperer le nom du fichier ou du processus qui le lance.

Est-ce que c'est possible ?

Merci de votre reponse.

[getupa]

J'ai bien une idée, mais c'est rustique ...
Tu crée le fichier, et tu lui fait spooller dans un fichier un ps -aef.
Ensuite tu fait un petit grep dans ton fichier de ton process. Tu récupère le proccess père et tu refait un grep pour trouver quel est le processus qui l'a lancé.

C'est pas très automatisé, mais ca devrais marcher.

[ggnore]

L'endroit d'où est lancé le script n'a pas d'importance. Le chemin du script en a une.

Il existe plusieurs solutions pour trouver un fichier.

tu peux faire en root :

Code :

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

updatedb

puis

Code :

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

locate nomdufichier

l'updatedb met à jour une base de données où est enregistrée l'emplacement de chaque fichier, c'est un processus plutôt long. Cependant, une fois que cela est fait, le locate est très rapide. Malheureusement, à chaque fois que de nouveaux fichiers apparaissent cette base de données n'est pas mise à jour.

Tu peux aussi utiliser find qui lui scrute effectivement le disque dur à chaque utilisation.

par exemple :

Code :

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

find -type f -name "batchsql2.sh" /

ou

Code :

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

find -type f -name "*.sh" /

Je ne suis pas sûr de ta demande

[Katyucha]

Le rustique ne tue pas !

En effet, ce n'est pas une mauvaise idée du tout !
vi /nacht_jobs/batchsql2.sh

Code :

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

1
2
#!/bin/sh
ps -aef > /tmp/mes_logs

Ainsi tu aura l'état de ton système au lancement.

[ggnore]

ok, j'ai mieux compris maintenant ...

Personnellement, je me placerai dans /etc et je lancerai un bon gros grep récursif.
C'est bourrin... J'avoue.

Le problème avec la méthode du ps -aef, c'est qu'il va falloir attendre que le script soit lancé automatiquement et on n'a aucune idée de la date de lancement.

[schnourf]

Je pense que la date de lancement se situe au alentour de 14h.

en effet mon fichier log ne contient que cette ligne et il date de 14h08.

Meci je vais une fois essayer de creer le fichier facon rustique et voir aussi avec locate si ca marche.

[ggnore]

Je pense que la date de lancement se situe au alentour de 14h.

en effet mon fichier log ne contient que cette ligne et il date de 14h08.

Meci je vais une fois essayer de creer le fichier facon rustique et voir aussi avec locate si ca marche.

Tente un :

Code :

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

1
2
cd /
grep -R batchsql2.sh *

Tu auras sûrement une liste un petit peu énorme en sortie... Les binaires vont sûrement contenir cette chaîne

[schnourf]

Je venait juste d'y penser.

J'ai lancer

Code :

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

 find / -type f -print | xargs grep batchsql2.sh > /nacht_jobs/log/test.log

Et je suis entrain d'attendre que ca se termine

[Invité]

et juste comme ca... Il à ete lancé depuis le cron ce script non ??

Code :

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

crontab -l | grep batchsql2.sh

ca marcherait ou j'ai pas compris le probleme ?

[schnourf]

J'ai trouvé ou etait lancé le fichier,

c dans /var/spool/cron/crontabs/oracle

J'ai regardé ce que contenait ce fichier, il contient a peu de chose pres les meme lignes de commande que dans un autre fichier crontab.

quand c'est dans 2 fichiers differents est-ce que les lignes qui sont dans les 2 fichiers seront interpreété 2 fois, d'ou le risque de voir 2 fois la meme procedure se lancer) ?

[MarcG]

tout depend ou est l autre fichier ... s'il se trouve aussi dans
/var/spool/cron/crontabs
le risque existe grandement :
ce repertoire contient un fichier par user (dans ton exemple c'est le user oracle), qui contienne leurs crontab
pour les modifier la procedure normal est :
su - user
puis crontab -e pour editer

[schnourf]

Merci de la reponse,

Et oui l'autre crontab se trouve dans le meme repertoire, c peut etre pour ca que ils ont des problemes de rapidité.

j'ai vu que ct le crontab de oracle, je viens de le modifier.
C'est peut etre du a une erreur de manip de quelqu'un qui a modifier celui de oracle et non celui de root.
En tout cas merci pour votre aide.