CRONTAB

NicolasAlex.Michel.remove

28/04/2010 à 14:47

patpro ~ Patrick Proniewski wrote:

In article <4bd6b53b$0$21592$,
LeBuss wrote:

> OK as tu des infos, tuto ou quoi que ce soit pour que je puisse me
> débrouiller avec ça ??

là par exemple :

http://patpro.net/blog/index.php/2008/01/03/131-passer-de-cron-a-launchd/

Merci patpro pour ce blog, que j'ai jamais remarqué
dans ta signature <:o)
Plein de bonnes choses à lire !

Par contre je ne comprends pas pourquoi, alors que tu critiques launchd
tout du long de ton article, tu dis qu'il est buggy, verbeux et
complexe, incompatible avec les versions précédentes de Mac OS X,
pourquoi donc tu continues à dire qu'il faut l'utiliser à la place de
cron !?

Tu penses que Apple va supprimer cron dans une future version ?
Ou que cron a des défaut ?
La seule raison que tu donne, c'est
"Apple a dit d'utiliser launchd, donc on utilise launchd" !?

Perso j'ai des crontab qui tournent depuis la 10.2,
j'ai pas vu le moindre soucis. Pareil pour anacron.
Ils font ce qu'ils sont sensés faire, ni plus ni moins.

En revanche j'ai les problèmes suivants avec launchd :
(en plus de ce que tu évoques)

- Il est complexe. J'ai pas pris le temps de bien étudier la chose, mais
par exemple que vient faire umask dans launchd ?
Le man ne le dit pas.

- Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
clients les daily ne sont pas exécutés de façon régulière

- "launchctl list" ne dit que si le process est on ou off.
Pour un scheduler c'est pas un peu léger ?
Savoir quand chaque job sera exécuté ne serait pas du luxe.
un "crontab -l", pour peu qu'on saches lire, nous le dit.

- Je ne sais pas quel est le status des bugs de launchd.
Dureste j'ai pas trouvé comment chercher des bug reports qui ne
m'appartiennent pas, donc possiblement ce truc a des problèmes et je ne
peux pas le savoir. Comme il change régulièrement, on est pas à l'abris
d'une coquille. A l'inverse, cron est débuggé depuis des années.

- Je ne connais pas la compatibilité entre les version système, vu que
c'est pas le même entre 10.4, 10.5 et 10.6. Et même si on test de façon
approfondie un truc, rien ne dit qu'il tournera encore après une update
système.

- Le détail qui agace, dans la man page de launchctl :
-w Overrides the Disabled key and sets it to false. In
previous versions, this option would modify the config-
uration file. Now the state of the Disabled key is
stored elsewhere on-disk.
C'est bien la première fois que je vois une man page dire "elsewhere"
ça veux dire quoi ? C'est le jeux des devinettes ? Il y a combien de
façon différentes de gérer la même chose ?

Bref, ça fait 5 ans que launchd est sortit et je ne suis toujours pas
convaincu. Pire, je crois que j'ai toujours rien compris.

--
Nicolas Michel

patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:

In article <4bd6b53b$0$21592$426a74cc@news.free.fr>,
LeBuss <lebuss@free.fr> wrote:

> OK as tu des infos, tuto ou quoi que ce soit pour que je puisse me
> débrouiller avec ça ??

là par exemple :

http://patpro.net/blog/index.php/2008/01/03/131-passer-de-cron-a-launchd/

Merci patpro pour ce blog, que j'ai jamais remarqué
dans ta signature <:o)
Plein de bonnes choses à lire !

Par contre je ne comprends pas pourquoi, alors que tu critiques launchd
tout du long de ton article, tu dis qu'il est buggy, verbeux et
complexe, incompatible avec les versions précédentes de Mac OS X,
pourquoi donc tu continues à dire qu'il faut l'utiliser à la place de
cron !?

Tu penses que Apple va supprimer cron dans une future version ?
Ou que cron a des défaut ?
La seule raison que tu donne, c'est
"Apple a dit d'utiliser launchd, donc on utilise launchd" !?

Perso j'ai des crontab qui tournent depuis la 10.2,
j'ai pas vu le moindre soucis. Pareil pour anacron.
Ils font ce qu'ils sont sensés faire, ni plus ni moins.

En revanche j'ai les problèmes suivants avec launchd :
(en plus de ce que tu évoques)

