„System jest teraz gotowy do ponownego uruchomienia”

Jestem połączony z beagleboardem przez tty i nagle widzę ten komunikat:

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

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

System to Ubuntu 12.10. Czy jest miejsce, w którym mogę dowiedzieć się, dlaczego system postanowił zejść?

AKTUALIZACJA: Więcej informacji

Dzieje się tak przez cały czas, plansza restartuje się co 1 do 5 minut.
Upewniłem się, że żaden program ani demon nie działa podczas uruchamiania.
RestartingNigdzie nie mogę znaleźć żadnego pliku/var/log
W syslogprzed ponownym uruchomieniem jest konsekwentnieFeb 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

— Tomasz
źródło

@ JMCF125 Zaktualizowałem swoje pytanie, dodając więcej informacji

— Thomas

Okazuje się, że rsyslogdto po prostu demon, który przekazuje te wiadomości ... Być może masz rzadkie złośliwe oprogramowanie dla Linuksa ... 1 do 5 minut to mało czasu, spróbuj włożyć Live CD i dowiedzieć się więcej. Jeśli nic nie dostaniesz, radzę ponownie zainstalować, być może inną dystrybucję.

— JMCF125

Na początku myślałem o fizycznym problemie na płytce, takim jak napięcie elektryczne, które jest nieco zbyt niskie, ale biorąc pod uwagę, czy system o tym wiedziałby?

— Thomas

Gdyby problem stanowił problem, w przypadku Live CD to samo by się stało.

— JMCF125

Odpowiedzi:

Sposób, w jaki to wyśledzę, to zastąpienie narzędzi halti shutdownskryptu.

Najpierw utwórz skrypt, taki jak poniżej /bin/fakehalt:

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

Następnie zainstaluj go za pomocą:

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

Spowoduje to utworzenie pliku dziennika przy /tmp/fakehalt.logkażdym wywołaniu. Będzie rejestrować nazwę, która została nazwana jako ( haltlub shutdown) jego własny PID, a następnie schemat drzewa wszystkich procesów w tym czasie.

To powinno dać ci wszystkie informacje niezbędne do jej wyśledzenia. Wystarczy spojrzeć na psdrzewo i znaleźć tak zwany skrypt.

/sbin/rebootpowinien być dowiązaniem symbolicznym do /sbin/halt. Jeśli tak nie jest, wymień go również.

Jeśli nadal nie można go przechwycić, wymień /sbin/initrównież (ponieważ można go również użyć do ponownego uruchomienia systemu). Ale jest to niebezpieczne, jakby system uruchomił się ponownie, nie zadziała poprawnie.

— Patrick
źródło

Podoba mi się twoje rozwiązanie, próbowałem i pomogło mi znaleźć problem (praca w fcron pozostawiona przez kogoś, kto celowo zamknął się, gdy czek był fałszywy)

— Thomas

@ Thomas Wspomniałeś wcześniej, że fcronbył pusty, po prostu zastanawiałeś się, dlaczego zadanie się nie pokazało, widzisz to teraz?

— X Tian

@XTian błąd ludzki, sprawdziłem, czy nie ma cron, ale nie fcron

— Thomas

@Thomas, BTW, dlaczego trzeba było fcronzamknąć pracę ?

— JMCF125

@ JMCF125 Tak właśnie było (problemy z rozłączaniem usb na beagleboard) i doprowadziły mnie do przeczytania bardzo długich wątków grup google. To był mój błąd z fcronem, to był fałszywy ogień. Jakoś skrypt w fcron mówi „zrestartuj” i dlatego w kern.log pojawia się komunikat „broadast”. Dzięki za kontynuację

— Thomas

Uruchom jądro z czymś takim init=/bin/bash. To powinno sprawić, że nie uruchomią się żadne procesy poza tą powłoką.

Sprawdź, czy problem dotyczy ponownego uruchamiania komputera.

Następnie dowiedz się, jakiego systemu init używasz normalnie i przejrzyj wszystkie uruchomione przez niego usługi.

Spróbuj wyłączyć usługi, aż problem z ponownym uruchomieniem zniknie.

— michas
źródło

w jakim pliku piszesz init=/bin/bash?

— Thomas

To zależy od twojego modułu ładującego. (grub, syslinux itp.) Zwykle program ładujący powinien dać ci interaktywny sposób wyboru jądra i dodania dodatkowych parametrów. Ma także plik konfiguracyjny (zwykle w / boot), aby trwale dodać parametry.

— michas,

To jedna z tych możliwości.

Ktoś jest wyłączany
cron uruchamia zamykanie (lub uruchomił coś, co uruchamia zamykanie)
zarządzanie energią powoduje zamknięcie systemu (brak zasilania, hibernacji, uśpienia lub bezczynności, naciśnięty jest przycisk zasilania)
żądanie ponownego uruchomienia po instalacji pakietu

— X Tian
źródło

Niestety cron i fcron są puste, a ja jestem jedynym podłączonym do tablicy, nikt nie wyłącza się

— Thomas

OP mówi: „Upewniłem się, że żaden program ani demon nie działają podczas uruchamiania.”. I wątpię, żeby ktoś włamał się do jego komputera, aby co jakiś czas go wyłączać. Może to coś innego.

— JMCF125

Szukaj shut (niezależny od wielkości liter, nie restartuje się) w var / log / *

— X Tian

brak wyników dla „shut”

— Thomas