Aller au contenu
Règlement du forum ×
IPTV et arnaques ×

Ubuntu - insserv - très dangereux !


djezzyman

Messages recommandés

J'utilise Ubuntu depuis quelques jours et à chaque démarrage le message suivant apparait:

 

EXT3FS: recovery required on read-only filesystem ...

 

Ce système de fichier est la racine (/) ce qui signifie que la racine n'est pas démontée correctement avant le reboot ou le stop.

 

Après investigation j'ai pu constaté qu'aucun système de fichier n'est démonté.

 

Le problème est du à l'utilisation de insserv. Commande qui m'a permis de désactiver certains services.

 

insserv à un bug sérieux semble-t-il. Lorsque l'on reboot on entre dans le runlevel 6, le système exécute les scripts présents dans le répertoire /etc/rc6.d, (en fait des liens vers les scripts de /etc/init.d) lançant d'abord ceux commençant par K puis ceux commençant par S. C'est un héritage de Unix System V. Chaque script se voit affecté un préfixe en K ou S et un numéro compris entre 00 et 99. Le système les lance dans l'ordre numérique puis lexicographique pour ceux ayant le même numéro.

 

Mais insserv attribue a reboot le préfixe S01 , alors qu'il attribue à umountfs, umountroot et sendsigs (arrêt des processus) le même numéro mais leur nom commence par u et s, ils sont donc lancés après. Donc le script /etc/init.d/reboot (tout comme /etc/init.d/halt dans le runlevel 0) redémarre (stop) sans avoir invité les processus restant à quitter et sans avoir démonté les systèmes de fichier montés.

 

Me voilà donc obligé de gérer les liens des répertoires /etc/rc6.d (reboot) et /etc/rc0.d (halt) à la main. A chaque utilisation de insserv ils sont perdus.

 

Si quelqu'un connait une meilleur solution merci de m'en informer.

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

sysvconfig est l'équivalent sous debian de system-config-services sous RedHat et Fedora.

 

De toute évidence je vais me fier à cette utilitaire plutôt qu'à insserv dont je ne comprend pas ce qu'il fait encore dans la distribution Ubuntu. insserv inverse tout simplement l'ordre dans lequel les scripts critiques doivent être lancés, tout du moins lors de l'arrêt du système. Au point que je me demande s'il ne faut pas revoir complètement le contenu des dossiers /etc/rc*.d/.

 

Menu principal:

 

sysvconfig-1.jpg

 

Activation/Désactivation des services

 

sysvconfig-2.jpg

 

Source : http://www.cyberciti.biz

 

Ubuntu / Debian Linux: Services Configuration Tool to Start / Stop System Services

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

Je vais l'essayer aussi. L'arborescence /etc/rc?.d est endommagée. J'espère pouvoir revenir à la normale mais c'est compliqué. Même en relançant les configurations post-installation des paquets intégrant un service j'ai des problème avec l'ordre dans lequel les scripts sont lancés.

 

Je vais tenter de générer un script de récupération à partir des scripts post-installaton du dossier /var/lib/dpkg/info.

 

Merci.

Lien vers le commentaire
Partager sur d’autres sites

Utiliser le Live CD est une bonne idée je vais monter l'image squashfs du live CD pour voir. De toute façon j'ai téléchargé le DVD et j'ai copié l'arborescence dans une partition ext3 dédiée. Je peux au choix démarrer Ubuntu ou le DVD depuis le disque dur. Ce n'est pas dur avec GRUB.

 

J'ai déjà récupéré les configurations d'origine depuis les scripts postinst de la base de donnée dpkg. Les scripts sont en fait des fichiers texte situés dans le dossier /var/lib/dpgk/info/, ils ont l'extension .postinst.

 

Les paquets débian utilisent update-rc.d pour installer et supprimer les liens vers les services. Le paquet initscripts installe les services du niveau S ( phase du boot non interactive et utilisée aussi en mode recovery). Il définie une fonction updatercd qui appelle le vrai update-rc.d avec les mêmes arguments:

 

Voici la partie interessante de la sortie de la commande: grep -E "update\-?rc" /var/lib/dpkg/info/initscripts.postinst

 

updatercd mountkernfs.sh start 1 S .

updatercd hostname.sh start 2 S .

updatercd mountdevsubfs.sh start 11 S .

#updatercd bootlogd start 5 S .

updatercd checkroot.sh start 20 S .

updatercd mtab.sh start 22 S .

updatercd checkfs.sh start 30 S .

updatercd mountall.sh start 35 S .

updatercd mountall-bootclean.sh start 36 S .

updatercd mountoverflowtmp start 37 S . stop 63 0 6 .

updatercd mountnfs.sh start 45 S .

updatercd mountnfs-bootclean.sh start 46 S .

updatercd bootmisc.sh start 55 S .

updatercd urandom start 55 S . start 30 0 6 .

updatercd halt start 90 0 .

updatercd reboot start 90 6 .

updatercd umountroot start 60 0 6 .

updatercd umountfs start 40 0 6 .

