La commande "at" ne s'exécute pas sur 10.8

[dimitrim]

Non seulement elle ne s'exécute pas, mais génère des messages stupides d'erreur. Exemple: le fichier "mycrontest.sh" contenant deux lignes

#!/bin/bash
echo "It is now $(date +%T) on $(date +%A)"

n'est pas exécuté avec le retard programmé d'une minute, bien que le job soit présent dans la queue (s'il était exécuté, il aurait tapé l'heure et la date, comme le montrent deux premières lignes de l'exemple).

Et il y a encore ce message idiot d'erreur. Le même message apparait après la commande "ps". Mais la commande ps est bien exécutée, à la différence de la commande "at".

****************************
$ mycrontest.sh
It is now 00:39:25 on Jeudi
$ at -f mycrontest.sh now +1 minute
dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/at) is setuid or setgid
job 11 at Thu Dec 11 00:41:00 2014
$ atq
dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/atq) is setuid or setgid
11 Thu Dec 11 00:41:00 2014
$ date
Jeu 11 déc 2014 00:41:11 CET
$ ps
dyld: DYLD_ environment variables being ignored because main executable (/bin/ps) is setuid or setgid
PID TTY TIME CMD
4009 ttys000 0:00.18 -bash
*****************************

 

[bompi]

Ce n'est pas un message d'erreur mais un avertissement et il n'est pas stupide, dans un contexte de sécurisation accrue de l'OS.
Mais je conviens volontiers que ce serait agréable de pouvoir le virer (après l'avoir vu deux-trois fois, on a compris ce qui est en jeu...)

Pour en revenir au fait que ça marche ou pas, si tu essayes en redirigeant la sortie vers un fichier, au lieu de stdout, ça donne quoi ?

 

[dimitrim]

J'ai modifié le script "mycrontest.sh" comme suit:

#!/bin/bash
# echo "It is now $(date +%T) on $(date +%A)"
echo "It is now $(date +%T) on $(date +%A)" >> test.txt

Et j'ai lancé le job:

$ at -f mycrontest.sh now +1 minute
dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/at) is setuid or setgid
job 15 at Thu Dec 11 11:52:00 2014
$

Or le fichier "test.txt" n'est pas apparu à 11h52, comme on pouvait attendre.

 

[bompi]