- Il est complexe. J'ai pas pris le temps de bien étudier la chose, mais
par exemple que vient faire umask dans launchd ?
Le man ne le dit pas.

- Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
clients les daily ne sont pas exécutés de façon régulière

- "launchctl list" ne dit que si le process est on ou off.
Pour un scheduler c'est pas un peu léger ?
Savoir quand chaque job sera exécuté ne serait pas du luxe.
un "crontab -l", pour peu qu'on saches lire, nous le dit.

- Je ne sais pas quel est le status des bugs de launchd.
Dureste j'ai pas trouvé comment chercher des bug reports qui ne
m'appartiennent pas, donc possiblement ce truc a des problèmes et je ne
peux pas le savoir. Comme il change régulièrement, on est pas à l'abris
d'une coquille. A l'inverse, cron est débuggé depuis des années.

- Je ne connais pas la compatibilité entre les version système, vu que
c'est pas le même entre 10.4, 10.5 et 10.6. Et même si on test de façon
approfondie un truc, rien ne dit qu'il tournera encore après une update
système.

- Le détail qui agace, dans la man page de launchctl :
-w Overrides the Disabled key and sets it to false. In
previous versions, this option would modify the config-
uration file. Now the state of the Disabled key is
stored elsewhere on-disk.
C'est bien la première fois que je vois une man page dire "elsewhere"
ça veux dire quoi ? C'est le jeux des devinettes ? Il y a combien de
façon différentes de gérer la même chose ?

Bref, ça fait 5 ans que launchd est sortit et je ne suis toujours pas
convaincu. Pire, je crois que j'ai toujours rien compris.

--
Nicolas Michel

Vous avez filtré cet utilisateur ! Consultez son message

patpro ~ Patrick Proniewski wrote:

In article <4bd6b53b$0$21592$,
LeBuss wrote:

> OK as tu des infos, tuto ou quoi que ce soit pour que je puisse me
> débrouiller avec ça ??

là par exemple :

http://patpro.net/blog/index.php/2008/01/03/131-passer-de-cron-a-launchd/

Merci patpro pour ce blog, que j'ai jamais remarqué
dans ta signature <:o)
Plein de bonnes choses à lire !

Par contre je ne comprends pas pourquoi, alors que tu critiques launchd
tout du long de ton article, tu dis qu'il est buggy, verbeux et
complexe, incompatible avec les versions précédentes de Mac OS X,
pourquoi donc tu continues à dire qu'il faut l'utiliser à la place de
cron !?

Tu penses que Apple va supprimer cron dans une future version ?
Ou que cron a des défaut ?
La seule raison que tu donne, c'est
"Apple a dit d'utiliser launchd, donc on utilise launchd" !?

Perso j'ai des crontab qui tournent depuis la 10.2,
j'ai pas vu le moindre soucis. Pareil pour anacron.
Ils font ce qu'ils sont sensés faire, ni plus ni moins.

En revanche j'ai les problèmes suivants avec launchd :
(en plus de ce que tu évoques)

- Il est complexe. J'ai pas pris le temps de bien étudier la chose, mais
par exemple que vient faire umask dans launchd ?
Le man ne le dit pas.

- Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
clients les daily ne sont pas exécutés de façon régulière

- "launchctl list" ne dit que si le process est on ou off.
Pour un scheduler c'est pas un peu léger ?
Savoir quand chaque job sera exécuté ne serait pas du luxe.
un "crontab -l", pour peu qu'on saches lire, nous le dit.

- Je ne sais pas quel est le status des bugs de launchd.
Dureste j'ai pas trouvé comment chercher des bug reports qui ne
m'appartiennent pas, donc possiblement ce truc a des problèmes et je ne
peux pas le savoir. Comme il change régulièrement, on est pas à l'abris
d'une coquille. A l'inverse, cron est débuggé depuis des années.

- Je ne connais pas la compatibilité entre les version système, vu que
c'est pas le même entre 10.4, 10.5 et 10.6. Et même si on test de façon
approfondie un truc, rien ne dit qu'il tournera encore après une update
système.

- Le détail qui agace, dans la man page de launchctl :
-w Overrides the Disabled key and sets it to false. In
previous versions, this option would modify the config-
uration file. Now the state of the Disabled key is
stored elsewhere on-disk.
C'est bien la première fois que je vois une man page dire "elsewhere"
ça veux dire quoi ? C'est le jeux des devinettes ? Il y a combien de
façon différentes de gérer la même chose ?

