Problème démarrage auto de process + reboot impossible

Support Debian
#1

Bonjour,

Je vous contact ce soir pour un problème étrange qui va au dela de mes compétences déjà bien faibles… Les recherches ici n’ont rien données pour ma part.

Bref je vous présente la bête :

Distrib’ Debian Lenny - 2.6

Problème : ne peut plus rebooter (init0 j’ose pas -> OVH…), et ne lance plus un paquet de process au démarrage (proftp, apache, cron, postif, parfois même le rsyslog !!).

Vérifications effectuées pour le problème de reboot :

Aucune, sauf qu’il me kill mysql, rsyslog, apache2, etc… Dernière ligne de log de syslog :

localhost shutdown[8411]: shutting down for system reboot

Et hop, le noir… Mais je garde la main !! le ssh fonctionne toujours (ou du moins “en cache”), et je peux relancer mes process…

Et je seche ici…

Vérifications effectuées pour le problème de process au démarrage :

Dans /etc/rc2.d/, j’ai mes liens symboliques vers mes bons process dans /etc/init.d/.
J’ai essayé du update-rd.d -f apache remove
Puis update-rc.d apache defaults
Mais rien n’y fait.

Là aussi s’arrêtent mes connaissances.

Auriez-vous une idée sur l’origine ou comment au moins résoudre la chose (qui, je pense, est liée).

Par avance merci, et bon week-end à tous !! (car oui, c’est le week-end !! :mrgreen: :mrgreen: )

FroZeN

#2

Salut,
Ton runlevel par defaut n’aurait pas bougé “accidentellement” par hasard ?
Cette commande devrait t’en dire plus sur le runlevel par défaut actuel :

cat /etc/inittab |grep initdefault
#3

Bonsoir Dric, et merci pour cette réponse.

La commande renvoie :

id:2:initdefault:

Après une brève recherche, je crois comprendre que ça correspond bien à mon rc2.d (avec le runlevel à 2). Qu’en pense-tu ?

#4

Oui, oui, c’est bien ça, ton runlevel est le 2 et correspond bien à /etc/rc2.d

Est ce que tu as vérifié les permissions sur les liens dans /etc/rc2.d ?
La même chose sur les scripts cibles dans /etc/init.d/ ?
Ils doivent tous appartenir a root, et les droits d’exécution doivent être bien positionnés.

Si tout est ok à ce niveau également, je ne saurai pas t’aider bcp plus :neutral_face:

#5

Pourrais-tu me fournir les droits justement, dont j’a besoin sur ces fichiers. Je doute que ça vienne de là, je ne crois pas y avoir touché… Et ils sont full en 777… Je but là aussi :frowning:

#6

Les liens symboliques sont en 777 dans /etc/rc2.d
Dans /etc/init.d/, il faut s’assurer que les scripts correspondants ont bien les droits d’exécutions.
Ex : rwx r-x r-x (ou 755)

#7

OK aussi de ce côté là.

Merci de ta patience !

#8

Si tu les lances à la main, ça fonctionne ?

#9

Yes, ça passe.

#10

Revenons aux fondamentaux.
Le père de tous les process sous unix, c’est init : c’est lui qui appelle les autres processus au démarrage de la machine, qui eux même en appellent d’autre etc.
C’est aussi lui qui est invoqué lorsque tu éteint ta machine.
Or tu as des problèmes au lancement auto des processus, et à l’arrêt de la machine. Le dénominateur commun semble donc être init.

Est ce qu’il est bien à sa place dans /sbin/, appartient a root / root, avec comme droits rwx r-x r-x ?

$ ls -l /sbin/init 
-rwxr-xr-x 1 root root 31420 22 mars  20:28 /sbin/init
#11

On est bon là aussi…

Question ?

Un update-rc.d init defaults ou même -f remove s’il faut, ça donne quoi en vrai ? ^^

#12

[quote=“FroZeN”]On est bon là aussi…

Question ?

Un update-rc.d init defaults ou même -f remove s’il faut, ça donne quoi en vrai ? ^^[/quote]

Ben, l’une n’a rien à voir avec l’autre :
la première rajouterait des liens vers init au runlevels 2345 pour le démarrage et 0,1 et 6 pour l’arrêt. A ne surtout pas pas faire, init est appelé par le kernel au démarrage, et se sert du contenu d’inittab pour savoir quels process lancer ensuite.

-f remove supprimerait le service, or init ne fait partie d’aucun runlevel.

Tu as des erreurs ou des trucs étranges dans le /var/log/boot ?

Il se peut que tu ais un problème avec init, auquel cas, le noyau va laisser tomber et lancer un shell (/bin/sh) et te donner accès au système en root (en mode single user en fait, avec aucun service lancé). C’est peut être ce qui se passe ?

De plus, dans ton premier post, tu dis avoir supprimé et réactivé le service apache, mais dnas ta commande tu ne fais pas apparaître le numéro de séquence qui va conditionner l’ordre de démarrage de ton service par rapport aux autres (il prend 20 par defaut, mais ca peut être incohérent s’il démarre après un service qui dépend de lui - cf man update-rc.d).

Peut être qu’un petit ls -l /etc/rc2.d/ aiderait à y voir plus clair aussi.

#13

Voici la chose :

