Distribution EOLE » Commun » eole-common

Je ne sais pas lancer de script en post-up que si la dernière interface est lancé et non à chaque "up" des interfaces.

Sur Amon aussi, creole_serv est lancé par bastion.
Je n'ai pas le problème sur un Amon de test.

Reboot du serveur Amon du collège la Parc : -> pas de souci, creole_serv se lance.

Salut,

Je pense bien que l'on ait des cas de bug similaire...
Sur un Amon 2.3.9, aprés reboot le service bastion (et donc creole_serv aussi) ne se lance pas, malgré la présence des commandes en post-up:

auto eth4
    iface eth4 inet static
    address 10.105.22.55
    netmask 255.255.255.192
    broadcast 10.105.22.63
    network 10.105.22.0
    post-up /sbin/restart-wrapper rsyslog
    post-up /etc/init.d/bastion restart

Même constat si on crée un script dans /etc/network/if-post-up.d/ qui lance bastion. Aurait-on un bug?

Je précise qu'un "ifdown eth4 && ifup eth4" relance bien bastion et lance creole_serv...

Pour complément d'informations, voici ce que mon collègue a constaté hier :

le 10/12/2013, lors d'une mise à jour d'un serveur A (Maj-Auto -E) en Horus 2.3.9 vers une version complète 2.3.11, suivi d'un reconfigure et un reboot.

Nous lançons un diagnose sur le serveur, ce qui nous a permis de relever l'erreur suivante:

creole_serv => Erreur

Nous avions fait exactement la même mise à jour sur serveur *B *le mardi précédent (03/12/2013) sans avoir ce problème.

Je lance donc la commande suivante "Maj-Auto -s -E" sur le serveur B, ce qui me permet de constater que la version 2.3.11 comporte 5 nouvelles mise à jour.

eole-sso (2.3-eole101+1)
     eole-sso-client (2.3-eole101+1)
     libculr3 (7.19.7-1ubuntu1.5)
     libcurl3-gnutls (7.19.7-1ubuntu1.5)
     python-eolelaptor (2.3-eole101+1)

Pour ma part je ne sais pas à quoi sert le "creole_serv", mais quand on lance la commande "/etc/init.d/creole_serv status" le serveur A nous indique que celui ci n'est pas lancé

Quand je lance la commande "/etc/init.d/creole_serv start", le module se lance et le diagnose est OK.

Conclusion, je pense que la mise à jour d'un paquet semble avoir une incidence sur le module "creole_serv" qui ne se lance pas automatiquement à l'amorçage de la machine.

en complément : nous constatons le pb sur amon, scribe et horus mais a priori c'est uniquement sur ce dernier module qu'il y a un impact : le horus n'est pas visible dans le voisinage réseau et les partages (lecteurs) ne se montent pas.
Je confirme que c'est souvent au reboot que nous constatons ce pb et qu'un service creole_serv restart règle le pb...

Autre conséquence possible de ce problème : sur AmonEcole après un reboot les services Controle-Vnc et Controle-Vnc (Web) sont en erreur.

Reproduit ce jour sur l'Amon du Parc en utilisant : Maj-Auto -CR avec une maj noyau !

Cependant, impossible à reproduire sur mes maquettes...

je viens de tester mais le service ne se lance pas mieux... (testé en rebootant le serveur ; un scribe dans le cas présent).

équipe eole Academie d'Orléans-Tours a écrit :

je viens de tester mais le service ne se lance pas mieux... (testé en rebootant le serveur ; un scribe dans le cas présent).

Est-il possible de tester en ajoutant la redirection dans /etc/network/interfaces ?

• avant: post-up /etc/init.d/bastion restart
• après: post-up /etc/init.d/bastion restart > /dev/null 2>&1

Si cela ne fonctionne pas, il faudra voir pour faire comme dans #7861.

Bonjour,

Modification effectuée :
start-stop-daemon --start --exec $DAEMON -- $DAEMON_ARGS --pidfile $PIDFILE --logfile /var/log/creole_serv/creole_serv.log > /dev/null 2>&1
post-up /etc/init.d/bastion restart > /dev/null 2>&1

Cela sur le même scribe que précédemment, reboot, creole_serv toujours en erreur. Rien au niveau des log, on ne voit que l'arret du serveur (14h21):
2014/05/21 14:21:25 CEST [-] Received SIGTERM, shutting down.
2014/05/21 14:21:25 CEST [-] (Port 4333 Closed)
2014/05/21 14:21:25 CEST [-] Stopping factory <twisted.web.server.Site instance at 0x9d7666c>
2014/05/21 14:21:25 CEST [-] Main loop terminated.
2014/05/21 14:21:25 CEST [-] Server Shut Down.

Pour Si cela ne fonctionne pas, il faudra voir pour faire comme dans #7861. => que faut-il modifier exactement?

équipe eole Academie d'Orléans-Tours a écrit :

Pour Si cela ne fonctionne pas, il faudra voir pour faire comme dans #7861. => que faut-il modifier exactement?

1. modifier /etc/network/interfaces pour que bastion ne soit pas démarrer pendant la phase de démarrage des interfaces réseaux
   

   auto eth1
   [...]
       post-up test "$(runlevel)" = unknown || /sbin/restart-wrapper rsyslog
       post-up test "$(runlevel)" = unknown || /etc/init.d/bastion restart
   

2. Activer la gestion de creole_serv pendant les phases de démarrage/arrêt
   

   root@server:# update-rc.d creole_serv defaults 19 90
   

3. Activer la gestion de bastion pendant les phases de démarrage/arrêt
   

   root@server:# update-rc.d bastion defaults 90 19
   

Ainsi :

• Au démarrage
  1. Les interfaces réseaux sont mises en service, le runlevel est unknown, bastion n’est donc pas démarré
  2. creole_serv est démarré très tôt par les scripts d’init
  3. bastion est démarré plus tard
• À l’arrêt
  1. bastion est arrêté très tôt par les scripts d’init
  2. creole_serv est arrêté presque à la fin
• Lors d’un reconfigure
  1. Les interfaces réseaux sont arrêtées puis démarrées, le runlevel n’est pas unknown, bastion est donc pas redémarré

ça marche en appliquant ces modifs (2 reboots sans modif -> creole_serv planté ; 2 reboots avec modifs -> creole_serv OK).

• un "up sleep 1" avant up bastion start (dans interfaces) --> creole_serv démarre
• Redirection des sorties dans un fichier par un script qui lance bastion --> creole_serv démarre
  ....

Pas de solution satisfaisante.
Un problème de lancement de bastion sur Eole 2.4 se pose. Une solution est proposée. Le backport en 2.3 serait à envisager.