Bref, ça fait 5 ans que launchd est sortit et je ne suis toujours pas
convaincu. Pire, je crois que j'ai toujours rien compris.

--
Nicolas Michel

patpro ~ Patrick Proniewski

28/04/2010 à 15:41

In article <1jhnmk4.1njy4jr2h9183N%,
(Nicolas Michel) wrote:

Merci patpro pour ce blog, que j'ai jamais remarqué
dans ta signature <:o)
Plein de bonnes choses à lire !

héhé, merci :)

Par contre je ne comprends pas pourquoi, alors que tu critiques launchd
tout du long de ton article, tu dis qu'il est buggy, verbeux et
complexe, incompatible avec les versions précédentes de Mac OS X,
pourquoi donc tu continues à dire qu'il faut l'utiliser à la place de
cron !?

Parce que c'est la voie tracée par Apple. Si tu résistes, tu finis par
te faire mal, à moins d'être hyper-compétent. Si tu n'aimes pas, il vaut
mieux te tourner vers des alternatives (FreeBSD, Linux...)

Tu penses que Apple va supprimer cron dans une future version ?

nop, j'en doute.

Ou que cron a des défaut ?

il en a, et launchd sait faire bien plus de choses. Mais launchd à
quelques années là ou cron a quelques dizaines d'années.

En revanche j'ai les problèmes suivants avec launchd :
(en plus de ce que tu évoques)

- Il est complexe. J'ai pas pris le temps de bien étudier la chose, mais
par exemple que vient faire umask dans launchd ?
Le man ne le dit pas.

hmmmm
man launchd.plist (10.6) me donne :

Umask <integer>
This optional key specifies what value should be passed to umask(2)
before running the job.
Known bug: Property lists don't support octal, so please convert
the value to decimal.

- Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
clients les daily ne sont pas exécutés de façon régulière

je n'ai pas de souvenir d'échec de cet ordre avec Launchd, par contre
j'ai eu pas mal de problèmes de mails non-envoyés à l'issue de
l'exécution d'un plist.

- "launchctl list" ne dit que si le process est on ou off.
Pour un scheduler c'est pas un peu léger ?
Savoir quand chaque job sera exécuté ne serait pas du luxe.
un "crontab -l", pour peu qu'on saches lire, nous le dit.

C'est sans fin, car launchd fait des tonnes de choses. Si tu commences à
indiquer les données de scheduling, il faut indiquer des données de
WatchPaths, QueueDirectories... et toutes les autres, dans un format
lisible et compact.

- Je ne sais pas quel est le status des bugs de launchd.
Dureste j'ai pas trouvé comment chercher des bug reports qui ne
m'appartiennent pas, donc possiblement ce truc a des problèmes et je ne
peux pas le savoir. Comme il change régulièrement, on est pas à l'abris
d'une coquille. A l'inverse, cron est débuggé depuis des années.

vrai

- Je ne connais pas la compatibilité entre les version système, vu que
c'est pas le même entre 10.4, 10.5 et 10.6. Et même si on test de façon
approfondie un truc, rien ne dit qu'il tournera encore après une update
système.

la compatibilité est plutôt bonne, mais c'est vrai que 10.4-10.5 est une
période charnière pendant la quelle Apple a mélangé allègrement
StartupItems, Launchd, ... le temps que les fonctionnalités de launchd
se stabilisent.

- Le détail qui agace, dans la man page de launchctl :
-w Overrides the Disabled key and sets it to false. In
previous versions, this option would modify the config-
uration file. Now the state of the Disabled key is
stored elsewhere on-disk.
C'est bien la première fois que je vois une man page dire "elsewhere"
ça veux dire quoi ? C'est le jeux des devinettes ? Il y a combien de
façon différentes de gérer la même chose ?

toujours plusieurs, quand on passe de l'une à l'autre. Probablement pour
conserver une compatibilité minimale entre l'ancienne et la nouvelle
version.

Cela dit, c'est clair que le elsewhere on-disk, ça craint !

patpro

--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133

In article <1jhnmk4.1njy4jr2h9183N%NicolasAlex.Michel.remove@epfl.ch>,
NicolasAlex.Michel.remove@epfl.ch (Nicolas Michel) wrote:

Merci patpro pour ce blog, que j'ai jamais remarqué
dans ta signature <:o)
Plein de bonnes choses à lire !

