CRON ne me trouve pas diskutil me dit il dans un "mail"

  • Créateur du sujet Créateur du sujet oZen
  • Date de début Date de début
O

oZen

Membre confirmé
8 Janvier 2006
82
26
Bonjour,

CRON me retourne des mails dans lesquels il dit ne pas trouver la commande "diskutil" lorsqu'il exécute un de mes (micro) script.
J'ai tenté de lui passé le chemin absolu mais rien n'y fait l'erreur est toujours la même...

Voila mon script:
(Je vous préviens c'est surement pas terrible terrible...)

Bloc de code: 
#!/bin/bash

tmutil startbackup &
PID1=$!

wait $PID1
sleep 30

/usr/sbin/diskutil umount /Volumes/TM_Ecole

Le petit "mail" de CRON:

Bloc de code: 
†From [email protected]  Tue Apr  8 15:38:31 2014
Return-Path: <[email protected]>
X-Original-To: Lololle
Delivered-To: [email protected]
Received: by MacBook-Air-de-Laure.local (Postfix, from userid 501)
        id 4A29D1C75FF; Tue,  8 Apr 2014 15:38:30 +0200 (CEST)
From: [email protected] (Cron Daemon)
To: [email protected]
Subject: Cron <Lololle@MacBook-Air-de-Laure> tmutil startbackup && sleep 30 && diskutil umount /Volumes/TM_Ecole
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=Lololle>
X-Cron-Env: <USER=Lololle>
X-Cron-Env: <HOME=/Users/Lololle>
Message-Id: <[email protected]>
Date: Tue,  8 Apr 2014 15:38:30 +0200 (CEST)

/bin/sh: diskutil: command not found

Si quelqu'un a une idée, ce serait avec joie !

Merci d'avance !
 
Dans le message que tu affiches, on voit bien que diskutil est appelé sans son chemin, lequel n'est pas défini par la variable PATH.
Donc :
- le mail est cohérent ;
- il ne correspond pas au script listé au-dessus.
 
bompi a dit:
Dans le message que tu affiches, on voit bien que diskutil est appelé sans son chemin, lequel n'est pas défini par la variable PATH.
Donc :
- le mail est cohérent ;
- il ne correspond pas au script listé au-dessus.
Cliquez pour agrandir...

Si, si, j'ai déjà fais cette tentative de chemin absolu mais je n'ai pas été très clair dans mon premier message. Ce n'est pas l'exemple de "code" que j'ai collé, mais j'ai déjà tenté.

De plus j'ai passé à CRON les variables PATH qui m'intéressaient dans la CRONTAB:

Bloc de code: 
PATH=/sbin:/bin:/usr/sbin:/usr/bin
*/2 * * * * /usr/bin/TmUmount

Mon script TmUmount se trouve dans /usr/bin
et diskutil dans /usr/sbin
lesquels sont déclarés dans ma crontab si j'ai bien les yeux en face des trous, mais rien n'est moins sur en ce moment... Toujours est t'il que je reçois encore les mêmes mails.

Alors je pige pas bien...
C'est vrai que j'utilise pas CRON tous les quatre matins... Est-ce que je déclare pas bien mes variable d'environnement pour mon PATH ? ou autre chose ?

PS: De toute façon CRON semble deprecated et il faudrait utiliser launchd. Mais j'aimerais bien comprendre quand même histoire de pas finir idiot.

Merci bien d'avoir répondu !
Et merci d'avance à tout ceux qui m'aideront ;)
 
Reprenons :

  • dans le message que tu donnes, le sujet est constitué d'une suite de commande qui ressemble bigrement à ton script, et diskutil y est appelé sans chemin ;
  • je n'ai pas de quoi tester sous la main mais je ne suis pas forcément confiant sur les déclarations de PATH dans la table ; après tout, autant mettre cette déclaration dans le script lui-même, en faisant précéder PATH de export :
    export PATH=/sbin:/bin:/usr/sbin:/usr/bin
  • effectivement, CRON est en voie d'obsolescence chez Apple... mais ils ont quand même décidé de l'intégrer à launchd (comme quoi) ; donc il marche toujours, y compris sous Mavericks ;
  • par ailleurs, il faudrait peut-être, avant de lancer la sauvegarde Time Machine, vérifier la présence du disque Time Machine, non ?
 
bompi a dit:
Reprenons :

  • dans le message que tu donnes, le sujet est constitué d'une suite de commande qui ressemble bigrement à ton script, et diskutil y est appelé sans chemin ;
  • je n'ai pas de quoi tester sous la main mais je ne suis pas forcément confiant sur les déclarations de PATH dans la table ; après tout, autant mettre cette déclaration dans le script lui-même, en faisant précéder PATH de export :
    export PATH=/sbin:/bin:/usr/sbin:/usr/bin
  • effectivement, CRON est en voie d'obsolescence chez Apple... mais ils ont quand même décidé de l'intégrer à launchd (comme quoi) ; donc il marche toujours, y compris sous Mavericks ;
  • par ailleurs, il faudrait peut-être, avant de lancer la sauvegarde Time Machine, vérifier la présence du disque Time Machine, non ?
