Quelle est la date de la dernière exécution d'un script ?

Version imprimable

28/01/2024, 14h07
Liamm

Quelle est la date de la dernière exécution d'un script ?

Bonjour,

La question du titre, a-t-elle une réponse ?

J'ai essayé d'obtenir une réponse avec la commande ls avec ce ...

Code:

~/projets/github_BEBSHELL$ ls --time=use --sort=time -l ./*/p*.sh

J'obtiens :

Citation:

-rwxr--r-- 1 simone simone 14851 janv. 28 12:31 ./BEB_SHELL_TC_PEA/p00.sh
-rwxrw-r-- 1 simone simone 3217 janv. 28 12:31 ./BEB_SHELL_TC_PEA/ps0allplus.sh
-rwxrw-r-- 1 simone simone 6265 janv. 28 12:31 ./BEB_SHELL_TC_PEA/ps0all.sh
-rwxr--r-- 1 simone simone 3228 janv. 28 12:06 ./BEB_SHELL_XX_NEW/ps0new.sh
-rwxrw-r-- 1 simone simone 5960 janv. 28 12:06 ./BEB_SHELL_XX_NEW/p8a.sh
-rwxr--r-- 1 simone simone 2004 janv. 28 12:06 ./BEB_SHELL_XX_NEW/p2.sh
-rwxr--r-- 1 simone simone 8511 janv. 28 12:06 ./BEB_SHELL_XX_NEW/p3.sh
-rwxr--r-- 1 simone simone 5273 janv. 28 12:06 ./BEB_SHELL_XX_NEW/p4.sh
-rwxr--r-- 1 simone simone 4237 janv. 28 12:06 ./BEB_SHELL_XX_NEW/p6.sh
-rwxr--r-- 1 simone simone 4657 janv. 28 12:06 ./BEB_SHELL_XX_NEW/p7.sh
. . .

J'obtiens une liste ordonnée de scripts, du plus récent au plus vieux, apparemment par date d'accès, mais pas par date d'exécution comme j'aurais voulu.
Y a-t-il une solution?
28/01/2024, 14h16
unanonyme

Bonjour,

HISTTIMEFORMAT='%d/%m/%y %T ' history?

Bonne journée.
28/01/2024, 14h25
Sve@r
Bonjour

Citation:

Envoyé par Liamm

La question du titre, a-t-elle une réponse ?

Non.

Citation:

Envoyé par Liamm

Y a-t-il une solution?

Non. Un fichier unix possède 3 dates
- date de dernier accès (la atime). Cette date est mise à jour chaque fois qu'on accède au fichier
- date de dernière mise à jour (mtime). Cette date est mise à jour chaque fois que le fichier est modifié
- date de création ou de modification d'inode (ctime). Cette date est mise à jour chaque fois que l'inode associé au fichier change
Nulle part il n'y a de "date de dernière exécution" (surtout que tout fichier n'est pas forcément script). En toute logique, pour que le script soit exécuté il faut qu'il soit lu donc accédé donc la "atime" est ce qui s'en rapprochera le plus. Toutefois cette date est tellement mise à jour dans tant de cas qu'elle ne veut plus rien dire (comme un chien qui aboie tout le temps ne sert alors à rien pour prévenir d'une présence malvenue) qu'il existe une option pour carrément ne pas la mettre à jour (option "noatime" à mettre au montage du filesystem)

Peut-être te demander la raison de cette demande. Si c'est pour une question de sécurité il existe des outils de log que l'on peut mettre en place (accounting). Ces outils logguent les actions de tous et donc les scripts appelés...
28/01/2024, 14h38
Liamm

Merci unanonyme, je ne connaissais pas cette possibilité avec la commande history.

Dans mon cas, cette solution ne va pas m'aider beaucoup.
En effet, mes scripts sont souvent composés de (sous-)scripts, qui eux-mêmes peuvent contenir d'autres scripts ; et les appels à ces scripts ne sont pas systématiques.
28/01/2024, 14h44
Liamm

@Sve@r
La raison est de repérer, sur un projet donné, en passant toutes les "chaines" hebdomadaires, annuelles et à la demande, les scripts qui ne sont plus utilisés dans ce projet, en vue de faire du ménage en les supprimant.
28/01/2024, 14h51
Sve@r

1 pièce(s) jointe(s)

Citation:

Envoyé par Liamm

La raison est de repérer, sur un projet donné, en passant toutes les "chaines" hebdomadaires, annuelles et à la demande, les scripts qui ne sont plus utilisés dans ce projet, en vue de faire du ménage en les supprimant.

Mouais. Donc le projet a été monté à la "va comme je te pousse" avec des scripts placés on ne sait trop pourquoi par on ne sait trop qui et maintenant le but est de les retrouver. :roll:

Solution 1: supprimer tous les scripts et attendre de voir les messages d'erreur du projet quand il appelle un script qui n'existe plus
Solution 2: placer des logs dans les scripts et voir les logs qui sortent de ceux qui ne sortent pas
Solution 3 (peut-être la plus sage): refaire le projet dans les règles de l'art plutôt que de jouer à "bricolo et bricolette"...

Pièce jointe 649867
28/01/2024, 16h31
Liamm
@ Sve@r

Citation:

Mouais. Donc le projet a été monté à la "va comme je te pousse" avec des scripts placés on ne sait trop pourquoi par on ne sait trop qui et maintenant le but est de les retrouver.

1/dont :

Citation:

avec des scripts placés on ne sait trop pourquoi

Tous les scripts ont une utilité dans la chronologie du projet; et on sait pourquoi ils ont été créés à un moment donné.

2/dont :

Citation:

par on ne sait trop qui

L'auteur de chaque script, ainsi que les modifications successives, sont notifiées dans chaque script.

3/dont :

Citation:

et maintenant le but est de les retrouver

Les retrouver, même si sur 6 environnements différents on sait faire par ce . . .

Code:

@HAL42:~/projets/github_BEBSHELL$ find -iname "p*.sh"

Citation:

Solution 3 (peut-être la plus sage): refaire le projet dans les règles de l'art plutôt que de jouer à "bricolo et bricolette"...

Je ne parlerai pas des deux premières solutions comiques.
Tout est normé dans le projet :
- Le nom des programmes script
- Le nom des tables
- Le nom des fichiers
- . . .
D'où la question : C'est quoi, pour vous, les règles de l'art ?
28/01/2024, 16h37
Sve@r
Citation:
Envoyé par Liamm

Je ne parlerai pas des deux premières solutions comiques.

Tout est normé dans le projet :

Le nom des programmes script
Le nom des tables
Le nom des fichiers
. . .

D'où la question : C'est quoi, pour vous, les règles de l'art ?
La première solution était comique certes. La seconde est plus sérieuse (un log est une trace qui montre ce qui est appelé et quand).
Pour répondre à votre question, les règles de l'art seraient de ne pas écrire de projet dans lequel on en arrive à aller sur un forum pour demander comment aider à trouver les scripts inutiles du projet mais ce serait une arabesque latérale (surtout que visiblement tout a été fait correctement mais si vous ne le dites pas on ne peut pas le deviner). Donc en fait la vraie question, c'est puisque tout est noté, normé, contrôlé, tracé, et que visiblement les scripts présents semblent avoir leur utilité, que de toute façon leurs auteurs sont identifiés et peuvent être questionnés ; alors pourquoi avoir besoin de dater l'exécution des scripts ?
Sommes-nous dans le cas d'un problème XY ???
28/01/2024, 16h46
Liamm

Avec le temps, le projet évolue, et je pense que certains scripts, aujourd'hui, ne sont plus utilisés.
D'où l'idée de les repérer par une commande via la dernière date d'exécution.
En utilisant peut-être votre remarque suivante :

Citation:

il existe une option pour carrément ne pas la mettre à jour (option "noatime" à mettre au montage du filesystem)
28/01/2024, 16h52
Sve@r

Citation:

Envoyé par Liamm

Avec le temps, le projet évolue, et je pense que certains scripts, aujourd'hui, ne sont plus utilisés.

En théorie (théorie qui parle de ces "règles de l'art") l'évolution d'un projet est aussi suivie. Si un script devient inutile, son auteur doit s'en rendre compte et le supprimer. Et pour les projets sérieux on va aller jusqu'à suivre les versions (revenir en arrière, créer des branches parallèles, etc). Il existe différents outils pour ça (dont git, créé par Linus Thorvald).

Citation:

Envoyé par Liamm

En utilisant peut-être votre remarque suivante :

Non, cette remarque était un bémol. On peut tenter le "atime" pour regarder quand un script (ie un fichier) a été accédé MAIS si l'admin a positionné l'option "noatime" (comme je le fais sur mes Linux) alors cette possibilité disparait car le "atime" n'est plus mis à jour.
28/01/2024, 17h03
N_BaH

dresser une liste des scripts présents, et en chercher l'appel dans les scripts ?

Code:

grep -f <(for script in /chemin/projet/*.sh; do test -f "$script" -a -x "$script" && echo "$script"; done) /chemin/projets/*.sh

:question::question::question:
28/01/2024, 17h23
unanonyme

La solution précédente ne gère pas les conditionnalités d'exécution du script en fonction de la donnée d'entrée.
AMHA, ce sera le souci avec cette dernière.
28/01/2024, 18h53
disedorgue

Sinon, reste à activer l'audit sur le system pour qu'il trace toutes les actions qui se passe...
28/01/2024, 18h54
Liamm

Je vais encore réfléchir à la question posée (en titre), et reviendrai vers vous ultérieurement pour conclure ce post.
À moins qu'une bonne idée surgisse avant !
28/01/2024, 23h51
papajoker

bonjour

Citation:

Envoyé par Liamm

Je ne parlerai pas des deux premières solutions comiques.
Tout est normé dans le projet :

En quoi utiliser des logs est comique ? ta réponse me semble comique puisque tu dis que tout est normé.

Il est facile d'ajouter une ligne dans chaque script, et comme ton projet est "normé", il doit même être très facile de créer un script pour ajouter cette ligne :lol:

Une ligne du type :

Code:

if VAR_ENV_LOG_MON_PROJET alors ecrire dans journald monprojet message = fichier_source[+parametres]

Note: puisque ton projet est bien "normé", tu réutilises le système de log de ton projet, donc encore plus simple :mrgreen:

Citation:

les scripts qui ne sont plus utilisés dans ce projet, en vue de faire du ménage en les supprimant.

Donc la liste des fichiers dans le projet moins ceux dans les logs... trop difficile :oops:

-------------

De plus, ce genre de log peut être utile pour le développement comme le dépannage d'un utilisateur ;) redondant avec l'existant ?
06/02/2024, 17h56
Escapetiger

Citation:

Envoyé par Liamm

D'où la question : C'est quoi, pour vous, les règles de l'art ?

Toutes les suggestions précédentes de mes collègues sont pertinentes (avec parfois un second degré humoristique quand il s'agit de supprimer des scripts, mais c'est l'idée qui est bonne) et surtout permettent de mieux déterminer le contexte de la problématique associé à tes réponses également éclairantes.

Ce type de projet apparaît régulièrement chez les clients du fait - notamment - de la succession de sous-traitants (SSII/ESN) passés chez eux... Parfois la maîtrise interne s'évapore au fil du temps.

Donc, les applications sont normées, les scripts aussi, bonne nouvelle !

Régles de l'art (issues de ~40 ans de systèmes/productions/exploitations/études/projets ... du côté Ops de DevOps)

1)
On ne touche pas à l'existant

2)
Les solutions de type audit/accounting comme préconisées plus haut sont à privilégier, leur mise en oeuvre générant la plupart du temps de très gros volumes de données qu'il faut trier par projet/application ensuite entre autres.

3)
Corollaire du 2, ça tombe bien; chez HP-UX ((Hewlett Packard UniX), ils ont édité par le passé un outil adéquat qui s'appelle Glances :

Citation:

glance -d : monitoring de disque

glance -c: monitoring CPU

glance -a : Average cpu load par unité de calcul

glance -v : monitoring de vos Volume group (I/O)

glance -u : monitoring de vos disques

glance -l : monitoring de vos interfaces réseaux

glance -g : monitoring de vos process

glance -A : Monitoring par application

Source: Monitorer HP UX avec l’outil glance | Journal d'un Admin Linux (30 Mai 2013 !) *

que j'ai déjà utilisé avec succès pour certains clients (logs dédiées par application, rapports de type .csv, etc.)

*
Et merci à eux deux:

xhark says:
8 janvier 2014 à 20 h 54 min
Cela me fait penser au Glances de Nicolargo http://nicolargo.github.io/glances/ (https://nicolargo.github.io/glances/) **

** An Eye on your system

Glances is a cross-platform system monitoring tool written in Python.

ps
Je n'ai pas testé cette version