héhé, merci :)

Par contre je ne comprends pas pourquoi, alors que tu critiques launchd
tout du long de ton article, tu dis qu'il est buggy, verbeux et
complexe, incompatible avec les versions précédentes de Mac OS X,
pourquoi donc tu continues à dire qu'il faut l'utiliser à la place de
cron !?

Parce que c'est la voie tracée par Apple. Si tu résistes, tu finis par
te faire mal, à moins d'être hyper-compétent. Si tu n'aimes pas, il vaut
mieux te tourner vers des alternatives (FreeBSD, Linux...)

Tu penses que Apple va supprimer cron dans une future version ?

nop, j'en doute.

Ou que cron a des défaut ?

il en a, et launchd sait faire bien plus de choses. Mais launchd à
quelques années là ou cron a quelques dizaines d'années.

En revanche j'ai les problèmes suivants avec launchd :
(en plus de ce que tu évoques)

- Il est complexe. J'ai pas pris le temps de bien étudier la chose, mais
par exemple que vient faire umask dans launchd ?
Le man ne le dit pas.

hmmmm
man launchd.plist (10.6) me donne :

Umask <integer>
This optional key specifies what value should be passed to umask(2)
before running the job.
Known bug: Property lists don't support octal, so please convert
the value to decimal.

- Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
clients les daily ne sont pas exécutés de façon régulière

je n'ai pas de souvenir d'échec de cet ordre avec Launchd, par contre
j'ai eu pas mal de problèmes de mails non-envoyés à l'issue de
l'exécution d'un plist.

- "launchctl list" ne dit que si le process est on ou off.
Pour un scheduler c'est pas un peu léger ?
Savoir quand chaque job sera exécuté ne serait pas du luxe.
un "crontab -l", pour peu qu'on saches lire, nous le dit.

C'est sans fin, car launchd fait des tonnes de choses. Si tu commences à
indiquer les données de scheduling, il faut indiquer des données de
WatchPaths, QueueDirectories... et toutes les autres, dans un format
lisible et compact.

- Je ne sais pas quel est le status des bugs de launchd.
Dureste j'ai pas trouvé comment chercher des bug reports qui ne
m'appartiennent pas, donc possiblement ce truc a des problèmes et je ne
peux pas le savoir. Comme il change régulièrement, on est pas à l'abris
d'une coquille. A l'inverse, cron est débuggé depuis des années.

vrai

- Je ne connais pas la compatibilité entre les version système, vu que
c'est pas le même entre 10.4, 10.5 et 10.6. Et même si on test de façon
approfondie un truc, rien ne dit qu'il tournera encore après une update
système.

la compatibilité est plutôt bonne, mais c'est vrai que 10.4-10.5 est une
période charnière pendant la quelle Apple a mélangé allègrement
StartupItems, Launchd, ... le temps que les fonctionnalités de launchd
se stabilisent.

- Le détail qui agace, dans la man page de launchctl :
-w Overrides the Disabled key and sets it to false. In
previous versions, this option would modify the config-
uration file. Now the state of the Disabled key is
stored elsewhere on-disk.
C'est bien la première fois que je vois une man page dire "elsewhere"
ça veux dire quoi ? C'est le jeux des devinettes ? Il y a combien de
façon différentes de gérer la même chose ?

toujours plusieurs, quand on passe de l'une à l'autre. Probablement pour
conserver une compatibilité minimale entre l'ancienne et la nouvelle
version.

Cela dit, c'est clair que le elsewhere on-disk, ça craint !

patpro

--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133

Vous avez filtré cet utilisateur ! Consultez son message

In article <1jhnmk4.1njy4jr2h9183N%,
(Nicolas Michel) wrote:

Merci patpro pour ce blog, que j'ai jamais remarqué
dans ta signature <:o)
Plein de bonnes choses à lire !

héhé, merci :)

Par contre je ne comprends pas pourquoi, alors que tu critiques launchd
tout du long de ton article, tu dis qu'il est buggy, verbeux et
complexe, incompatible avec les versions précédentes de Mac OS X,
pourquoi donc tu continues à dire qu'il faut l'utiliser à la place de
cron !?

Parce que c'est la voie tracée par Apple. Si tu résistes, tu finis par
te faire mal, à moins d'être hyper-compétent. Si tu n'aimes pas, il vaut
mieux te tourner vers des alternatives (FreeBSD, Linux...)