[quote]lrwxrwxrwx 1 root root 17 sep 2 2009 S10rsyslog -> …/init.d/rsyslog
lrwxrwxrwx 1 root root 17 sep 2 2009 S13fixudev -> …/init.d/fixudev
lrwxrwxrwx 1 root root 15 sep 2 2009 S15bind9 -> …/init.d/bind9
lrwxrwxrwx 1 root root 13 sep 2 2009 S16ssh -> …/init.d/ssh
lrwxrwxrwx 1 root root 23 sep 2 2009 S17mysql-ndb-mgm -> …/init.d/mysql-ndb-mgm
lrwxrwxrwx 1 root root 19 sep 2 2009 S18mysql-ndb -> …/init.d/mysql-ndb
lrwxrwxrwx 1 root root 15 sep 2 2009 S19mysql -> …/init.d/mysql
lrwxrwxrwx 1 root root 20 sep 2 2009 S19open-iscsi -> …/init.d/open-iscsi
lrwxrwxrwx 1 root root 22 mar 3 16:03 S19spamassassin -> …/init.d/spamassassin
lrwxrwxrwx 1 root root 28 oct 1 2009 S20courier-authdaemon -> …/init.d/courier-authdaemon
lrwxrwxrwx 1 root root 14 avr 23 19:01 S20cron -> …/init.d/cron
lrwxrwxrwx 1 root root 15 sep 2 2009 S20exim4 -> …/init.d/exim4
lrwxrwxrwx 1 root root 17 sep 2 2009 S20hddtemp -> …/init.d/hddtemp
lrwxrwxrwx 1 root root 23 sep 2 2009 S20openbsd-inetd -> …/init.d/openbsd-inetd
lrwxrwxrwx 1 root root 17 mar 23 10:20 S20postfix -> …/init.d/postfix
lrwxrwxrwx 1 root root 17 avr 23 19:01 S20proftpd -> …/init.d/proftpd
lrwxrwxrwx 1 root root 15 sep 2 2009 S20rsync -> …/init.d/rsync
lrwxrwxrwx 1 root root 19 oct 1 2009 S20saslauthd -> …/init.d/saslauthd
lrwxrwxrwx 1 root root 23 sep 2 2009 S20smartmontools -> …/init.d/smartmontools
lrwxrwxrwx 1 root root 15 sep 7 2009 S20snmpd -> …/init.d/snmpd
lrwxrwxrwx 1 root root 13 mar 3 15:47 S21fam -> …/init.d/fam
lrwxrwxrwx 1 root root 13 oct 1 2009 S23ntp -> …/init.d/ntp
lrwxrwxrwx 1 root root 15 sep 2 2009 S25mdadm -> …/init.d/mdadm
lrwxrwxrwx 1 root root 17 sep 2 2009 S91apache2 -> …/init.d/apache2
lrwxrwxrwx 1 root root 18 sep 2 2009 S99rc.local -> …/init.d/rc.local
lrwxrwxrwx 1 root root 19 sep 2 2009 S99rmnologin -> …/init.d/rmnologin
lrwxrwxrwx 1 root root 23 sep 2 2009 S99stop-bootlogd -> …/init.d/stop-bootlogd
[/quote]

merci encore pour ton implication !

#14

Et le contenu du bootlog aussi ^^

#15

Hop, après une bonne nuit, une bonne balade au soleil et un bon petit dej’, c’est reparti !

Le fichier /var/log/boot est actuellement vide.

Il existe plusieurs autres bootlog, notamment le /sbin/bootlog, mais inéditable.

Je repars la tête fraiche sur le sujet et vois ce que ça donne :slightly_smiling:

#16

faut activer les logs :
en root : gedit /etc/default/bootlogd

puis : BOOTLOGD_ENABLE=Yes

#17

Alors j’ai tenté ceci :

#18

bootlogd n’est censé fonctionner que durant le boot, et s’arrête juste avant le chargement de X. Donc même si t’arrivais a démarrer le service maintenant, ca ne servirait à rien : il ne loguerait rien.
Cela dit, je n’ai pas ce message d’erreur sur ma machine, en démarrant le service une fois connecté.

EDIT : normal que j’ai pas le pb, apparemment c’était un bug qui a été corrigé dans les dernières versions (mail-archive.com/debian-bugs … 78264.html) (je suis sous sid, tu es sous lenny)

#19

Après un reboot réussi (WOUHOUUUUU !!), il s’avère que le fichier de log /var/log/boot reste vide (et il ne devrait pas s’agir d’un fichier bootlogd ou quelque chose du style ?).

Par contre, apache2, cron, proftpd n’était pas démarré. Pas d’erreur sur leurs starts manuel. rsyslog et mysql étaient démarrés…

Fichier syslog clear sur le boot, pas d’erreur qui remonte, a part des tables à réparer (chose faite ^^) lors du démarrage de mysql.

Je sursèche…

Et profitez un peu du beau temps, c’est presque l’été !!! :mrgreen: :mrgreen: :mrgreen: :mrgreen:

#20

C’est pas tellement étonnant quand on y pense : bootlogd est un service qui se met aussi dans les rcX.d, donc pour la/les mêmes raisons que les autres services ne démarrent pas tout le temps, ce derniers n’a pas du démarrer non plus et donc le log reste vide…

C’est bien /var/log/boot.

Y a un utilitaire qui permet de contrôler (et modifier si on veut) les services à démarrer dans les divers runlevels : c’est sysv-rc-conf

Peut être que son interprétation peut nous en dire plus.