[Linux-bruxelles] y aurait-il un gros bug dans at ?

[Gildas Cotomale]

> Supposons que ce que tu dis est vrai, ya des centaines de membres de ce
> forum utilisant Debian !!!!!!!!!!!!!!!!!
>
ou une distribution basée sur Debian (pour ce genre de paquets, les
différences sont seulement au niveau des versions)

[...]
>> Tu es peut-être victime du bug de l'an 2010!
>> Cela a été également le cas d'une banque il y a peu (données erronées sur la
>> puce / piste magnétique de certaines cartes de crédit...)
>>
C'est le fameux bogue de l'an 2000... Comme je l'explique souvent
autour de moi, ça existe presque partout mais n'est pas lié
spécifiquement à cette date (on avait déjà vu des systèmes et
appareils mal se comporter en 1900 !) : c'est lié d'une part à la
longueur de codage des années (pour 1900 par exemple ; la sécurité
sociale en France --je crois, mais je peux confondre-- qui ne notait
que les deux derniers chiffres de l'année a fait renaitre quelques
centenaires... avec 4 chiffres, le problème demeure, il est juste
repoussé à l'année suivant 9999 hahah) et de la date choisie comme
pivot ou point de départ (pour Ms-Excel par exemple, le calculs de
dates passaient bien 2000, mais...)

Ceci dit, je ne pense pas que ce soit le cas ici ; les dates Unix (et
at fait bien appel au cœur du système, ça n'utilise pas un truc propre
à lui) sont un timestamp dont la limite est connue  (et est repoussé à
Mathusalem avec le passage de plus en plus important au 64bits...)
Donc, pour en revenir à notre souci :

[...]
>> > j'ai un script permettant de préprogrammer l'enregistrement d'une emission
>> > radio, script qui jusqu'à présent fonctionnait;
>> > le blème est que le script semble toujours fonctionner, cad affiche la
>> > liste
>> > de tâches qu'il va accomplir de tel jour heure poste jusqu'à tel jour
>> > heure,
>> > mais ... atq me redonne le prompt sans plus,
>> > et ça avant le 31 décemble ça avait bien marché.
>> > Es-ce un blème (bug) dans at ?
>> > Ma distro est Deb Lenny
>> > et at est la v. 3.1.9.
>> >
Peux-tu essayer de reproduire le problème avec un exemple tout simple
que nous pouvons tous suivre et tester ?
Par exemple, j'ai un fichier à la racine de mon home que j'appelle
test_at.sh et qui contient :
=====code===bash==\
#!/bin/sh
date
echo "je suis lancé par la commande at : preuve de fonctionnement"
=====code===bash==/
ensuite, voici ma console
=====session===bash==\
$ at -f test_at.sh  now + 5minutes
warning: commands will be executed using /bin/sh
job 1 at Thu Jan 14 14:22:00 2010
$ atq
1	Thu Jan 14 14:22:00 2010 a gildas
=====session===bash==/
Et effectivement, il ne s'est rien passé ici...
Je n'ai pas de /etc/at.allow mais par contre un /etc/at.deny où ne
figure aucun user (que des services/serveur ainsi que guest, nobody,
...) Dans /var/spool/cron j'ai bien atjobs et atspools qui sont des
répertoires en lecture et écriture pour le propriétaire daemon et le
groupe de même nom et ces répertoires ont le bit sTicky (comment avoir
les valeurs numériques/octales des permissions au fait ?)
Je relance la commande et je vérifie (en root) qu'un fichier dont je
suis propriétaire est bien créé dans /var/spool/cronatjobs ; ceci
n'est pas surprenant vu que atq a fonctionné. Et rien de signalé dans
/var/log/messages (doit-on supposer que la commande s'est executée
sans erreur ? qu'en est-il alors de sa sortie ?) Je suis perplexe.