Tu penses que Apple va supprimer cron dans une future version ?

nop, j'en doute.

Ou que cron a des défaut ?

il en a, et launchd sait faire bien plus de choses. Mais launchd à
quelques années là ou cron a quelques dizaines d'années.

En revanche j'ai les problèmes suivants avec launchd :
(en plus de ce que tu évoques)

- Il est complexe. J'ai pas pris le temps de bien étudier la chose, mais
par exemple que vient faire umask dans launchd ?
Le man ne le dit pas.

hmmmm
man launchd.plist (10.6) me donne :

Umask <integer>
This optional key specifies what value should be passed to umask(2)
before running the job.
Known bug: Property lists don't support octal, so please convert
the value to decimal.

- Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
clients les daily ne sont pas exécutés de façon régulière

je n'ai pas de souvenir d'échec de cet ordre avec Launchd, par contre
j'ai eu pas mal de problèmes de mails non-envoyés à l'issue de
l'exécution d'un plist.

- "launchctl list" ne dit que si le process est on ou off.
Pour un scheduler c'est pas un peu léger ?
Savoir quand chaque job sera exécuté ne serait pas du luxe.
un "crontab -l", pour peu qu'on saches lire, nous le dit.

C'est sans fin, car launchd fait des tonnes de choses. Si tu commences à
indiquer les données de scheduling, il faut indiquer des données de
WatchPaths, QueueDirectories... et toutes les autres, dans un format
lisible et compact.

- Je ne sais pas quel est le status des bugs de launchd.
Dureste j'ai pas trouvé comment chercher des bug reports qui ne
m'appartiennent pas, donc possiblement ce truc a des problèmes et je ne
peux pas le savoir. Comme il change régulièrement, on est pas à l'abris
d'une coquille. A l'inverse, cron est débuggé depuis des années.

vrai

- Je ne connais pas la compatibilité entre les version système, vu que
c'est pas le même entre 10.4, 10.5 et 10.6. Et même si on test de façon
approfondie un truc, rien ne dit qu'il tournera encore après une update
système.

la compatibilité est plutôt bonne, mais c'est vrai que 10.4-10.5 est une
période charnière pendant la quelle Apple a mélangé allègrement
StartupItems, Launchd, ... le temps que les fonctionnalités de launchd
se stabilisent.

- Le détail qui agace, dans la man page de launchctl :
-w Overrides the Disabled key and sets it to false. In
previous versions, this option would modify the config-
uration file. Now the state of the Disabled key is
stored elsewhere on-disk.
C'est bien la première fois que je vois une man page dire "elsewhere"
ça veux dire quoi ? C'est le jeux des devinettes ? Il y a combien de
façon différentes de gérer la même chose ?

toujours plusieurs, quand on passe de l'une à l'autre. Probablement pour
conserver une compatibilité minimale entre l'ancienne et la nouvelle
version.

Cela dit, c'est clair que le elsewhere on-disk, ça craint !

patpro

--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133

NicolasAlex.Michel.remove

28/04/2010 à 16:53

patpro ~ Patrick Proniewski wrote:

Parce que c'est la voie tracée par Apple. Si tu résistes, tu finis par
te faire mal, à moins d'être hyper-compétent. Si tu n'aimes pas, il vaut
mieux te tourner vers des alternatives (FreeBSD, Linux...)

Il y a du juste dans ce que tu dis :
Je déteste quand un éditeur ne suit pas les recommandation Apple
et se retrouve avec des incompatibilités après une update.

hmmmm
man launchd.plist (10.6) me donne :

Umask <integer>
This optional key specifies what value should be passed to umask(2)
before running the job.

Tien, c'est juste, je m'étais contenté du man de launchctl.

Donc il spécifie la variable umask pour les jobs qu'il gère ?
Logique.

Note que avec cron, on peut spécifier n'importe quelle variable dans la
crontab. On dirait que launchd est pensé pour être utilisé d'abord en
GUI, donc ils limitent les possibilités à des chose qu'ils peuvent
contrôler "à la souris"

> - Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
> clients les daily ne sont pas exécutés de façon régulière

je n'ai pas de souvenir d'échec de cet ordre avec Launchd, par contre
j'ai eu pas mal de problèmes de mails non-envoyés à l'issue de
l'exécution d'un plist.

