Solaris "crontab -e" locking via vi

J'ai rencontré un problème hier avec le locking sur Solaris et l'édition de crontab qui m'a demandé de savoir quelle est la meilleure façon de protéger plusieurs modifications simultanées du même crontab sur Solaris. J'ai confirmé que le comportement existe dans Solaris au 11.2.10.5.0.

EDITOR=vi OS=Solaris 10, 11 SHELL=bash RBAC=pfexec 

Maintenant, normalement, vi utilise les files .filename.swp pour éviter plusieurs modifications simultanées du même file, qu'il s'agisse de plusieurs users ou de multiples invocations du même user. Cependant, "crontab -e" crée et passe un file temporaire avec un nom basé sur / tmp / crontabXXXXXX vers $ EDITOR, et plusieurs invocations simultanées de "crontab -e" transmettront différents files temporaires à $ EDITOR, ce qui pourrait permettre la réversion des modifications au crontab quand il est ouvert à partir de deux endroits à la fois, ou lorsqu'une session Vi suspendue est tuée en raison du dépassement de time de TTY, comme cela s'est passé avec moi. Il n'y a en outre aucun avertissement de $ EDITOR sur la deuxième invocation de "crontab -e" car le file en cours de modification est différent.

Comment puis-je empêcher que ce problème ne se produise? L'utilisation d'un nom de file temporel pseudo-random empêche le locking embedded dans vi de travailler, ce qui correspond à l'itinéraire optimal. Peut-être que le problème est plus fondamental et doit être soulevé en tant que bogue OS. La page manuelle de Solaris Crontab ne laisse pas beaucoup d'espoir en indiquant: "Des modifications simultanées du même file crontab peuvent entraîner des résultats inattendus", mais j'espère que quelqu'un a une réponse.

Si cela vous préoccupe vraiment, vous devrez écrire quelque chose comme vous, car la page man suggère qu'elle n'est pas embeddede.

Vous pouvez écrire un wrapper pour crontab (1) qui a effectué la vérification de locking / locking avant d'exécuter crontab (1) lui-même.

Dans cette réponse, je suggère une méthode de locking de file utilisant mkdir.

Cette idée ne semble cependant pas être une entreprise insignifiante.