Forum Linux.debian/ubuntu systemd et script au shutdown...

Posté par (page perso) . Licence CC by-sa
Tags :
2
9
mai
2016

Salut les ubuntueros,

j'ai récemment après une mise a jours raté vers 16.04 installer 16.04 tout neuf…

Et le problème et que j'avais un script qui se déclenchait lors d'un shutdown ou d'un reboot.
Avant (14.04).
Rien de compliquer a cela: mettre des liens dans /etc/rc0.d/ et /etc/rc6.d/ + rétro-compatibilité avec SysV et voila.

Mais maintenant malgré mes tags LSB correctes et le .service de systemd je n'arrive pas a faire remarcher mon script.

Tag LSB:

#! /bin/sh
### BEGIN INIT INFO
# Provides:              my_script
# Required-Start:    $local_fs 
# Required-Stop:     $local_fs 
# Default-Start:     
# Default-Stop:      0 6
# Short-Description: short description
# Description:       my long description
### END INIT INFO

Et puis lancer update-rc.d depuis

# systemd my_script enable # Something like this.

ou directement ne fonctionne pas…

# update-rc.d -f my_script defaults
# update-rc.d -f my_script enable

J'ai tout tenter (y compris modifier les LSB Tags en mettant 2 3 4 5 a Default-Start, faire des fonctions do_start() & do_end(), inclure les libs…) je n'y arrive pas.

J'ai même essayer de faire un service systemd.

Toute aide est la bienvenue car mettre un truc au démarrage est facile mais le mettre au shutdown c'est peut être impossible ?

