Trouver ou un fichier est lancé

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é

Citation:

---

/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.

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.

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:

---

updatedb

---

puis

Code:

---

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:

---

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

---

ou

Code:

---

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

---

Je ne suis pas sûr de ta demande :?

Le rustique ne tue pas !

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

Code:

---

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

---

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

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.

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.

Citation:

---

Envoyé par 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.

---

Tente un :

Code:

---

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 :(

Je venait juste d'y penser.

J'ai lancer

Code:

---

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

---

Et je suis entrain d'attendre que ca se termine

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

Code:

---

crontab -l | grep batchsql2.sh

---

ca marcherait ou j'ai pas compris le probleme ?

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) ?

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

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.