7 votes

cron requiert apparemment un caractère de nouvelle ligne sur sa propre ligne à la fin du fichier.

J'essaie de comprendre pourquoi cron refuse de fonctionner avec un certain fichier crontab. La page de manuel de crontab dit :

cron exige que chaque entrée d'une crontab se termine par un caractère de nouvelle ligne. Si la dernière entrée d'une crontab ne comporte pas de nouvelle ligne, cron considère que la crontab est (au moins partiellement) cassée et refuse de l'installer. refusera de l'installer.

Étant donné le fichier cron suivant :

\# managed by Fabric$
$
SHELL=/bin/sh$
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin$
$
# m h dom mon dow user  command$
17 \*    \* \* \*   root    cd / && run-parts --report /etc/cron.hourly$
25 6    \* \* \*   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )$
47 6    \* \* 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )$
52 6    1 \* \*   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )$
$
# Postgres monitoring$
\*  \*    \* \* \*   postgres cd / && /etc/cron.d/pgup.sh$
\*/5 \*   \* \* \*   postgres   cd / && /etc/cron.d/aws-scripts-mon/mon-put-instance-data.pl --mem-avail --disk-space-util --disk-path=/mnt$
$
# Postgres Backup$
00 00   \* \* \*   postgres /etc/cron.d/pgbackup.sh$

Noter que le caractère "$" indique un caractère LF (format vim unix).

Et je reçois l'erreur suivante dans syslog lorsque je redémarre cron :

Mar 31 17:34:02 postgres-primary0 cron[30852] : ( système ) ERROR (saut de ligne manquant avant EOF, ce fichier crontab sera ignoré)

Et l'ajout d'une ligne vide à la fin du fichier cron n'entraîne aucune erreur lors du redémarrage de cron.

Conclusion :

Pour autant que je sache, la dernière entrée se termine par un caractère de nouvelle ligne. Il semble donc que la crontab ne la reconnaisse pas.

Est-ce un bug ? Peut-être que l'intention était qu'il y ait une nouvelle ligne sur sa propre ligne à la fin du fichier, auquel cas la documentation est trompeuse. Ou peut-être que je ne comprends pas correctement le terme "nouvelle ligne" dans ce contexte... Une clarification sur ce point serait appréciée.

4voto

Kamil Maciorowski Points 57004

Est-ce un bug ?

Non. J'ai créé un fichier sans caractère de nouvelle ligne à la fin. Néanmoins, Vim (après :set list ) montre $ à la fin. Il semble que votre prémisse soit fausse, qu'il manque une nouvelle ligne finale à votre fichier, et que cron fonctionne comme prévu.


Notes :

  • POSIX nécessite un caractère de fin de ligne pour considérer qu'une ligne est complète.

    3.195 Ligne incomplète
    Une séquence d'un ou plusieurs caractères non-<newline> à la fin du fichier.

    [ ]

    3.206 Ligne
    Une séquence de zéro ou plus caractères non-<nouvelle> plus un caractère <nouvelle> de fin.

    Ainsi, le comportement de cron n'est pas seulement une bizarrerie arbitraire (bien que l'outil puisse ne pas être aussi restrictif). Pour plus d'informations, voir Pourquoi les fichiers texte doivent-ils se terminer par un saut de ligne ?

  • Vim, avec les paramètres par défaut, corrigera le saut de ligne manquant lors de l'enregistrement, sauf si vous lui dites de ne pas le faire .

  • Pour savoir s'il y a un caractère de nouvelle ligne à la fin ou non, faites un hexdump du fichier, par exemple. hexdump the_file o xxd the_file . Dans le cas de votre crontab, cela peut être difficile. Dans ma Debian, la crontab est /var/spool/cron/crontabs/kamil mais comme je n'ai pas accès à /var/spool/cron/crontabs/ en tant qu'utilisateur normal, je ne peux pas simplement xxd le fichier. Pour surmonter ce problème, je peux utiliser l'astuce suivante :

    EDITOR=xxd crontab -e

    Il y a une nouvelle ligne à la fin si le dernier octet rapporte comme 0a .

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X