Pourquoi les crontabs ne sont-ils pas stockés dans les répertoires personnels des utilisateurs?

Je suis curieux de savoir: pourquoi les crontabs sont-ils stockés dans / var plutôt que dans les répertoires personnels de l'utilisateur? Il est très pénible d’isoler ces fichiers pour les mises à niveau, mais je soupçonne qu’il existe une raison logique ...

cron directory-structure home

— Martin Eve
source

Quelques raisons pour lesquelles je peux penser:

Dans les environnements d'entreprise, vous pouvez avoir des milliers d'utilisateurs. Si tel est le cas, cron devrait parcourir le répertoire de chaque utilisateur toutes les minutes pour rechercher le fichier crontab (qu'il ait été créé, supprimé ou modifié).
En les conservant au même endroit, il n’a pas à effectuer cette analyse intensive.
Les répertoires personnels ne sont peut-être pas toujours disponibles. Si les répertoires de départ sont un montage autofs, ils ne seront peut-être pas montés. Le fait de les vérifier toutes les minutes à la place de cron les ferait monter et les empêcherait de se démonter pour cause d'inactivité. De plus, si le répertoire de base est crypté et déchiffré avec le mot de passe de l'utilisateur, cron ne pourra pas accéder au répertoire de base à moins que l'utilisateur ne l'ait connecté et déchiffré / monté.
Les répertoires de base peuvent être partagés entre les hôtes. Si le répertoire de base est un partage réseau, ce même répertoire de base apparaîtra sur plusieurs hôtes. Mais vous ne voudrez peut-être pas que vos tâches cron soient exécutées sur tous les hôtes, un seul d'entre eux.

— Patrick
source

+1 Bien que traditionnellement cron, ces fichiers ne soient pas réanalysés toutes les minutes; il les a chargés une fois et ne les relit que sur un signal.

— goldilocks

Mais vous avez raison à propos du point 3; selon wikipedia, les crontabs étaient à l’ origine dans $ HOME, jusqu'à ce que "[les développeurs du laboratoire Bell] incorporent Unix à la commande dans cron, déplacent les fichiers crontab des répertoires de départ des utilisateurs (qui ne sont pas spécifiques à l’hôte) et à un système commun spécifique à l’hôte. spool directory ... "C’est également lors de la création de la crontabcommande qui aurait pu traiter le problème de rechargement.

— goldilocks

@Patrick Ou lorsqu'un programme utilise l' utimesappel système, avec le chemin du répertoire de spool comme argument, pour définir le mtime du répertoire, comme le fait la crontabcommande de Vixie cron .

— Mark Plotnick

Les premières versions de cron ne prenaient certainement pas en compte les modifications apportées aux fichiers utilisateur crontab, à moins qu'elles aient été modifiées via crontab -e. Je suis pris par dans le passé sur Solaris voir cette décennies page man manpages.info/sunos/cron.1.html

Sur Solaris 10, crontab -equi est setuid root, écrit un message /etc/cron.d/FIFOaprès qu'un utilisateur a modifié une crontab.

— Mark Plotnick