nur aus neugier: zwangsbooten aus der ferne

[michaa7]

Aus reiner Neugier:

Eben verfolge ich an meinen Rechner (Desktop) einen Nachrichtenstream. Ich berühre weder die Tastatur noch die Maus. Pötzlich mitten im Stream ohne Hänger oder erkennbaren Fehler ein Reboot als ob ich die Resetttaste gedrückt hätte. Das habe ich in meiner gesamten Zeit mit Linux noch nie erlebt. Bildschirm wird schwarz und gibt die übliche Meldung aus bevor der Rechner normal rebootet. Alles funktioniert wieder.

Ist es möglichen einen Rechner aus der Ferne zu booten? Ich könnte mir das für den dazwischenhängenden Router gerade noch vorstellen (obwohl da der Zugriff nur aus dem LAN erlaubt ist)
aber für meinen Desktop ...

[DeletedUserReAsG]

Ist es möglichen einen Rechner aus der Ferne zu booten?

Natürlich. Man loggt sich via ssh ein, und setzt ein reboot o.Ä. ab.

Möglicherweise wolltest du aber fragen, warum deine Kiste sich rebootet haben könnte? Die Antwort findet sich, seitdem Erwerb, Besitz und Verwendung von Glaskugeln nur noch der Staatsmacht erlaubt ist, am ehesten in deinem Log.

[michaa7]

In meinem log ... leider ist das mit journalctl nicht so einfach und so einfach mal die verdächtigen textdateien durchgehen geht ja nicht mehr.

Wie ringe ich journalctl eine ausgabe von der vorangegangen session ab. Denn "journalctl" beginnt im moment mit der laufenden session ... also nach dem reboot.

[towo]

Code: Alles auswählen

journalctl -b -1

[michaa7]

Danke towo, das brachte aber die Session von heute nacht zu Tage. "0" statt "1" brachte dann den gesamten heutigen Tage zum Vorschein.

Die letzten Meldungen vor dem reboot:

Feb 09 17:31:42 neutower systemd[1]: Started Daemon for power management.
Feb 09 17:31:50 neutower kernel: ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Feb 09 17:31:50 neutower kernel: ata1.01: BMDMA stat 0x66
Feb 09 17:31:50 neutower kernel: ata1.01: failed command: READ DMA
Feb 09 17:31:50 neutower kernel: ata1.01: cmd c8/00:00:b0:21:11/00:00:00:00:00/f1 tag 0 dma 131072 in
res 51/84:10:a0:22:11/84:00:01:00:00/f1 Emask 0x30 (host bus error)
Feb 09 17:31:50 neutower kernel: ata1.01: status: { DRDY ERR }
Feb 09 17:31:50 neutower kernel: ata1.01: error: { ICRC ABRT }
Feb 09 17:31:50 neutower kernel: ata1: soft resetting link
Feb 09 17:31:50 neutower kernel: ata1.01: supports DRM functions and may not be fully accessible
Feb 09 17:31:50 neutower kernel: ata1.00: configured for UDMA/133
Feb 09 17:31:50 neutower kernel: ata1.01: supports DRM functions and may not be fully accessible
Feb 09 17:31:50 neutower kernel: ata1.01: configured for UDMA/33
Feb 09 17:31:50 neutower kernel: sd 0:0:1:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 09 17:31:50 neutower kernel: sd 0:0:1:0: [sdb] tag#0 Sense Key : Aborted Command [current]
Feb 09 17:31:50 neutower kernel: sd 0:0:1:0: [sdb] tag#0 Add. Sense: Scsi parity error
Feb 09 17:31:50 neutower kernel: sd 0:0:1:0: [sdb] tag#0 CDB: Read(10) 28 00 01 11 21 b0 00 01 00 00
Feb 09 17:31:50 neutower kernel: blk_update_request: I/O error, dev sdb, sector 17899952 op 0x0:(READ) flags 0x80700 phys_seg >
Feb 09 17:31:50 neutower kernel: ata1: EH complete
Feb 09 17:32:01 neutower dbus-daemon[768]: [system] Failed to activate service 'org.bluez': timed out (service_start_timeout=2>
Feb 09 17:33:43 neutower kernel: perf: interrupt took too long (2504 > 2500), lowering kernel.perf_event_max_sample_rate to 79>
Feb 09 17:35:02 neutower kernel: perf: interrupt took too long (3144 > 3130), lowering kernel.perf_event_max_sample_rate to 63>
Feb 09 17:37:19 neutower kernel: perf: interrupt took too long (3933 > 3930), lowering kernel.perf_event_max_sample_rate to 50>Feb 09 17:46:28 neutower systemd[1]: Starting Cleanup of Temporary Directories...
Feb 09 17:46:28 neutower systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Feb 09 17:46:28 neutower systemd[1]: Started Cleanup of Temporary Directories.
Feb 09 17:49:00 neutower kernel: perf: interrupt took too long (4920 > 4916), lowering kernel.perf_event_max_sample_rate to 40000

hmm ... da scheint es einer platte nicht allzugut zu gehen. Entspricht ata1.01: 0:0:1:0: [sdb] ?

[DeletedUserReAsG]

Wie ringe ich journalctl eine ausgabe von der vorangegangen session ab.

Bei Debian ist die Defaultkonfiguration vom journald bislang wohl, dass es kein persistentes Journal gibt. Wenn du da noch nix geändert hast, müsstest du das einrichten. Wenn ich mich nicht ganz falsch erinnere, reichte das Anlegen des Verzeichnisses ›/var/log/journal/‹, oder man aktiviert’s in der Config (unter /etc/ irgendwo).

Eine kaputte Platte kann durchaus für ein solches Phänomen verantwortlich sein, ja.

[OrangeJuice]

Ich hatte das mal damit aktiviert:

Code: Alles auswählen

nano /etc/systemd/journald.conf
Storage=persistent

Hier ist das gut erklärt(WikiArchLinux). Dann kann man gleich noch die max. Größe "SystemMaxUse" der Logs usw. festlegen.