Merci pour votre précieuse aide et vos réponses éclairées illuminant les ténèbres de mon ignorance.

  • # dependance ?

    Posté par . Évalué à 4.

    Required-Stop: $local_fs

    il ne se passe peut-etre rien car ton script depend d'un truc qui est dans $local_fs
    je ne suis pas un expert en LSB/Systemd mais je penses que ton script ne se lancera pas tant que $local_fs ne sera pas executé.

    donc les questions a se poser :
    - $local_fs est-il executé lors de l'arret/redemarrage de la machine ?
    - $local_fs ne demonte-t-il pas les disques lors de ce passage, et donc ton script ne pourrait plus s'executer ?

    • [^] # Re: dependance ?

      Posté par (page perso) . Évalué à -1.

      Je ne suis pas un expert non-plus, je découvre plutôt systemd, mais je crois que justement comme c'est une dépendance ( $local_fs ) il faut qu'elle soit résolus et donc systemd devrait faire en sorte qu'elle le soit.

      Comme dépendance j'ai besoin de python2 et du système de fichier.

      Et ça fait ch|€zzzzzzzzzz…

      C'était tellement plus simple avec le système V et init.

      Le plus grave dans l'affaire est que ce script est important, car il somme l'uptime et du coup j'en tire des stats et actuellement donc je n'ai pas de données et il semble que personne ne sache me répondre (3 forums différents)…

  • # start stop

    Posté par . Évalué à 4.

    Default-Start: run_level_1 [run_level_2…]
    Default-Stop: run_level_1 [run_level_2…]
    defines the run levels where the script should be started (stopped) by default. For example, if a service should run in runlevels 3, 4, and 5 only, specify "Default-Start: 3 4 5" and "Default-Stop: 0 1 2 6".

    # Default-Start:
    # Default-Stop:      0 6
    

    Ton script veut être actif en runlevel 6 et en runlevel 0, donc c'est à inverser.

    Tu veux aussi probablement mettre le fs et autre
    en
    X-Start-Before: boot_facility_1 [boot_facility_2…]

    • [^] # Re: start stop

      Posté par (page perso) . Évalué à 1. Dernière modification le 10/05/16 à 21:41.

      Désolé mais ce que je ne comprends pas c'est que mon script est un script donc une procédure a exécuter une fois au shutdown et donc pas un daemon que l'on stoppe et que l'on démarre.

      D'ailleurs d'après ce que je comprends c'est que le passage d'arguments start et stop au script n'est plus garantie.

      Pour moi le runlevel 0 est celui dans lequel entre le système, a l'arrèt (halt).

      Et le runlevel 6 celui lors d'une séquence de reboot au lieu de passer par le runlevel 0.

      Donc en étant un humble hacker comme vous tous armer de manpages, info books et autres moyens de connaître mieux son système, j'ai aussi regarder la structure des scripts présents aux runlevels 0 1 6, et la terminologie

      [K|S][0-9]{2} 
      

      de préfix… (Le K étant aussi présent aussi au runlevel 1 et j'ai également essayer).

      Concernant les liens dans /etc/rc[0|1|6].d

      Apparemment cela fonctionne très bien systemd au démarrage mais y a un problème a l'arrêt car j'ai remarquer que mon ordinateur mets une éternité a s'éteindre poweroff.

      Je vais essayer le Default-Start proposer comme solution, a mon dilemme.

      En espérant que cela fonctionne je vous remercie sincèrement pour vos réponses.

  • # faire des vrai services systemd

    Posté par . Évalué à 6.

    Si je comprends bien ton besoin, tu veux qu'un script s'exécute au démarrage du système et un autre à l'arrêt.
    Tu avais fait ça en utilisant les actions start et stop d'un init script sysV, mais j'ai l'impression que ce n'est pas vraiment le fonctionnement prévu pour ces scripts et que ça fonctionnait par effet de bord (l'init sysV traditionnel n'ayant aucun moyen de savoir si un service fonctionne encore vraiment, il lance tous les stop prévu, qu'il y ait quelque chose à arrêter ou pas).

    Systemd a essayer de maintenir autant que possible la compatibilité avec ces scripts d'init, mais il a visé le fonctionnement normal et le scripts qui comptaient sur un effet de bord des limitations d'init sysV ne vont plus forcément fonctionner comme prévu.
    En l'occurrence, je pense que systemd constate, après avoir démarré ton «service» qu'il ne reste plus aucun processus qui tourne et en conclu que le service s'est terminé et qu'il n'y a donc plus rien à arrêter.

    La solution est de faire un vrai service systemd en tenant compte du fonctionnement (documenté!) de systemd.
    Je te recommande de lire les pages de manuel systemd.unit systemd.service et systemd.exec.

    En particulier, je pense que l'option importante pour ce que tu veux faire est RemainAfterExit (dans le man systemd.service) qui permet de dire à systemd que le service doit encore être considéré comme actif même si tous les processus se sont terminés.
    Tu combine ça avec ExecStart et ExecStop pour définir les scripts à exécuter au démarrage et à l'arrêt (le Type par défaut simple devrait faire l'affaire).
    Tu ajoute une section Install où tu indique que ton service est WantedBy multi-user.target (ou celui qui est le plus adapté à ce que tu veux faire).
    Un fois que tu systemctl enable ton service il devrait être automatiquement démarré au boot et arrêté au shutdown (parce que par défaut tous les services sont arrêtés au suhtdown, cf le paramètre DefaultDependencies dans man systemd.unit).

    Note que si tu veux en plus que ton service soit arrêté quand le système est mis en veille et relancé quand il sort de veille, c'est plus compliqué (j'ai une solution qui fonctionne, mais elle n'est pas très élégante).

    • [^] # Re: faire des vrai services systemd [Résolu]

      Posté par (page perso) . Évalué à 2. Dernière modification le 15/05/16 à 05:00.

      Bonjours,

      Je pense que tu te trompe sur mes intentions, mais ce n'est pas grave, car il me semble que si le problème ne serai résolu tu saurai m'aider.

      Je voulais simplement mettre un script (processus pas daemon) a l'arrêt (shutdown) que ce soit un reboot ou un halt.
      

      Et j'ai réussis grâce la réro-compatiblité SysV et les nouveau tag LSB l'accompagnant si j'ai bien compris.

      #! /bin/sh
      ### BEGIN INIT INFO
      # Provides:          my_script
      # Required-Start:    $local_fs $time
      # Required-Stop:     $local_fs 
      # X-Start-Before:    # Un service se trouvant dans /etc/rc0.d et /etc/rc6.d 
      # X-Stop-Before:     # Un service se trouvant dans /etc/rc0.d et /etc/rc6.d 
      # Default-Start:     S    
      # Default-Stop:      0 6
      # Short-Description: short description
      # Description:       my long description
      ### END INIT INFO
      

      Voila le problème est résolu. Mais je ne sais si mon bricolage va tenir longtemps étant donner la précarité de celui-ci.

Suivre le flux des commentaires

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