Flock ne semble pas fonctionner

flock fait du locking consultatif, qui est un schéma de locking coopératif. Cela signifie que vous pourrez annuler le locking si vous ne coopérez pas. Vous coopérez en demandant le locking avant de faire l'opération, puis en libérant le verrou une fois que vous avez terminé. C'est l'opération qui est protégée par le verrou, pas (forcément) le file de locking lui-même.

Du manuel flock(2) sur mon système:

Les verrous de consultation permettent aux process qui coopèrent d'effectuer des opérations cohérentes sur les files, mais ne garantissent pas la cohérence (c.-à-d. Les process peuvent toujours accéder aux files sans utiliser de verrous consultatifs pouvant entraîner des incohérences).

Considérez ce script:

 #!/bin/sh ( flock -x 9 || exit 1 echo '1: Locking for 5 secs'; sleep 5; echo '1: Done' ) 9>/tmp/lock & sleep 1 echo '2: Will now attempt to get lock' ( flock -x 9 || exit 1 echo '2: Got lock' ) 9>/tmp/lock # Since the second flock call only performs one operation, the whole last # subshell may be replaced by just # flock -x /tmp/lock -c echo '2: Got lock' # # (-x and -c are not needed, a lock is exclusive ("write lock") # unless -s is used to create a shared lock ("read lock"), # and the -c is optional) 

Sortie:

 1: Locking for 5 secs 2: Will now attempt to get lock 1: Done 2: Got lock 

Vous pouvez voir que le locking a été acquis par le process d'arrière-plan et que l'autre invocation du flock a dû attendre qu'il soit libéré avant de pouvoir le verrouiller.

Notez également que le file de locking n'est pas ce qui est protégé ici, ce sont les opérations d' echo dans les sous-shell qui sont garanties exclusives. En particulier, le file de locking n'est pas protégé contre les process non coopératifs qui écrivent ou lisent à partir de celui-ci.

Cela garantit que les opérations (sur les files ou autres ressources de données partagées) ne seront pas mélangées avec des opérations conflictuelles de n'importe quel autre programme utilisant flock avec /tmp/lock comme le file de locking.

Pour illustrer le dernier paragraphe ci-dessus, exécutez mon script ci-dessus dans deux terminaux différents (éventuellement avec un time de sumil légèrement augmenté), et vérifiez que les deux scripts concurrents acquièrent les verrous de manière appropriée. Comme un verrou est demandé dans un process d'arrière-plan, cela signifie que les verrous peuvent être acquis hors de l'ordre de ce qui est spécifié dans le script.

Dans votre exemple, le shell interactif ne coopère pas avec le mécanisme de locking . C'est pourquoi vous pouvez lire et écrire dans le file même si le verrou est maintenu par le sous-shell en arrière-plan.

Notez également que tous les filesystems ne supportent pas le locking de file avec flock (ou l'équivalent de la bibliothèque C, flock() ). Par exemple, les filesystems réseau AFS et NFS peuvent être problématiques à cet égard. Voir https://en.wikipedia.org/wiki/File_locking#Problems