updatercd umountnfs.sh start 31 0 6 .

updatercd sendsigs start 20 0 6 .

updatercd killprocs start 30 1 .

updatercd single start 90 1 .

updatercd bootlogs.sh start 70 1 2 3 4 5 .

updatercd ondemand start 99 2 3 4 5 .

updatercd rc.local start 99 2 3 4 5 .

updatercd rmnologin start 99 2 3 4 5 .

#updatercd stop-bootlogd-single start 99 S .

#updatercd stop-bootlogd start 99 2 3 4 5 .

 

On y voit par exemple que halt et boot ont le numéro 90 avec le préfixe S alors que insserv leur attribue le numéro 01 avec le même préfixe. Ils sont donc lancés les derniers alors qu'avec insserv ils étaient lancés les premiers.

 

Le runlevel S contient pas mal de scripts critiques (checkfs mountall) et une initialisation désordonnée peut être catastrophique.

 

J'ai pu ainsi retrouvé la commande d'installation de chaque service.

 

grep -E "update\-?rc" /var/lib/dpkg/info/*.postinst

 

et généré un script de réinstallation après avoir supprimé tous les liens des dossiers /etc/rc*.d/.

 

Avec rpm les informations sur les paquets sont contenus dans une base de donnée au format Berkeley DB3 (ou DB4). On obtient les scripts avec la commande:

 

rpm -q --scripts nom-du-paquet

 

La sortie est un peu plus compliquée à traiter que sous débian car tous les scripts (preinst postinst preuninst postuinst ...) sont affichées en même temps.

 

Conclusion:

 

Toujours utiliser update-rc.d pour gérer les services actifs ou non au démarrage.

 

Pour désactiver un service au démarrage:

 

update-rc.d -f nom-du-service remove

 

Pour le réactiver se référer au script d'installation pour récupérer les paramètres de la commande update-rc.d. Par exemple pour gdm:

 

update-rc.d gdm defaults 30 01

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

Content que ton problème sois résolu, n'oublie de le mettre dans le titre :)

 

Voyant tes compétences, je te conseille d'essayer Archlinux, on plus tu ne risque pas d'avoir le même problème et qui te permet de connaitre mieux GNU/Linux, car elle n'a pas d'outils spécifique à elle :)

 

Bahhh... y'a pas d'outils graphiques sous archlinux mais c'est quand même mieux foutu que sous certaines autres distrib... là sous Debian des fois je galère pour un rien...enfin bon... j'ai enfin retenu les différentes commandes d'apt-get, apt-cache et apt-file... Là on s'asmuse avec chroot et debootstrap en TP.

Lien vers le commentaire
Partager sur d’autres sites

Je vais essayer ArchLinux. Cela ne coute rien.

 

Je commence à me faire à cette distribution Ubuntu mais il demeure des problèmes majeurs.

 

Comme le support Selinux. J'ai du compilé le noyau 2.6.31 et abandonner le noyau Ubuntu. De plus Ubuntu utilise un système de fichier tmpfs en mémoire pour les dossiers /var/run et /var/lock par exemple. Ils sont montés à chaque démarrage et démontés à l'arrêt. Or le dossier /var/run est utilisé par les services pour y stocker leurs fichiers .pid ou fichiers de socket pour les communications unix dans un sous dossier portant leur nom (dbus, setroubleshoot, cupsd, avahi-daemon ...).

 

Mais voilà, à chaque arrêt ou redémarrage l'arborescence /var/run est dédruite. Par exemple à chaque démarrage le service dbus (bus système) échoue car le dossier /var/run/dbus n'éxiste pas. Mais dbus est très important. Sans lui hald, cups et beaucoup d'autres échoueront. Sans hal, gdm bloque (souris et clavier inaccessible). Il n'y a alors qu'une chose à faire. Appuyer sur le bouton power et attendre l'arrêt de la machine puis redémarrer Ubuntu en mode single.

 

Compte-tenue de la taille du système de fichier /var/run (très petite 132k) j'ai choisi de désactiver le montage au démarrage avec l'option RAMRUN=no du fichier /etc/default/rcS. /var/run devient persistant entre les démarrages et c'est bien mieux car même restorecond échoue dans la surveillance du dossier /var/run/dbus.

 

Théoriquement il doit veiller à ce que ce dossier ait le bon label selinux mais au démarrage il n'existe pas et il doit donc abandonner la surveillance. Et lorsque dbus démarrera /var/run/dbus n'aura pas le bon label s'il existe.

 

Conclusion:

 

/etc/default/rcS:

RAMRUN=no

RAMLOCK=no

Sauvegarde et restauration de l'arborescence /var/run:

 

find /var/run -type d|awk 'BEGIN{} {print "mkdir -p \x22"$0"\x22"} END{print "restorecon -R /var/run"}' >restore-var-run-tree.sh

Il suffit maitenant de redémarrer avec les options selinux=1 single et dans un shell root:

 

sh chemin/vers/restore-var-run-tree.sh

 

puis continuer le démarrage avec resume.

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...