script : savoir si c'est la première exécution depuis le dernier démarrage

Le
Francois Lafont
Bonjour à tous,

J'ai un script sur une Debian Squeeze qui s'exécute de temps en temps de
manière automatique (en fait à chaque fois que la fenêtre de connexion
apparaît, c'est-à-dire à chaque démarrage mais aussi après chaque
fermeture de session). L'exécution se fait via le compte root.

Je voudrais affiner le script pour qu'il se comporte légèrement
différemment suivant que l'exécution est la première depuis le dernier
démarrage ou non. Comment faire cela de manière fiable ?

J'avais pensé écrire un fichier « pipeau » dans /tmp, profitant du fait
que /tmp est vidé à chaque démarrage il me semble. Du coup, dans le
script, ça donnerait un truc dans le genre ça :

if [ -e /tmp/pipeau ]; then
# Alors ce n'est pas la première exécution
# depuis le dernier démarrage de la machine.
else
# Alors c'est la première exécution
# depuis le dernier démarrage de la machine.
# Du coup on crée le fichier.
touch /tmp/pipeau
fi

Mais je ne sais pas si c'est une bonne façon de faire :

1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?

2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors
qu'il n'y a pas eu encore redémarrage ?

3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?

Du coup, je me dis qu'on peut peut-être s'y prendre mieux que ça. :-)

Merci d'avance pour votre aide.

--
François Lafont
Vos réponses Page 2 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Luc.Habert.00__arjf
Le #24466131
Francois Lafont :

L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne
peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?



Non, contrairement à windows, linux ne permet pas vraiment ça. Par contre,
il permet de lui demander "crée moi ce fichier si il n'existe pas, et jette
moi sinon", ce que fait > lorsqu'on a fait un set -C.

Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour,
c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte
qu'il y ait « panique » ?



Je ne veux pas faire en sorte, mais c'est juste comme ça que ça se passe.

if : > blah; then ploum; else plim; fi

n'exécute ni ploum ni plim si la redirection échoue.

Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à
chaque redémarrage, je repars sur un répertoire vide.



Avec l'inconvénient que si le script a été appellé avant le montage, boum.

if ! mountpoint "$rep"; then
mount -t tmpfs -o size=1M tmpfs "$rep"
fi



Toujours une race-condition.
Nicolas George
Le #24466121
Luc Habert, dans le message
if : > blah; then ploum; else plim; fi
n'exécute ni ploum ni plim si la redirection échoue.



Mais on peut ramener au comportement habituel en mettant la redirection dans
un sous-shell avec des parenthèses.
Francois Lafont
Le #24466151
Le 10/05/2012 13:25, Luc Habert a écrit :

L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne
peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?



Non, contrairement à windows, linux ne permet pas vraiment ça.



Pas sûr d'avoir compris cette double négation. Le noyau ne permet pas
l'écriture simultanée sur un même fichier : c'est juste ou faux ? :-)

Par contre,
il permet de lui demander "crée moi ce fichier si il n'existe pas, et jette
moi sinon", ce que fait > lorsqu'on a fait un set -C.



Ok.

Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour,
c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte
qu'il y ait « panique » ?



Je ne veux pas faire en sorte, mais c'est juste comme ça que ça se passe.

if : > blah; then ploum; else plim; fi

n'exécute ni ploum ni plim si la redirection échoue.



Je ne constate pas cela sur mon bash :

--------------------------------------
$ if : > out; then echo Ok; else echo PB; fi
bash: out: Permission non accordée
PB
--------------------------------------

Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à
chaque redémarrage, je repars sur un répertoire vide.



Avec l'inconvénient que si le script a été appellé avant le montage, boum.



C'est le script qui fait le montage.

if ! mountpoint "$rep"; then
mount -t tmpfs -o size=1M tmpfs "$rep"
fi



Toujours une race-condition.



Ah, zut. :-)

Très honnêtement, la probabilité d'avoir une race-condition me semble
vraiment nulle et en plus le script ne fait pas grand chose de méchant.
Mes craintes portaient surtout sur /tmp et la « non maîtrise » de son
contenu ce qui est résolu, il me semble, avec un montage de type tmpfs.
Du coup, je suis quand même plutôt satisfait, même si je ne nie pas que
le problème de race-condition demeure.


--
François Lafont
Francois Lafont
Le #24466321
Le 10/05/2012 13:17, Marc Boyer a écrit :

Mon point de vue serait un peu différent: soit tu désires faire
un truc vraiment fiable, et il faut insérer ta commande dans la
liste des scripts exécutés au démarrage et à l'extinction de
ta machine,



Ah, je sais que ça serait le truc propre mais j'aimerais bien éviter et
faire un truc plus « artisanal ». :-)

soit tu veux rester en dehors,



Oui.

et de manière moins
précise, tu peux par exemple comparer la date de création de
ton fichier avec l'uptime de la machine.



Au delà de l'aspect conversion de date, mesure d'écart qui je verrai
plus tard, je ne vois pas trop ce que tu veux dire.

