Forum Linux.debian/ubuntu openswan ne démarre pas, il faut le relancer à chaque reboot

Posté par  (site web personnel) .
Étiquettes :
0
3
avr.
2010
Bonjours à tous,
Je viens de tester openswan sur les distributions ubuntu (9.10 et 10.04) ainsi que debian lenny et le problème est le même sur les 3 :
il me faut relancer /etc/init.d/ipsec restart à chaque démarrage et j'ai le message suivant :
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Removing orphaned /var/run/pluto/pluto.pid:
ipsec_setup: Starting Openswan IPsec U2.6.23/K2.6.32-19-generic-pae...


Qui dit qu'ipsec a bien été lancé à un moment mais n'est plus actif (la 2e ligne), un ps ne me donne aucun processus contenant ipsec et pluto au démarrage mais il est bien lancé suite au restart.

J'ai fait le test avec des distributions fraîchement installées avec seulement l'installation supplémentaire des paquets openswan et xl2tpd, sans toucher à la conf et après chaque redémarrage de la machine il me faut faire un /etc/init.d/ipsec restart pour que le processus soit bien lancé.

Je ne trouve pas de messages d'erreur dans les syslog qui expliquerai le fait qu'il se soit arrêté.

J'ai beau chercher, je ne trouve pas ce qui le fait mourir lors du boot.

Avez vous une solutions ?
  • # ordre des process init ?

    Posté par  . Évalué à 3.

    ton openswan il ne se lancerait pas "avant" que la carte reseau ne soit active ?

    et ton extrait est faux,
    car il montre que Openswan s'arrete, et qu'ensuite il "purge" le pluto.pid
    puis qu'il redemarre

    ce qui semble donc etre l'extrait de ton "restart"
    • [^] # Re: ordre des process init ?

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

      oui l'extrait est suite au restart, mais aucun processus ipsec n'est actif avant le restart, il semble donc que le processus soit lancé, meurt et que le fichier pid soit toujours présent.

      Mais ton idée du openswan qui se lancerai avant la carte réseau a l'air plutôt bonne, j'ai essayé de faire les commandes suivantes update-rc.d -f ipsec remove :
      Removing any system startup links for /etc/init.d/ipsec ...
      /etc/rc0.d/K34ipsec
      /etc/rc6.d/K34ipsec
      /etc/rcS.d/S41ipsec

      puis update-rc.d ipsec defaults
      Adding system startup for /etc/init.d/ipsec ...
      /etc/rc0.d/K20ipsec -> ../init.d/ipsec
      /etc/rc1.d/K20ipsec -> ../init.d/ipsec
      /etc/rc6.d/K20ipsec -> ../init.d/ipsec
      /etc/rc2.d/S20ipsec -> ../init.d/ipsec
      /etc/rc3.d/S20ipsec -> ../init.d/ipsec
      /etc/rc4.d/S20ipsec -> ../init.d/ipsec
      /etc/rc5.d/S20ipsec -> ../init.d/ipsec


      et maintenant ça marche... faut que je me plonge dans l'init de debian pour comprendre le pourquoi du comment de tout ça.

      Mais merci de l'idée, ça a résolu mon problème.

      S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

      • [^] # Re: ordre des process init ?

        Posté par  . Évalué à 3.

        [...]faut que je me plonge dans l'init de debian pour comprendre le pourquoi du comment de tout ça.

        les modes de demarrage ont changé recemment dans plusieurs distributions pour rendre le demarrage plus rapide.

        dans les modifs on trouve entre autres :
        - lancement simultané de certains scripts Init (quand il ne sont pas dependant)
        - reorganisation des dependances
        - reorganisation de l'ordre de certains scripts.

        dans ton cas, on voit il ne se lancait qu'au niveau S (single)
        mais pas dans les autres niveaux

        je penses qu'il s'agit plutot d'un bug dans les scripts d'installation du paquet
        • [^] # Re: ordre des process init ?

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

          ok, j'ai fait remonter ça aux développeurs ubuntu sur launchpad, ils auront peut être le temps de se pencher dessus.

          S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

Suivre le flux des commentaires

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