Cliquez pour agrandir...

Merci pour ton aide Bompi !


Depuis j'ai essayé ce que tu m'a dis, en rajoutant export PATH=/sbin:/bin:/usr/sbin:/usr/bin dans le script.
D'abord comme ça:
Bloc de code: 
#!/bin/bash

export PATH=/sbin:/bin:/usr/sbin:/usr/bin

tmutil startbackup &
PID1=$!

wait $PID1
sleep 30

diskutil umount /Volumes/TM_Ecole

puis comme ça avec des chemins absolus:
Bloc de code: 
#!/bin/bash

export PATH=/sbin:/bin:/usr/sbin:/usr/bin

[COLOR="red"]/usr/bin/[/COLOR]tmutil startbackup &
PID1=$!

wait $PID1
[COLOR="red"]/bin/[/COLOR]sleep 30

[COLOR="Red"]/usr/sbin/[/COLOR]diskutil umount /Volumes/TM_Ecole

Selon les cas et pour pas que les PATH fasse doublon (voire triplon, oui je viens de l'inventer) je les ai testé avec deux tables CRON:

Bloc de code: 
PATH=/sbin:/bin:/usr/sbin:/usr/bin
*/2 * * * * /usr/bin/TmUmount

ou

Bloc de code: 
*/2 * * * * /usr/bin/TmUmount
Quand l'export était intégré dans le script pour éviter un doublon, au cas ou...


Quoi qu'il arrive je reçois toujours ce maudis mail:
Bloc de code: 
From [email protected]  Tue Apr  8 15:38:31 2014
Return-Path: <[email protected]>
X-Original-To: Lololle
Delivered-To: [email protected]
Received: by MacBook-Air-de-Laure.local (Postfix, from userid 501)
        id 4A29D1C75FF; Tue,  8 Apr 2014 15:38:30 +0200 (CEST)
From: [email protected] (Cron Daemon)
To: [email protected]
Subject: Cron <Lololle@MacBook-Air-de-Laure> tmutil startbackup && sleep 30 && $
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=Lololle>
X-Cron-Env: <USER=Lololle>
X-Cron-Env: <HOME=/Users/Lololle>
Message-Id: <[email protected]>
Date: Tue,  8 Apr 2014 15:38:30 +0200 (CEST)

/bin/sh: diskutil: command not found
Et question subsidiaire, pourquoi la date reste toujours au 8 Apr 2014 15:38:30 +0200 (CEST) peu importe quand je reçois ces mails.
Dans ces mails, si j'ai spécifié des variables PATH autres que celles par défaut pourtant j'ai toujours cette ligne X-Cron-Env: <PATH=/usr/bin:/bin> qui semble vouloir rester bloqué sur seulement /usr/bin et /bin.
Est-ce qu'il m'installe complètement ma CRONTAB ? :mouais:

Je te remercie bien encore !
 
Petit question : tu le voies comment ce mail ?
Es-tu sûre de vraiment le supprimer et que donc il est recréé par le système ?
 
;)

Pour voir un message envoyé par le système à un des comptes de ce système, en l'état, il faut, loggé(e) sous ce compte, ouvrir le Terminal et lancer la commande mail. Si tu le supprimes, tu ne le verras plus (c'est une lapalissade mais parfois il vaut mieux en asséner une :D).

Malheureusement, plus aucun client de messagerie n'est capable de lire la boîte mail du système (UNIX). Ce que je fais, c'est passer par le Terminal ou alors j'installe un serveur POP ou un serveur IMAP sur la machine et je crée un compte dans Mail ou Thunderbird.

Bref : tu l'auras compris, tu t'acharnes alors qu'il n'y a plus de problème depuis que tu as mis le chemin complet pour accéder la commande diskutil.
 
D'accord je comprends mieux pourquoi certains se plient en quatre pour envoyer tout ça vers des fichiers .log

Reste que si les symptômes ont disparus la maladie persiste, puisque malgré les chemins absolus CRON ne m'exécute pas mon script de la même manière que lorsque je le lance "à la main". Résultat mon volume de sauvegarde n'est pas démonté avec CRON là ou il est bien démonté quand je lance mon script.
 
Il faudrait effectivement récupérer dans des traces ce qui se passe dans le script.
Notamment ce que dit la commande diskutil.
 
Bon pour ne rien te cacher depuis je l'ai fais avec Launchd et ça marche très bien. Il y a certaines règles à suivre la aussi. La différence entre agent et deamon que personne ne semble bien apte a expliquer correctement notamment... :siffle:

Mais si je dois utiliser CRON, sous linux par exemple j'aimerais bien savoir faire.
Alors je vais "débugger" (avec de gros guillemets lol) tout ça, en effet, parce que, comme je l'ai déjà dis je voudrais pas finir idiot.