lorsque je lance via ARD un "grep 2010 /var/log/daily.out"
je constate que la majorité des clients n'ont pas un log régulier.

Le launchDaemon com.apple.periodic-daily.plist dit ceci :

<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>3</integer>
<key>Minute</key>
<integer>15</integer>
</dict>

Est-ce que ça veux dire que une machine éteinte ou en veille à 3h15 ne
fera jamais le daily ?

C'est malin ... mais c'est rassurant.

En fait il faut mettre un StartInterval à la place du
StartCalendarInterval, comme on mettait anacron à la place de cron ?

C'est sans fin, car launchd fait des tonnes de choses. Si tu commences à
indiquer les données de scheduling, il faut indiquer des données de
WatchPaths, QueueDirectories... et toutes les autres, dans un format
lisible et compact.

Je comprends ton argument, mais je trouve qu'une fois de plus le nouveau
machin en fait moins que l'ancien.

Prends ps, il utilise quasiment tout l'alphabet pour te permettre de
sortir l'info spécifique qu'il te faut, là où "launchctl list" ne
propose que l'option -x
Je ne dis pas que je maitrise toutes les subtilités de ps, mais je
connais une ou deux combinaisons classique d'options qui me suffisent et
m'aident bien.

la compatibilité est plutôt bonne, mais c'est vrai que 10.4-10.5 est une
période charnière pendant la quelle Apple a mélangé allègrement
StartupItems, Launchd, ... le temps que les fonctionnalités de launchd
se stabilisent.

Ah oui, c'est vrais, j'avais oublié cet épisode :)

Merci pour ta réponse :)

--
Nicolas Michel

patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:

Parce que c'est la voie tracée par Apple. Si tu résistes, tu finis par
te faire mal, à moins d'être hyper-compétent. Si tu n'aimes pas, il vaut
mieux te tourner vers des alternatives (FreeBSD, Linux...)

Il y a du juste dans ce que tu dis :
Je déteste quand un éditeur ne suit pas les recommandation Apple
et se retrouve avec des incompatibilités après une update.

hmmmm
man launchd.plist (10.6) me donne :

Umask <integer>
This optional key specifies what value should be passed to umask(2)
before running the job.

Tien, c'est juste, je m'étais contenté du man de launchctl.

Donc il spécifie la variable umask pour les jobs qu'il gère ?
Logique.

Note que avec cron, on peut spécifier n'importe quelle variable dans la
crontab. On dirait que launchd est pensé pour être utilisé d'abord en
GUI, donc ils limitent les possibilités à des chose qu'ils peuvent
contrôler "à la souris"

> - Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
> clients les daily ne sont pas exécutés de façon régulière

je n'ai pas de souvenir d'échec de cet ordre avec Launchd, par contre
j'ai eu pas mal de problèmes de mails non-envoyés à l'issue de
l'exécution d'un plist.

lorsque je lance via ARD un "grep 2010 /var/log/daily.out"
je constate que la majorité des clients n'ont pas un log régulier.

Le launchDaemon com.apple.periodic-daily.plist dit ceci :

<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>3</integer>
<key>Minute</key>
<integer>15</integer>
</dict>

Est-ce que ça veux dire que une machine éteinte ou en veille à 3h15 ne
fera jamais le daily ?

C'est malin ... mais c'est rassurant.

En fait il faut mettre un StartInterval à la place du
StartCalendarInterval, comme on mettait anacron à la place de cron ?

C'est sans fin, car launchd fait des tonnes de choses. Si tu commences à
indiquer les données de scheduling, il faut indiquer des données de
WatchPaths, QueueDirectories... et toutes les autres, dans un format
lisible et compact.

Je comprends ton argument, mais je trouve qu'une fois de plus le nouveau
machin en fait moins que l'ancien.

Prends ps, il utilise quasiment tout l'alphabet pour te permettre de
sortir l'info spécifique qu'il te faut, là où "launchctl list" ne
propose que l'option -x
Je ne dis pas que je maitrise toutes les subtilités de ps, mais je
connais une ou deux combinaisons classique d'options qui me suffisent et
m'aident bien.

la compatibilité est plutôt bonne, mais c'est vrai que 10.4-10.5 est une
période charnière pendant la quelle Apple a mélangé allègrement
StartupItems, Launchd, ... le temps que les fonctionnalités de launchd
se stabilisent.