Avec l'uptime, j'ai la possibilité de connaître la date de démarrage du
système. Ok. Mais ensuite. Cette date, tu veux que je la « compare »
avec la date de dernière modif (et donc de création) du fichier, c'est
ça ? Ok. Mais alors qu'entends-tu par « comparer » ? Mesurer l'écart ?
Mais dans ce cas, comment fixer une règle de décision ? Quel seuil fixer ?


--
François Lafont
Sergio
Le #24466311
Le Thu, 10 May 2012 13:15:36 +0200, Francois Lafont a écrit :

1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?



Clairement non. Mon /tmp est plein de fichiers temporaires « anciens »
(antérieurs au dernier démarrage) ; leur effacement est configurable
(opensuse 11.2) en fonction de l'âge.



Ah, et bien j'apprends quelque chose car je pensais que /tmp était
toujours vidé à chaque redémarrage.



Ça dépend des scripts au démarrage. La plupart des distributions le font
par défaut, mais on ne connaît jamais les vicieux...

Sinon, tu vérifie, s'il existe, que son âge est inférieur à l'uptime...

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Luc.Habert.00__arjf
Le #24466331
Francois Lafont :

Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est
juste ou faux ? :-)



Le noyau ne permet pas vraiment d'interdire l'écriture simultanée. Il y a
des locks, mais ça n'interdit pas l'écriture, il faut que tous les
programmes susceptibles d'écrire tentent explicitement d'acquerir un lock
avant d'écrire.

Je disais pas vraiment, parce qu'un jour, un gus défoncé a décidé que ça
serait une bonne idée que si le fichier a un bit sgid, alors un lock
interdit vraiment les writes de la part d'autres programmes. Je sais pas si
c'est encore supporté sous linux, ou si ils ont pas ajouté une autre feature
mutante du style.

Je ne constate pas cela sur mon bash :



Oui, il y a des chances que ça varie en fonction du shell.
Marc Boyer
Le #24466441
Le 10-05-2012, Francois Lafont
Le 10/05/2012 13:17, Marc Boyer a écrit :
et de manière moins
précise, tu peux par exemple comparer la date de création de
ton fichier avec l'uptime de la machine.



Au delà de l'aspect conversion de date, mesure d'écart qui je verrai
plus tard, je ne vois pas trop ce que tu veux dire.

Avec l'uptime, j'ai la possibilité de connaître la date de démarrage du
système. Ok. Mais ensuite. Cette date, tu veux que je la « compare »
avec la date de dernière modif (et donc de création) du fichier, c'est
ça ? Ok. Mais alors qu'entends-tu par « comparer » ? Mesurer l'écart ?
Mais dans ce cas, comment fixer une règle de décision ? Quel seuil fixer ?



Je veux un script qui s'exécute de façon différente si c'est sa
première exécution depuis le reboot: dans un cas, il appelle
prem(), et dans l'autre, pas_prem()

Si le fichier n'existe pas
# Première exécution
prem()
Creer le fichier
SinonSi le fichier existe *et* est plus vieux que l'uptime
# Première exécution depuis le dernier reboot
prem()
Mettre à jour le fichier
Sinon
# Pas une première exécution
pas_prem()



--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Nicolas George
Le #24466591
Luc Habert, dans le message
ou si ils ont pas ajouté une autre feature
mutante du style.



Il y a les leases qui peuvent ressembler, de loin, à ça.
Francois Lafont
Le #24466921
Le 10/05/2012 15:47, Marc Boyer a écrit :

Je veux un script qui s'exécute de façon différente si c'est sa
première exécution depuis le reboot: dans un cas, il appelle
prem(), et dans l'autre, pas_prem()

Si le fichier n'existe pas
# Première exécution
prem()
Creer le fichier
SinonSi le fichier existe *et* est plus vieux que l'uptime
# Première exécution depuis le dernier reboot
prem()
Mettre à jour le fichier
Sinon
# Pas une première exécution
pas_prem()



Ah, d'accord, je comprends. Ça rejoint l'idée de Sergio.
Merci bien.

--
François Lafont
Francois Lafont
Le #24466981
Le 10/05/2012 14:49, Luc Habert a écrit :
Francois Lafont :

Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est
juste ou faux ? :-)



Le noyau ne permet pas vraiment d'interdire l'écriture simultanée. Il y a
des locks, mais ça n'interdit pas l'écriture, il faut que tous les
programmes susceptibles d'écrire tentent explicitement d'acquerir un lock
avant d'écrire.

Je disais pas vraiment, parce qu'un jour, un gus défoncé a décidé que ça
serait une bonne idée que si le fichier a un bit sgid, alors un lock
interdit vraiment les writes de la part d'autres programmes. Je sais pas si
c'est encore supporté sous linux, ou si ils ont pas ajouté une autre feature
mutante du style.



Ok.

Je ne constate pas cela sur mon bash :



Oui, il y a des chances que ça varie en fonction du shell.



Ok.

Merci à tous pour vos explications. Avec tous ces éléments, j'ai de quoi
faire un truc qui tiendra la route je pense.

À+


--
François Lafont
Publicité
Poster une réponse
Anonyme