Discussion :

[kondor76]

Bonjour,

Je souhaite utiliser la flock pour locker un fichier, mais comment tester simplement si de fichier à été locké ou non?
Je vu lsof, mais cela m'oblige à parser derrière et je me demande s'il n'y a pas un moyen plus simple...

Merci d'avance,

Kondor76

[BufferBob]

salut,

tu envisagerai quoi/quel genre de moyen "plus simple" ?

[kondor76]

Ben disons un binaire genre isset_lock sur un fichier pou voir si un lock est positionné...

[BufferBob]

en fait je connais pas flock, ce qui m'interpelle c'est quand tu parles de "locker un fichier", mais j'ai l'impression que flock sert à poser un fichier de lock pour encadrer un ensemble d'instructions plutôt non ?

de ce que je lis il existerait la commande lslk et sa remplaçante lslocks dans le package util-linux, je dois dire que je les ai pas trouvées perso, donc à vérifier

par ailleurs, même avec lsof chez moi ça donne pas grand chose :

Code :

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

1
2
3
# ( flock -x -w 10 200 || echo "cant lock";  sleep 2 ; lsof +f g /run/lock/mylockfile ; sleep 2 ) 200>/run/lock/mylockfile
COMMAND  PID USER   FD   TYPE FILE-FLAG DEVICE SIZE/OFF      NODE NAME
bash    3179 root  200w   REG      W,LG  0,152        0 252146240 /run/lock/mylockfile

[Sve@r]

Ben disons un binaire genre isset_lock sur un fichier pou voir si un lock est positionné...

Bonjour

Suffit de demander le lock sur une commande neutre (style true). Si le lock n'est pas accordé, c'est qu'il est déjà positionné...

Exemple
terminal 1: flock -n verrou -c "ls; sleep 120" (pour positionner un lock durant 2mn sur le fichier nommé "verrou")
terminal 2: flock -n verrou -c "true" && echo "fichier libre" || echo "fichier verrouillé" (teste et affiche si le lock y est ou pas)

Et si on remplace la commande neutre par un rm, alors ça permet même de supprimer le fichier lock quand il est devenu inutile => flock -n verrou -c "rm -f verrou" && echo "fichier libre" || echo "fichier verrouillé".

Ensuite suffit d'encapsuler tout ça dans un outil général permettant de faire ce que tu souhaites...

[Flodelarab]

Bonjour

Très intéressante discussion.

2 questions:
Qu'est-ce qu'un verrou ?
Quelle est sa portée ?

Pour la première question, je me doute bien que cela interdit l'accès en modification à un fichier. Mais la lecture ? Et l'exécution ?
Et puis verrouiller un fichier de données, ok aussi. Mais que signifie verrouiller une commande comme fait ci-dessus ? Cela signifie-t-il que tous les fichiers traités par le-dit script verrouillé seront verrouillés ?
Pour la deuxième question, il s'agit, en fait, d'un accès privilégié. Mais pour qui ? Si je verrouille un fichier pour un script, les scripts enfants appelés dans un script pourront-ils y accéder ? Et les parents, pourront-ils ?

[Sve@r]

Qu'est-ce qu'un verrou ?

Un outil destiné à protéger une ressource contre plusieurs accès concurrents...

Quelle est sa portée ?

Je dirais qu'elle englobe tout l'OS

Pour la première question, je me doute bien que cela interdit l'accès en modification à un fichier. Mais la lecture ? Et l'exécution ?

Le verrou peut être positionné de façon à autoriser la lecture (partagé). De plus, l'outil flock (/usr/bin/flock) ne permet de verrouiller qu'une commande, pas un fichier. Le fichier, lui, c'est le verrou lui-même. Il peut-être

• soit nommé explicitement (comme dans mon exemple)
• soit référencé par son descripteur (1=stdout, 2=stderr, etc). Dans ce cas, ça se fait par un un truc du type ( flock -n X || exit ; commandes ...) X>verrou (X étant un n° de descripteur de ton choix)

Et donc dans ces deux et uniques cas, il n'y a pas de notion "d'exécution" de quoi que ce soit...

Mais que signifie verrouiller une commande comme fait ci-dessus ?

Ca assure l'unicité de la commande à un instant "t"...

Cela signifie-t-il que tous les fichiers traités par le-dit script verrouillé seront verrouillés ?

On ne pourra pas lancer plusieurs instances de la commande (du script) en même temps. Donc les fichiers modifiés par la commande (le script) ne seront modifiés que par une seule instance de la commande (du script) à un instant "t". Mais cela n'interdira pas l'accès aux fichiers par un autre moyen. Bref si le script modifie "/etc/passwd", rien ne m'interdira d'aller ouvrir "/etc/passwd" par "vi" pendant que le script s'exécute. Le verrou est un outil collaboratif => ça ne fonctionne que si tout le monde joue le jeu...

Pour la deuxième question, il s'agit, en fait, d'un accès privilégié. Mais pour qui ? Si je verrouille un fichier pour un script, les scripts enfants appelés dans un script pourront-ils y accéder ? Et les parents, pourront-ils ?

Je pense que si tu comprends tout ce que j'ai écrit ci-dessus, cette question ne se pose plus...

[BufferBob]

après quelques recherches, comme fait remarquer Sve@r c'est censé être un truc coopératif, du coup on peut légitimement s'interroger de l'intérêt réel du mécanisme (hormis le coté atomique), c'était apparemment hérité de BSD et on encourageait plus trop à les utiliser

néanmoins certains OS (dont Linux avec flock(2)) ont implémenté des locks stricts, et il semble par ailleurs que tous les filesystems ne supportent pas les verrous non plus

de fait dans mon précédent post ça ne fonctionne pas (pas de manière stricte avec une interdiction explicite de toucher au descripteur ou au fichier), il semblerait que ce soit parceque j'effectuais mes tests sur du SIMFS

sur un FS et un OS qui le supporte, la théorie voudrait que flock -x verrou -c "sleep 30" dans le terminal 1, renvoit dans le terminal 2 (y compris en root) quelque chose comme :

Code :

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

1
2
# cat verrou
bash: verrou: Ressource temporairement non disponible

si quelqu'un peut confirmer...

[Sve@r]

sur un FS et un OS qui le supporte, la théorie voudrait que flock -x verrou -c "sleep 30" dans le terminal 1, renvoit dans le terminal 2 (y compris en root) quelque chose comme :

Code :

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

1
2
# cat verrou
bash: verrou: Ressource temporairement non disponible

si quelqu'un peut confirmer...

Sur ma Debian (FS de type ext4), la commande flock -x verrou -c "sleep 30" va créer un fichier vide nommé "verrou" qui sert de verrou pour protéger mon "sleep 30". Et donc si je tape la même comande dans un autre terminal, celle-ci attend que la première ait terminé pour s'exécuter. Mais dans tous les cas le fichier reste et demeure vide et ne contient donc pas de message particulier. Détails d'implémentation peut-être (mais qui restent du détail)...

[Flodelarab]

Et donc si je tape la même commande dans un autre terminal, celle-ci attend que la première ait terminé pour s'exécuter.

Euh ... pas chez moi. Ou alors j'ai loupé un épisode. C'est pas la fête du sleep.