Ah oui, c'est vrais, j'avais oublié cet épisode :)

Merci pour ta réponse :)

--
Nicolas Michel

Vous avez filtré cet utilisateur ! Consultez son message

patpro ~ Patrick Proniewski wrote:

Parce que c'est la voie tracée par Apple. Si tu résistes, tu finis par
te faire mal, à moins d'être hyper-compétent. Si tu n'aimes pas, il vaut
mieux te tourner vers des alternatives (FreeBSD, Linux...)

Il y a du juste dans ce que tu dis :
Je déteste quand un éditeur ne suit pas les recommandation Apple
et se retrouve avec des incompatibilités après une update.

hmmmm
man launchd.plist (10.6) me donne :

Umask <integer>
This optional key specifies what value should be passed to umask(2)
before running the job.

Tien, c'est juste, je m'étais contenté du man de launchctl.

Donc il spécifie la variable umask pour les jobs qu'il gère ?
Logique.

Note que avec cron, on peut spécifier n'importe quelle variable dans la
crontab. On dirait que launchd est pensé pour être utilisé d'abord en
GUI, donc ils limitent les possibilités à des chose qu'ils peuvent
contrôler "à la souris"

> - Je doutes de sa fiabilité. par exemple sur la grosse majorité de mes
> clients les daily ne sont pas exécutés de façon régulière

je n'ai pas de souvenir d'échec de cet ordre avec Launchd, par contre
j'ai eu pas mal de problèmes de mails non-envoyés à l'issue de
l'exécution d'un plist.

lorsque je lance via ARD un "grep 2010 /var/log/daily.out"
je constate que la majorité des clients n'ont pas un log régulier.

Le launchDaemon com.apple.periodic-daily.plist dit ceci :

<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>3</integer>
<key>Minute</key>
<integer>15</integer>
</dict>

Est-ce que ça veux dire que une machine éteinte ou en veille à 3h15 ne
fera jamais le daily ?

C'est malin ... mais c'est rassurant.

En fait il faut mettre un StartInterval à la place du
StartCalendarInterval, comme on mettait anacron à la place de cron ?

C'est sans fin, car launchd fait des tonnes de choses. Si tu commences à
indiquer les données de scheduling, il faut indiquer des données de
WatchPaths, QueueDirectories... et toutes les autres, dans un format
lisible et compact.

Je comprends ton argument, mais je trouve qu'une fois de plus le nouveau
machin en fait moins que l'ancien.

Prends ps, il utilise quasiment tout l'alphabet pour te permettre de
sortir l'info spécifique qu'il te faut, là où "launchctl list" ne
propose que l'option -x
Je ne dis pas que je maitrise toutes les subtilités de ps, mais je
connais une ou deux combinaisons classique d'options qui me suffisent et
m'aident bien.

la compatibilité est plutôt bonne, mais c'est vrai que 10.4-10.5 est une
période charnière pendant la quelle Apple a mélangé allègrement
StartupItems, Launchd, ... le temps que les fonctionnalités de launchd
se stabilisent.

Ah oui, c'est vrais, j'avais oublié cet épisode :)

Merci pour ta réponse :)

--
Nicolas Michel

patpro ~ Patrick Proniewski

28/04/2010 à 17:02

In article <1jho2q4.t22xstospbnN%,
(Nicolas Michel) wrote:

Le launchDaemon com.apple.periodic-daily.plist dit ceci :

<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>3</integer>
<key>Minute</key>
<integer>15</integer>
</dict>

Est-ce que ça veux dire que une machine éteinte ou en veille à 3h15 ne
fera jamais le daily ?

C'est malin ... mais c'est rassurant.

en théorie, Launchd est capable de rattraper son retard sur des jobs
manqué pour cause de veille ou d'extinction. Mais c'est pas
systématique, et je ne me suis pas livré à des tests pour savoir si il
tient compte des écarts entre l'heure de réveil, l'heure de l'exécution
manquée, et l'heure de la prochaine exécution pour décider ou non de
lancer le job.

En fait il faut mettre un StartInterval à la place du
StartCalendarInterval, comme on mettait anacron à la place de cron ?

tu pourrais, oui.

Je comprends ton argument, mais je trouve qu'une fois de plus le nouveau
machin en fait moins que l'ancien.

