Journal Debian : contrôle du démarrage des services

Posté par  .
Étiquettes : aucune
0
16
oct.
2005
Cher journal, sur ma debian, j'ai des services installés (daemon). Seulement je ne veux pas qu'ils se lancent tous aux démarrage. Par exemple, j'ai un bind, ntop, etc que je veux lancer au coup par coup selon mon utilisation. Auquel cas j'utilise /etc/init.d/service {start, ...}.

Pour empêcher le démarrage automatique, j'ai 2 solutions :
- update-rc.d -f remove
- des fois il y a un option NODAEMON dans un fichier de conf qui fait que /etc/rc*.d/ ne fait rien.

La première solution semble la meilleure, seulement voilà, à chaque mise-à-jour du paquet, les liens symboliques sont recrées ... Et comme je ne me souviens pas toujours de qui doit faire quoi, je me retrouve au démarrage suivant avec un daemon lancé alors qu'il ne devrait pas.

Quelle est la solution ? Merci

  • # invoke-rc.d

    Posté par  . Évalué à 4.

    On peut aussi utiliser invoke-rc.d service en lieu et place de /etc/init.d/service sous Debian. Je crois même que c'est conseillé.

    Par contre j'ai le même problème que toi, mais pas la solution miracle. Enfin la plupart des paquets ont un /etc/default/... dans lequel on peut configurer ça. Par exemple pour apache2 il suffit de mettre NO_START à 1 dans /etc/default/apache2.

    Pour les paquets qui ne disposent pas de cela il y a bien les .placeholder qui permettent d'interdire à dpkg de toucher à certains fichiers, mais il me semble que les paquets utilisent update-rc.d pour créer les liens dans /etc/rc*.d, et update-rc.d ne respecte pas les .placeholder. Donc il faut modifier les scripts de démarrage pour qu'ils ne démarrent pas le service, ou leur ajouter le support d'un fichier de config dans /etc/default/.

    Sinon tu peux toujours faire un script qui fait des update-rc.d -f remove au démarrage, mais c'est pas top quand même...

    • [^] # Re: invoke-rc.d

      Posté par  . Évalué à 2.

      Il y a aussi sysv-rc-conf qui est plus confortable à l'usage.

      • [^] # Re: invoke-rc.d

        Posté par  . Évalué à 2.

        La petite interface ncurses est sympa pour avoir une vue générale du démarrage du système (mieux qu'un ls /etc/rc*.d ;).
        Par contre c'est pas utilisable dans un script.

  • # les effacer...

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

    ... mais pas tous !

    Normalement, si tu retires les liens pour les runlevels 0, 1, 2, 6 et S, tu devrais être tranquille. Si j'ai bonne mémoire, la prochaine mise à jour du paquet ne touchera à rien tant qu'il restera encore au moins un lien.

    Extrait du man:

    Quand des fichiers /etc/rcrunlevel.d/[SK]??name existent déjà, update-rc.d ne fait rien. C'est ainsi pour que l'administrateur système puisse réarranger les liens -- à condition qu'il en reste au moins un -- sans que sa configuration ne soit réécrite.


    Si un paquet ignore tes modifications alors que tu as respecté la petite règle ci-dessus, c'est un bug qui mérite d'être signalé.

    • [^] # Re: les remplacer...

      Posté par  . Évalué à 1.

      Salut,

      Je ne comprends pas ce passage du manuel de la même façon que toi : s'il existe déjà un lien /etc/rcX.d/S??name, celui-ci n'est pas remplacé. C'est à dire que l'on peut modifier l'ordre d'exécution de ces scripts et que ces modifications sont conservées après les mises à jour.
      En tout cas, il semble possible d'utiliser cela pour éviter le lancement de cetains démons, y compris après une mise à jour : il devrait suffire de créer un lien symbolique /etc/rcX.d/S??name vers un script qui ne fait rien. Lors des mises à jour, le lien symbolique existant, il ne sera pas remplacé.


      JJD

      • [^] # Re: les remplacer...

        Posté par  . Évalué à 3.

        Personnellement, en général, j'ajoute et supprime les liens symboliques dans /etc/rc2.d et je n'ai pas remarqué de réapparition intempestives de liens.

      • [^] # Re: les remplacer...

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

        Je conçois bien que le « /etc/rcrunlevel.d/[SK]??name » puisse porter à confusion, mais je persiste dans ce que j'affirme :

        Un seul lien présent dans n'importe quel runlevel, à n'importe quel niveau de priorité, que ce soit pour l'arrêt ou le démarrage, suffit pour qu'update-rc.d ne fasse rien.

        Un exemple :
        Au runlevel 3, samba doit être démarré...
        hali:/etc/rc3.d# ls -l *samba*
        lrwxrwxrwx 1 root root 15 2005-10-16 12:20 S20samba -> ../init.d/samba

        Si je n'en veux plus :
        hali:/etc/rc3.d# rm S20samba

        Imaginons qu'un script de mise à jour relance update-rc.d :
        hali:/etc/rc3.d# update-rc.d samba defaults 20
        System startup links for /etc/init.d/samba already exist.

        Résultat :
        hali:/etc/rc3.d# ls -l S20samba
        ls: S20samba: Aucun fichier ou répertoire de ce type


        La configuration n'a pas été modifiée.
        Comme dit juste au dessus, il suffit généralement de retirer le lien de rc2.d et il ne reviendra pas.

        • [^] # Re: les remplacer...

          Posté par  . Évalué à 1.

          si tu retire le lien et que tu fais un apt-get remove puis install
          un package il va te relancer le démon à la fin de l'install.

          Par contre si tu renomme ton lien en K00 il ne relance pas
          le démon à la fin de l'install, c'est ce que veut benoit il me semble.

  • # En GUI

    Posté par  (Mastodon) . Évalué à 1.

    Il y a des GUI pour configurer ça, au moins dans unstable:
    - bum
    - services-admin, qui fait partie du package gnome-system-tools, et donc les fonctionnalités fluctuent au fil des versions. À une époque il était pas mal, puis il a disparu, et maintenant il est revenu mais il a l'air beaucoup trop simplifié.

  • # ...

    Posté par  . Évalué à 2.

    Quelle est la solution ? Merci
    Perso je fais un truc un peu crade, mais qui marche pas trop mal :
    je modifie directement le /etc/init.d/* pour que start ne fasse rien et que startm lance le service.

    Lors de la mise a jour des paquets, la plupart te demande s'il faut remplacer le script qui a été personnalisé.

  • # Démarrage manuel

    Posté par  . Évalué à 1.

    Certains scripts le prévoit et demande si ils doivent être lancer au démarrage.
    Pour les autres je rajoute la ligne suivante au début du script:
    exemple pour apache: [ "$0" = "/etc/init.d/apache" ] || exit 0 # Starts only manually

  • # rcconf

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

    j'aime bien rcconf aussi... package en stable, testing, unstable!

    • [^] # Re: rcconf

      Posté par  . Évalué à 1.

      très simple et efficasse !
      merci :)

      comment ça se fait qu'avec rcconf, je vois plus de services qu'avec services-admin ? est-ce qu'il y sont tous ?

      de plus j'ai regardé dans le montieur système pour voir la place en mémoir occupé par des services. J'ai trouvé samba (smbd) mais j'ai pas trouvé ppp qui est actif d'après rcconf. Vous savez pouquoi ?

    • [^] # Re: rcconf

      Posté par  . Évalué à 1.

      sur le papier ça a l'air bien, mais le paquet est pété :/ À suivre.

      • [^] # Re: rcconf

        Posté par  . Évalué à 1.

        Oui. Il ne marche plus sur ma unstable ppc. Comme j'ai dit plus haut, sysv-rc-conf le remplace davantagement.

        • [^] # Re: rcconf

          Posté par  . Évalué à -1.

          je ne vois pas en quoi ça va empêcher la MAJ d'un paquet de tout foutre en l'air.

        • [^] # Re: rcconf

          Posté par  . Évalué à 1.

          J'utilise sysv-rc-conf aussi et j'en suis satisfait. Je n'ai pas rencontré le problème décrit dans ce journal ( voir l'explication de Amand Tihon plus haut ). Par contre je me demande bien comment fonctionnent les programmes simplifiés comme rcconf ou services-admin. Ça n'édite que le runlevel courant ? quel priorité ? (20 pour rcconf d'aprés le man. ). Du coup, j'ai pas du tout confiance dans ces outils. J'ai l'impression que parfois, à force de trop simplifier, on finit par compliquer les choses.

  • # Il faux recréer les liens symboliques

    Posté par  (site web personnel) . Évalué à 1.

    Il faut recréer les liens symboliques pour que la mise à jour du paquet ne les recréent pas :

    # update-rc.d -f remove apache
    # update-rc.d apache stop 0 1 2 3 4 5 6 .

    (en gros tu dis quel que soit le runlevel, apache est arrêté)

    • [^] # Re: Il faux recréer les liens symboliques

      Posté par  . Évalué à 0.

      c'est bien ce que je dis ... on peut pas s'amuser à faire ça à chaque mise à jour. Déjà que la MAJ d'un daemon relance le service même s'il n'est pas lancé ... c'est lourd. Dangereux en fait. Une MAJ peut amener à faire des changements de configuration. Je trouve ça dangereux de relancer le programme avec des options qui peuvent être désormais invalides.

      • [^] # Re: Il faux recréer les liens symboliques

        Posté par  . Évalué à 0.

        la solution c'est comme dit plus haut rcconf, maintenant si ce
        package ne fonctionne pas tu peu faire la même chose à la
        main en changeant le lien dans ton rc2.d en remplaçant S?? par K00

        exemple:

        S20lpd -> K00lpd

        • [^] # Re: Il faux recréer les liens symboliques

          Posté par  . Évalué à 0.

          oops j'ai pas été très clair.

          Il faut juste renommer le lien.

          • [^] # Re: Il faux recréer les liens symboliques

            Posté par  . Évalué à 1.

            Je renomme le lien avec un "s" ou un "k" (noter la minuscule). Les liens ne sont utilisés que quand ils débutent avec une majuscule.
            Et au passage je ne perds pas l'information de l'ordre auquel le service était lancé :-)

Suivre le flux des commentaires

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