Au risque d'en décevoir certain, dans la majorité des cas, je pense que la réponse est négative.

Si j'ai écris un certain nombre de démons, c'était pour répondre à des besoins strictement personnels, et ceci pour deux raisons.

Tout d'abord, j'avais envie de m'amuser, et le challenge me semblait à chaque fois intéressant.

C'est d'ailleurs pour cette raison que le gestionnaire de fenêtre que j'utilise sous FreeBSD utilise des démons écrit en PHP pour interagir avec l'utilisateur.

Ensuite, je n'ai jamais rencontré dans mon contexte professionnelle un cas de figure qui nécessité la mise en œuvre d'un démon.

En effet, dans tous les cas, un script régie via l'utilitaire cron s'est révélé bien plus adapté, pour plusieurs raisons.

Tout d'abord, indépendamment de son écriture, un démon est bien plus complexe à mettre en œuvre qu'un script déclenché à intervalle régulier par cron.

Il est en effet nécessaire de faire en sorte que le démon se lance au démarrage (ou au redémarrage en cas de plantage) du serveur physique, et qu'il puisse également être arrêté ou redemarré.

Or, bien souvent, cela passe par l'écriture de un ou plusieurs scripts, souvent écrit en sh,  et dont la structure est bien souvent spécifiques au système d'exploitation.

De fait, la portabilité de ces scripts, et donc du démon qu'ils gèrent, est donc problématique.

Avec un script dirigé par cron, ce problème n'existe pas, puisque cet utilitaire est disponible sur tout les UNIX, et que de plus son fonctionnement est identique indépendamment du système d'exploitation.

Autre argument en faveur de l'utilisation de cron, ce dernier avertira l'administrateur de la machine si jamais le script rencontre un problème lors de son exécution, puisqu'il capture la sortie standard et la sortie d'erreur des scripts qu'il exécute et envoie le courrier électronique correspondant si le script exécuté a écrit sur l'une ou l'autre.

Enfin, si PHP en lui-même n'a pas de fuites de mémoire significative, ce n'est pas forcément le cas des extensions qu'un démon peut être amené à mettre en œuvre. Si cela n'est pas un problème avec cron, puisque le script est exécuté à intervalle régulier qu'en conséquence, les ressources mémoires qu'il consomme seront forcément libérées, ce n'est pas le cas avec un démon, qui par définition est destiné à tourner en permanence.

Donc, si le démon se révèle avoir des fuites de mémoire, dans le meilleur des cas, il atteindra la limite de mémoire autorité par la configuration de PHP et s'arrêtera de lui-même, et dans le pire des cas, il finira par consommer l'intégralité de la RAM disponible, compromettant ainsi le bon fonctionnement du serveur.

Enfin, changer la configuration d'un démon nécessite de pouvoir soit lui faire relire sa configuration dynamiquement, soit de l'arrêter et de le redémarrer.

Dans le cas d'une solution basée sur cron, cela n'est pas nécessaire, puisque le script peut aller lire sa configuration lors de chaque démarrage.

Il suffit donc de modifier le fichier de configuration pour que les nouveaux paramètres soient automatiquement pris en compte, alors que dans le cas du démon, il faudra en plus demander au démon de relire sa configuration, soit l'arrêter et le redémarrer.

Bref, cron est une solution plus simple et plus fiable techniquement, qui ne risque pas d'altérer le bon fonctionnement du serveur, et qui plus facile à gérer au quotidien.

Cela ne veut cependant pas dire que la solution du démon est à rejeter systématiquement.

Dans certain cas, elle est même incontournable, comme par exemple ceux ou la ou les tâches doivent être exécutées non pas à intervalle régulier, mais en fonction d'un événement ou bien lorsqu'il faut exécuter ces tâches le plus rapidement possible ou avec une granularité inférieure à la minute.

Il faut cependant l'utiliser en ayant bien conscience de tout ce qu'elle implique en terme de contraintes, et surtout que PHP n'est pas le langage le plus adapté pour cela, même s'il est parfaitement outillé pour le faire.