• # Crontab

    Posté par  . Évalué à 5. Dernière modification le 27/07/20 à 17:06.

    Utilise la crontab de l'utilisateur www-data
    ex :
    https://askubuntu.com/a/801619

    Pense aussi à le migrer le serveur, il n'y a plus de mise à jour de sécurité pour cette version de Debian

    • [^] # Re: Crontab

      Posté par  . Évalué à 1.

      Merci walter.
      Je n'y avais pas pensé.
      J'attends quand même de voir la solution de Xulops pour l’impersonation www-data par curiosité.

  • # init.d

    Posté par  (site Web personnel) . Évalué à 4.

    Debian 6, c'est pas tout jeune, mais ça doit fonctionner comme ça :
    Imaginons que ton daemon est le script titi.php qui se trouve dans /home/toto, tu vas devoir créer un petit fichier php nommé toto.php pour gérer le lancement et l'arrêt (tu peux tout mettre dans le même script php, mais bon, pourquoi faire bordélique…)
    Tu crées un fichier dans /etc/init.d/toto.sh

    #! /bin/sh
    set -e
    
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/home/toto
    DESC="toto daemon"
    NAME=toto
    DAEMON=/home/toto/$NAME
    PIDFILE=/var/run/$NAME.pid
    SCRIPTNAME=/etc/init.d/$NAME
    
    
    case "$1" in
      start)
          echo -n "Starting $DESC: $NAME"
          php /home/toto/toto.php start
          echo "."
          ;;
      stop)
         echo -n "Stopping $DESC: $NAME"
         php /home/toto/toto.php stop
         echo "."
         ;;
      restart|force-reload)
         echo -n "Restarting $DESC: $NAME"
         php /home/toto/toto.php restart
         sleep 1
         echo "."
         ;;
      *)
         echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
         exit 1
         ;;
    esac
    exit 0
    

    Donc dans toto.php, on a :

    <?php
    
    chdir("/home/toto");
    
    $ordre = $argv[1];
    $fait = "N";
    
    if ($ordre == "") $ordre = "START";
    
    if (strtoupper($ordre) == "START") {
        echo "\r\nDemarrage du daemon titi.\r\n";
        system("php titi.php < /dev/null > /dev/null 2> /dev/null &");
        $fait = "O";
    }
    
    if (strtoupper($ordre) == "STOP") {
        echo "\r\nArret du daemon titi.\r\n";
        // Là à toi de programmer un truc pour que toto.php sache qu'il doive s'arreter 
        $fait = "O";
    }
    
    if (strtoupper($ordre) == "RESTART") {
        echo "\r\nRedemarrage du daemon titi.\r\n";
        // Là à toi de programmer un truc pour que toto.php sache qu'il doive s'arreter 
        // puis
        system("php titi.php < /dev/null > /dev/null 2> /dev/null &");
        $fait = "O";
    }
    
    if ($fait == "N") {
        // affiche l'aide
        echo "\r\nTITI deamon\r\n\r\n";
        echo "commandes :\r\n";
        echo "  start   : demarre le serveur mail\r\n";
        echo "  stop    : arrete le serveur mail\r\n";
        echo "  restart : arrete puis redemarre le serveur mail\r\n";
        echo "  help    : cette page d'aide\r\n\r\n";
    }
    ?>
    

    Comme dit dans le code. c'est à toi de voir comme informer titi qu'il doit cesser. Ca peut être par plein de moyens (fichier scruté, telnet, …).
    Je n'ai pas mis l'option force-reload, tu sauras bien le faire si nécessaire.

    Pour qu'il se lance au (re)démarrage de la machine, faut créer un lien symbolique du fichier sh dans /etc/rc2.d :
    ln -s /etc/init.d/toto.sh /etc/rc2.d/S99toto

    Le S99, c'est pour "Start", et en dernier, ce qui généralement est ok, sauf si tu as besoin qu'il se lance avant d'autres deamons.

    • [^] # Re: init.d

      Posté par  . Évalué à 1.

      Hello,

      Merci Xulops.
      J'ai bien compris le principe.
      Par contre comment faire pour que le script s’exécute en tant que www-data ?
      J'imagine qu'un script /etc/init.d/ linké dans /etc/rc2.d s’exécute avec des droits root même si l'utilisateur root n'est pas loggé?
      Est-ce que donc dans le toto.sh il est raisonnable d'appeler titi.php avec un commande sudo -u www-data?

      Y a t'il une autre façon de faire plus propre ?

      Merci

      • [^] # Re: init.d

        Posté par  (site Web personnel) . Évalué à 2.

        J'avais zappé que tu voulais lancer le daemon avec un autre utilisateur.

        Plutôt que d'utiliser sudo (qui n'est pas installé par défaut sous Debian), utilise su :

        system("su - www-data -c 'php titi.php < /dev/null > /dev/null 2> /dev/null &'");

        A tester…

  • # probleme de definition et CRON

    Posté par  . Évalué à 2. Dernière modification le 28/07/20 à 10:37.

    un script php n'est pas un daemon, il n'attend pas, il se lance, fait son traitement et se termine.

    si tu veux en faire un daemon il faut passer par un service (PHP-FPM, apache/nginx) qui va écouter en permanence et executer le php que tu lui demandes.

    si tu veux juste lancer ton PHP régulièrement, alors le cron est tout indiqué

    exemple un fichier dans /etc/cron.d qui contient les lignes suivantes permettra le lancement toutes les minutes de ton script php

    * * * * * www-data /le/chemin/vers/php-cli /le/chemin/vers/ton/script.php
    • [^] # Re: probleme de definition et CRON

      Posté par  . Évalué à 1.

      Ok merci beaucoup.
      Effectivement s'il faut installer la machinerie php pour que le script s’exécute en permanence il vaut mieux que je passe par le cron.

    • [^] # Re: probleme de definition et CRON

      Posté par  (site Web personnel) . Évalué à 3.

      Ben si, un script php peut très bien tourner tout seul en permanence comme un daemon. Il faut juste qu'il se réveille suivant un événement bien précis.

      Il y a quelques années de ça, je me suis amusé à coder un serveur SMTP et POP en PHP. Un listener sur le port 25 et 110 et ça roule. Pas besoin d'apache ou autre intermédiaire. Il tourne en permanence depuis des années sans problème.

      Comme tout daemon qui se respecte, faut bien faire attention aux allocations mémoires pour ne pas que la ram se fasse bouffer, ça demande un peu de rigueur au codage, mais ce n'est pas pire qu'avec d'autres langages.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.