"Le système va redémarrer maintenant"

13

Je suis connecté à un beagleboard via tty et je vois soudain ce message:

Broadcast message from root@arm
        (unknown) at 11:40 ...

The system is going down for reboot NOW!
[  143.036193] Restarting system.

Le système est Ubuntu 12.10. Y a-t-il un endroit où je peux trouver pourquoi le système a décidé de tomber en panne?

MISE À JOUR: Plus d'infos

  • Cela se produit en fait tout le temps, la carte redémarre toutes les 1 à 5 minutes.
  • Je me suis assuré qu'aucun programme ou démon ne s'exécute au démarrage.
  • Je ne trouve Restartingnulle part dans aucun fichier de/var/log
  • En syslogavant un redémarrage il y a toujours unFeb 10 09:20:00 arm rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="317" x-info="http://www.rsyslog.com"] exiting on signal 15.
logs reboot Thomas
la source
@ JMCF125 J'ai mis à jour ma question avec plus d'informations
Thomas
Il s'avère que rsyslogdc'est simplement le démon qui donne ces messages ... Peut-être que vous avez un logiciel malveillant Linux rare ... 1 à 5 minutes c'est peu de temps, essayez d'insérer un Live CD et en savoir plus. Si vous n'obtenez rien, je vous conseille de réinstaller, éventuellement une autre distribution.
JMCF125
Au début, je pensais à un problème physique sur la carte, comme une tension électrique un peu trop faible, mais étant donné que le système le saurait?
Thomas
Si l'alimentation était le problème, avec le Live CD, la même chose se produirait.
JMCF125

Réponses:

11

La façon dont je retrouverais cela est de remplacer les utilitaires haltet shutdownpar un script.

Créez d'abord un script tel que celui-ci sur /bin/fakehalt:

#!/bin/bash
exec >>/tmp/fakehalt.log 2>&1
date
echo "CMD=$0 PID=$$"
ps -ef --forest
echo '========'

Installez-le ensuite avec:

chmod a+x /bin/fakehalt
mv /sbin/halt /sbin/halt.orig
ln -s /bin/fakehalt /sbin/halt
mv /sbin/shutdown /sbin/shutdown.orig
ln -s /bin/fakehalt /sbin/shutdown

Cela créera un fichier journal à /tmp/fakehalt.logchaque appel. Il enregistrera le nom sous lequel il a été appelé ( haltou shutdown) son propre PID, puis un diagramme arborescent de tous les processus à l'époque.

Cela devrait vous donner toutes les informations nécessaires pour le retrouver. Il suffit de regarder à travers l' psarborescence et de trouver ce qu'on appelle le script.

/sbin/rebootdevrait être un lien symbolique vers /sbin/halt. Si ce n'est pas le cas, remplacez-le également.

Si cela ne le capture toujours pas, remplacez- /sbin/initle également (car il peut également être utilisé pour redémarrer le système). Mais cela est dangereux car si le système redémarre, il ne se déclenchera pas correctement.

Patrick
la source
J'aime votre solution, je l'ai essayée et elle m'a aidé à trouver le problème (un travail dans fcron laissé par quelqu'un d'autre qui a fait un arrêt exprès quand un chèque était faux)
Thomas
1
@Thomas Vous avez mentionné plus tôt que fcronc'était vide, vous vous demandiez simplement pourquoi la tâche ne s'est pas affichée, pouvez-vous la voir maintenant?
X Tian
@XTian erreur humaine, j'ai vérifié pour cron mais pas fcron
Thomas
@Thomas, BTW, pourquoi y avait-il un travail fcronpour fermer?
JMCF125
1
@ JMCF125 Oui, c'était le cas (problèmes de déconnexion USB Beagleboard) et m'a amené à lire de très longs fils de discussion sur les groupes Google. C'était mon erreur avec le fcron, c'était un faux feu. D'une manière ou d'une autre, le script dans fcron dit "reboot" et c'est pourquoi il y a un message de diffusion dans kern.log. Merci d'avoir suivi
Thomas le
3

Exécutez votre noyau avec quelque chose comme init=/bin/bash. Cela devrait faire qu'aucun processus n'est en cours d'exécution que le shell this.

Vérifiez qu'il n'y a plus de problème de redémarrage.

Découvrez ensuite quel système d'initialisation vous utilisez normalement et jetez un œil à tous les services démarrés par celui-ci.

Essayez de désactiver les services jusqu'à ce que le problème de redémarrage disparaisse.

michas
la source
dans quel fichier écrivez-vous init=/bin/bash?
Thomas
Cela dépend de votre chargeur de démarrage. (grub, syslinux, etc.) Habituellement, votre chargeur de démarrage devrait vous donner un moyen interactif de choisir votre noyau et d'ajouter des paramètres supplémentaires. Il a également un fichier de configuration (généralement dans / boot) pour ajouter définitivement des paramètres.
michas
2

Eh bien, c'est l'une de ces possibilités.

  • Quelqu'un exécute l'arrêt
  • cron exécute l'arrêt (ou a démarré quelque chose qui est en cours d'arrêt)
  • la gestion de l'alimentation déclenche un arrêt (pas d'alimentation, de mise en veille prolongée, de veille ou de système inactif, le bouton matériel d'alimentation est enfoncé)
  • redémarrage demandé après l'installation du package
X Tian
la source
Malheureusement, cron et fcron sont vides, et je suis le seul connecté à la carte, personne n'est en cours d'arrêt
Thomas
L'OP dit: «Je me suis assuré qu'aucun programme ou démon ne s'exécute au démarrage.». Et je doute que quelqu'un ait piraté son ordinateur pour l'exécuter de temps en temps. C'est peut-être autre chose.
JMCF125
Rechercher shut (indépendant de la casse ne redémarre pas) dans var / log / *
X Tian
aucun résultat pour "fermé"
Thomas