Mais pour cet après midi j'ai un iMac à démonter/remonter au programme.
Ca ne devrait pas me prendre trop de temps. Je m'y remettrais peut être ce soir si madame n'est pas trop grognon. Après tout c'est pour sauvegarder SES données... :casse:

Merci pour tout Bompi !
 
oZen a dit:
Bon pour ne rien te cacher depuis je l'ai fais avec Launchd et ça marche très bien. Il y a certaines règles à suivre la aussi. La différence entre agent et deamon que personne ne semble bien apte a expliquer correctement notamment... :siffle:
Cliquez pour agrandir...

Un agent ça peut présenter une UI, un daemon non, c'est clairement expliqué dans la doc ;)

Sous linux les logs pour cron sont dans /var/log/cron, ils doivent être au même endroit sur OS X.
Tu peux utiliser /Utilities/Console.app pour chercher à la limite?
 
La différence entre un agent et un daemon est que celui-ci est lancé pour le compte du système (quitte ensuite à se relancer sous un compte spécifique) quand celui-là est lancé sous le compte de l'utilisateur.

Les services ou daemons sont définis dans les dossiers suivants :

  • /System/Library/LaunchDaemons : daemons définis par Apple et installés avec le système ou ses compléments ; quand on est respectueux de l'ordre établi, on n'y installe pas ses propres daemons, quoi...
  • /Library/LaunchDaemons : là où on installe ses propres daemons ;)
Sauf s'ils sont désactivés, les daemons définis dans ces deux dossiers seront lancés au démarrage du système.


Les agents sont définis dans les dossiers suivants :

  • /System/Library/LaunchAgents : agents définis par Apple et installés avec le système ou ses compléments ;
  • /Library/LaunchAgents : agents définis par des tiers ou considérés comme n'appartenant pas au système ;
  • ~/Library/LaunchAgents : agents définis par des tiers ou considérés comme n'appartenant pas au système.
Sauf s'ils sont désactivés, les agents sont lancés (resp. arrêtés) à l'ouverture (resp. la fermeture) des sessions. Les deux premiers dossiers comprennent les agents lancés pour toute session. Les agents définis dans les troisièmes dossiers (donc dans des bibliothèques d'utilisateurs) ne sont lancés qu'à l'ouverture de la session de leur utilisateur respectif.


Et, de fait, on a bien le cas d'un daemon présentant une interface graphique, c'est celui qui lance le serveur graphique, via le processus WindowServer : /System/Library/LaunchDaemons/com.apple.WindowServer.plist.

PS 1 : les services ont souvent un compte attitré, avec lequel on ne peut se logger (que ce soit en mode texte ou en mode graphique) ; on indique alors à launchd de lancer le service sous ce compte spécifique ou, le cas échéant, le service se relance lui-même automatiquement sous le bon compte (mais je ne suis pas sûr que ce soit bien vu par Apple, ce fonctionnement-là).
PS 2 : note que, si cela t'amuse, tu peux installer launchd sur d'autres systèmes, car c'est un lanceur Open Source ;)
 
Je ne conteste pas, bien entendu.

Je prenais simplement le point de vue du lancement des exécutables (en lien avec le sujet de départ) plus que la nature de ce qui est lancé : les daemons sont pour tout le monde, les agents par utilisateur (on le constate en regardant les processus).
Par ailleurs, il y a encore d'autres moyens de lancer automatiquement des exécutables.

Mais je trouve plaisant cette différenciation sur l'interface graphique puisque le serveur graphique est forcément lancé au niveau du système (donc en tant que daemon, pas d'agent) pour avoir le login graphique (avant toute authentification).
 
Voila c'est un peu ça. A vous deux vous avez résumé la situation. J'étais un peu confus quant à la nature des damons/agents. Beaucoup de sites/blogs n'expliquent pas bien les deux facettes de la chose. Ils donnent leur vision mais ne balaye pas complètement le problème.

Il y a à la fois le fait que l'executable comporte ou non une GUI, mais aussi des histoires de comptes (et par extension de session)

Enfin c'est pas grave, en recoupant les informations, on arrive à tout trouver.

PS 2 : note que, si cela t'amuse, tu peux installer launchd sur d'autres systèmes, car c'est un lanceur Open Source
Cliquez pour agrandir...
Oui, j'ai vu ça et la communauté est plutôt reconnaissante d'Apple par ailleurs.
 

Sujets similaires

A
macOS Big Sur Macbook air 2015 très lent depuis MAJ
Réponses
9
Affichages
3K
macOS
Locke
Locke
furiet
Mail : trouver l'IP de l'expéditeur dans l'en-tête d'un message reçu
Réponses
0
Affichages
1K
Web et e-mail
furiet
furiet
H
10.11 El Capitan /etc/hosts - Corrompu !
Réponses
12
Affichages
3K
macOS
het
H
I
Mises-à-jour automatiques
Réponses
4
Affichages
988
macOS
I1I2I3I
I
R
10.13 High Sierra iTune s'ouvre tout seul
Réponses
0
Affichages
2K
macOS
robin68
R
Haut Bas