Tu sais c'est partiellement faux. Tu dis que lire une crontab est
immédiat : pas toujours. Sur un système tu peux avoir des users pour
chaque démon/appli/process, et une crontab utilisateur pour les taches
de maintenance.
ie. je pourrais avoir un user "mantis" avec sa propre crontab, un user
"mailman" avec sa propre crontab, ad lib. Et au lieu de lire une seule
crontab pour avoir les heures de chaque script de maintenance, il
faudrait que j'ai en tête la liste des users ayant une crontab, et que
je les lise toutes.

patpro

--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133

Frédéric Testuz

28/04/2010 à 17:11

Nicolas Michel a couché sur son écran :

Le launchDaemon com.apple.periodic-daily.plist dit ceci :

<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>3</integer>
<key>Minute</key>
<integer>15</integer>
</dict>

Est-ce que ça veux dire que une machine éteinte ou en veille à 3h15 ne
fera jamais le daily ?

C'est malin ... mais c'est rassurant.

Pour compléter les propos de Patrick, j'ai constaté que les scripts
daily, weekly et monthly étaient lancé au réveil si la machine est en
veille, mais pas si la machine est éteinte. (10.5 et 10.6)

--
Frédéric

Patrick Stadelmann

28/04/2010 à 18:33

In article <4bd85013$,
Frédéric Testuz wrote:

Nicolas Michel a couché sur son écran :

> Le launchDaemon com.apple.periodic-daily.plist dit ceci :
>
> <key>StartCalendarInterval</key>
> <dict>
> <key>Hour</key>
> <integer>3</integer>
> <key>Minute</key>
> <integer>15</integer>
> </dict>
>
> Est-ce que ça veux dire que une machine éteinte ou en veille à 3h15 ne
> fera jamais le daily ?
>
> C'est malin ... mais c'est rassurant.

Pour compléter les propos de Patrick, j'ai constaté que les scripts
daily, weekly et monthly étaient lancé au réveil si la machine est en
veille, mais pas si la machine est éteinte. (10.5 et 10.6)

En fait je crois que launchd détermine quand lancer le job la prochaine
fois. Si on éteint la machine tous les soirs, il va chaque matin
déterminer qu'il faut le lancer la nuit suivante (il ne s'occupe pas de
savoir si le script a été exécuté ou pas).

Par contre, la veille ne fait que suspendre le compteur, qui reprend au
réveil : l'effet est que l'exécution du script sera décalée dans le
temps, le décalage correspondant à la durée de veille.

C'est donc pas du tout une fonctionnalité, juste un effet secondaire de
la manière dont launchd lancer periodic.

Patrick
--
Patrick Stadelmann

patpro ~ patrick proniewski

28/04/2010 à 20:41

In article
,
Patrick Stadelmann wrote:

In article <4bd85013$,
Frédéric Testuz wrote:

> Nicolas Michel a couché sur son écran :
>
> > Le launchDaemon com.apple.periodic-daily.plist dit ceci :
> >
> > <key>StartCalendarInterval</key>
> > <dict>
> > <key>Hour</key>
> > <integer>3</integer>
> > <key>Minute</key>
> > <integer>15</integer>
> > </dict>
> >
> > Est-ce que ça veux dire que une machine éteinte ou en veille à 3h15 ne
> > fera jamais le daily ?
> >
> > C'est malin ... mais c'est rassurant.
>
> Pour compléter les propos de Patrick, j'ai constaté que les scripts
> daily, weekly et monthly étaient lancé au réveil si la machine est en
> veille, mais pas si la machine est éteinte. (10.5 et 10.6)

En fait je crois que launchd détermine quand lancer le job la prochaine
fois. Si on éteint la machine tous les soirs, il va chaque matin
déterminer qu'il faut le lancer la nuit suivante (il ne s'occupe pas de
savoir si le script a été exécuté ou pas).

Par contre, la veille ne fait que suspendre le compteur, qui reprend au
réveil : l'effet est que l'exécution du script sera décalée dans le
temps, le décalage correspondant à la durée de veille.

C'est donc pas du tout une fonctionnalité, juste un effet secondaire de
la manière dont launchd lancer periodic.

Merci pour ces précisions intéressantes !

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133

NicolasAlex.Michel.remove

29/04/2010 à 08:27

patpro ~ patrick proniewski wrote:

Merci pour ces précisions intéressantes !

+1
--
Nicolas Michel

CRONTAB

8 réponses

Veuillez sélectionner un problème