Pas si sûr.
Tu as mis un chemin relatif pour le fichier, puisque tu n'as pas précisé son répertoire et que, comme le précise l'avertissement, les variables d'environnement sont ignorées. Donc il reste encore la possibilité qu'un fichier "test.txt" a été créé quelque part sur le disque (mais pas dans le dossier où se situait le shell au moment de l'appel à la commande at).
Pour être absolument certain que ça tourne ou pas, il faut soit écrire quelque chose dans les journaux (avec logger par exemple) soit écrire dans un fichier dont on précisera bien le chemin complet.

Pour revenir à ton premier test, je m'interroge sur la sortie sur laquelle doit être envoyé le echo. Je pense que c'est le stdout du shell (sh d'après le manuel) lancé par at. Pas le stdout du shell dans lequel tu as lancé at.

Est-ce que tu as déjà utilisé cette commande sur OS X ?

 

[dimitrim]

Avant j'utilisais un MacBookPro sous Snow Leopard. Il est cassé depuis quuelques semaines et j'ai migré au Mac Mini sous ML 10.8.5.

Je n'ai pas essayé "at" sur MacBookPro. Mais j'ai utilisé d'autres scripts sur MacBookPro qui ne fonctionnent plus sur Mac Mini. Voilà mon imprimante virtuelle préférée, qui travaillait sans souci sur MacBookPro et ne fonctionne pas sur MacMini:
*************
#!/usr/bin/perl
use IO::Socket::INET;
$myport=12000;
$pserve=IO::Socket::INET->new(LocalPort => $myport,Type=>SOCK_STREAM,Reuse=>1,Listen=>1) or die "can't do that $!\n";
while ($pjob=$pserve->accept()) {
open(J,">>/Users/dimitrim/Desktop/tran/myprintfile") or print "having issues $!\n";
while (<$pjob>) {
print J "$_";
}
close J;
close $pjob;
}
*************
Elle prétend être une imprimante postscript et collectionne tout ce qu'elle reçoit dans un fichier postscript. Sur MacMini, elle ne crée pas le fichier "/Users/dimitrim/Desktop/tran/myprintfile" sans rien dire. Je ne sais pas quel est le problème; ça doit être un problème d'autorisation, mais je ne sais pas où chercher une solution. Peut être, c'est le même problème qu'avec "at".

J'ai regardé ce qui se passe dans la console après le lancement de l'impression, cela ne me dit rien, je recopie quand même:

11/12/14 14:45:43,239 Dock[176]: no information back from LS about running process
11/12/14 14:46:12,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:46:46,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:47:21,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:47:56,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:48:18,000 kernel[0]: firefox (map: 0xffffff8032d633a0) triggered DYLD shared region unnest for map: 0xffffff8032d633a0, region 0x7fff86200000->0x7fff86400000. While not abnormal for debuggers, this increases system memory footprint until the target exits.
11/12/14 14:48:33,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:48:36,195 com.apple.kextcache[295]: Kernel file /mach_kernel does not contain requested arch: i386
11/12/14 14:48:52,599 com.apple.kextcache[295]: Created prelinked kernel /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache.
11/12/14 14:49:31,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:50:03,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:50:37,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:51:11,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:51:46,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:52:22,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:53:00,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:53:38,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:54:17,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:54:58,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:56:18,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)
11/12/14 14:59:00,000 kernel[0]: nbssn_recvhdr: bad nb header received 0x1 (bogus type)

 

[bompi]

Pour ton problème d'imprimante virtuelle, c'est effectivement une question de sécurité et de sandboxing, qui n'existait pas sous Snow Leopard, et, comme toi, pas le moindre message d'erreur à l'écran...

J'ai donc dû changer la configuration de CUPS-PDF pour qu'il crée les fichiers dans un sous-répertoire du système (genre : /private/var/spool/cups-pdf/brol) et créer un lien symbolique sur mon bureau vers ce répertoire pour accéder simplement aux fichiers imprimés.

Dans ton cas, il faudrait donc que tu changes dans ton script /Users/dimitrim/Desktop/tran/myprintfile en quelque chose comme /private/var/spool/virtualPSprinter/dimitrim. Avec ce qu'il faut comme droit en lecture (pour tous comme eût dit Pierre Dumayet).
Puis faire un lien symbolique vers ce dossier pour que son contenu soit aisément accessible.

[[N'ayant pas mon MBP sous la main je ne peux pas te dire les droits que j'ai mis à ce dossier. En plus, depuis Yosemite, CUPS-PDF n'y arrivant carrément plus j'ai pris une autre solution.]]

 

[dimitrim]

Merci pour la suggestion de modifier CUPS-PDF. Je ne sais pas comment le faire, si tu as une référence, j'aimerais bien l'apprendre.

Entre temps j'ai réussi de faire marcher l'imprimante virtuelle en corrigeant une erreur stupide d'un chemin qui a changé lors de la migration.

Maintenant je vois que perl n'a aucun souci pour ouvrir un fichier chez moi.

Le problème de "at" reste non-résolu.

 

[bompi]

En fait, c'est tout simple : la commande at permet de créer les travaux à exécuter. Mais les travaux sont exécutés par un daemon qui, par défaut, n'est pas lancé.

Il te suffira donc de le lancer, comme ceci :

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.atrun.plist

 

[dimitrim]

Merci, Bompi!

Maintenant cela marche. La solution que tu donnes est très simple, mais il n'est pas facile de la trouver sur l'internet!

Le problème est que quand on google la commande at, on ne trouve rien, car at est un mot trop commun.

D'ailleurs, "at" continue à afficher l'avertissement de dyld, mais cela ne m'ennuie pas trop.

 

[bompi]

Pour le coup, je n&#8217;ai pas cherché sur Internet mais fait des tests sur mon Mac.
L&#8217;idée m&#8217;est venue quand j&#8217;ai constaté que les jobs étaient tous là à attendre quelque chose.

Pour le message, je n&#8217;ai pas encore vu d&#8217;astuce pour qu&#8217;il disparaisse.