Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #113925 > unrolled thread

Absturz ArchLinux mit Storage=volatile

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-09 12:55 -0800
    Re: Absturz ArchLinux mit Storage=volatile Arno Lutz <invalid@freakmail.de> - 2021-01-09 22:03 +0100
      Re: Absturz ArchLinux mit Storage=volatile Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2021-01-09 22:58 +0100
        Re: Absturz ArchLinux mit Storage=volatile Arno Lutz <invalid@freakmail.de> - 2021-01-09 23:14 +0100
          Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-11 09:16 -0800
        Re: Absturz ArchLinux mit Storage=volatile Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-01-10 08:50 +0100
        Re: Absturz ArchLinux mit Storage=volatile Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-01-10 09:11 +0100
      Re: Absturz ArchLinux mit Storage=volatile Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-01-10 08:32 +0100
    Re: Absturz ArchLinux mit Storage=volatile Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-01-10 08:43 +0100
      Re: Absturz ArchLinux mit Storage=volatile "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-01-10 15:47 +0000
        Re: Absturz ArchLinux mit Storage=volatile Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-01-10 18:52 +0100
          Re: Absturz ArchLinux mit Storage=volatile "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-01-11 16:22 +0000
            Re: Absturz ArchLinux mit Storage=volatile Ralph Angenendt <dein.name@strg-alt-entf.org> - 2021-01-11 17:08 +0000
              Re: Absturz ArchLinux mit Storage=volatile "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-01-11 18:48 +0000
            Re: Absturz ArchLinux mit Storage=volatile Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-01-11 21:14 +0100
      Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-11 09:35 -0800
        Re: Absturz ArchLinux mit Storage=volatile Christian Garbs <mitch@cgarbs.de> - 2021-01-11 20:07 +0100
          Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-11 11:50 -0800
            Re: Absturz ArchLinux mit Storage=volatile Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-01-13 22:40 +0100
              Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-13 15:21 -0800
    Re: Absturz ArchLinux mit Storage=volatile Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2021-01-10 11:28 +0100
      Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-11 09:11 -0800
        Re: Absturz ArchLinux mit Storage=volatile Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2021-01-14 16:47 +0100
          Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-15 13:21 -0800
            Re: Absturz ArchLinux mit Storage=volatile Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2021-01-18 18:43 +0100
              Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-18 15:18 -0800
              Re: Absturz ArchLinux mit Storage=volatile Christian Garbs <mitch@cgarbs.de> - 2021-01-19 20:57 +0100
    Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-02-13 12:27 -0800

Page 2 of 2 — ← Prev page 1 [2]

#113938

On 09.01.21 21:55, Joerg wrote:
> # [Journal]
> Storage=volatile
> RuntimeMaxUse=10M [Journal]

Warum das "#" vor "[Journal]"?
Warum das "[Journal]" hinter "10M"?

> Weiss jemand, wo ich wuehlen koennte? Koennte irgendwas anecken, wenn 
> die 10M voll sind und das Log anfaengt zu rollen?

Die Frage ist was genau passiert.

Hat dein ARM-Board auch USB und einen Bildschirmanschluss? Das würde ich 
zuerst probieren. Wenn das Ding hängt Bildschirm und Tastatur dran und 
vor Ort checken in welchem Zustand das Board wirklich ist. Es kann sein 
das der Bildschirm im Nachgang nicht initialisiert wird. Also am besten 
irgendwas ausgemustertes direkt an dem Board abstellen und angeschlossen 
lassen.

Wenn kein Bildschirm möglich, dann geht meist ein serielles Terminal als 
"letzter Ausweg". 3,3V FTDI FT232RL Board besorgen und am seriellen 
Anschluss des Board anschließen. Wenn es hängt versuchen mit einem 
Laptop ein serielles Terminal zu bekommen.

> Erwaehnen sollte ich noch, dass dieses NAS nur 128MB RAM hat, was aber 
> fuer den Job locker reicht. ArchLinux und die wenigen noetigen Programme 
> belegen keine 40MB.

Zeitweise könnte durchaus mehr RAM gebraucht werden. Ich würde das mal 
beobachten! 128 MB ist sogar für einen ARM-Rechner mittlerweile echt wenig.

Meine letzten ARM-Boards mit so wenig RAM habe ich vor ein paar Wochen 
bei eBay entsorgt. Mit allem was unterhalb eines 30 Euro Raspberry ist 
ärgere ich mich nicht mehr rum. Und gerade als NAS wäre doch ein 
Raspberry Pi 4 optimal.

Bei Arch ist das /tmp eine RAM-Disk. Wenn ein Dienst meint große 
Temp-Dateien erstellen zu müssen ist ein Großteil deines RAM dann ganz 
schnell voll.

Ich erinnere mich dunkel das man sogar Probleme beim Updaten bekommen 
konnte wenn kein Swap eingerichtet ist. Das aber mit einem Board mit 64 
MB RAM.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#113965

On 1/10/21 2:28 AM, Manuel Reimer wrote:
> On 09.01.21 21:55, Joerg wrote:
>> # [Journal]
>> Storage=volatile
>> RuntimeMaxUse=10M [Journal]
> 
> Warum das "#" vor "[Journal]"?
> Warum das "[Journal]" hinter "10M"?
> 

Das hab ich als Anfaenger einfach aus nehreren gleichlautenden 
Empfehlungen so uebernommen. Es tut ja auch erstmal, nur stuerzt die 
Kiste damit immer alle 2-3 Wochen gruendlich ab.


>> Weiss jemand, wo ich wuehlen koennte? Koennte irgendwas anecken, wenn 
>> die 10M voll sind und das Log anfaengt zu rollen?
> 
> Die Frage ist was genau passiert.
> 
> Hat dein ARM-Board auch USB und einen Bildschirmanschluss? Das würde ich 
> zuerst probieren. Wenn das Ding hängt Bildschirm und Tastatur dran und 
> vor Ort checken in welchem Zustand das Board wirklich ist. Es kann sein 
> das der Bildschirm im Nachgang nicht initialisiert wird. Also am besten 
> irgendwas ausgemustertes direkt an dem Board abstellen und angeschlossen 
> lassen.
> 

Das hat es alles nicht. Steht im Keller, es steckt nur der USB Stick mit 
dem ArchLinux drauf in der USB Buchse. Sonst ist da nur noch eine 64GB 
SD-Card drin, als File-Ablage fuer das NAS. Darauf wird nur wenig 
geroedelt, es dient hauptsaechlich dazu, wichtige Files von ueberall im 
Haus zugaenglich zu haben.


> Wenn kein Bildschirm möglich, dann geht meist ein serielles Terminal als 
> "letzter Ausweg". 3,3V FTDI FT232RL Board besorgen und am seriellen 
> Anschluss des Board anschließen. Wenn es hängt versuchen mit einem 
> Laptop ein serielles Terminal zu bekommen.
> 

Ist alles vorhanden, habe sogar eine 3.5mm Klinkenbuchse reingesetzt und 
mit den passenden Leiterbahnen verbunden, denn ich musste das Dingen 
ueber RS232 hacken. Per Terminal kaeme ich noch rein, nur komme ich bei 
abgekrachten OS m.W. nicht mehr an das Log. journalctl laeuft dann ja 
nicht mehr. Erst nach Reboot und danach ist alles fluechtig gespeicherte 
weg.


>> Erwaehnen sollte ich noch, dass dieses NAS nur 128MB RAM hat, was aber 
>> fuer den Job locker reicht. ArchLinux und die wenigen noetigen 
>> Programme belegen keine 40MB.
> 
> Zeitweise könnte durchaus mehr RAM gebraucht werden. Ich würde das mal 
> beobachten! 128 MB ist sogar für einen ARM-Rechner mittlerweile echt wenig.
> 

Ich hatte das mal laengere Zeit mitlaufen und von einem anderen Rechner 
(in Sichtweite) auf das NAS zugegriffen. Die RAM-Belegung blieb unter 
40MB und pendelte meist zwischen 36MB und 37MB.


> Meine letzten ARM-Boards mit so wenig RAM habe ich vor ein paar Wochen 
> bei eBay entsorgt. Mit allem was unterhalb eines 30 Euro Raspberry ist 
> ärgere ich mich nicht mehr rum. Und gerade als NAS wäre doch ein 
> Raspberry Pi 4 optimal.
> 

Klar, wegschmeissen und neu kaufen ist immer eine Methode. Ich bin aber 
kein Anhaenger der Wegewerfgesellschaft und das Dingen hat auch den 
Vorteil, nur ein Watt zu verbrauchen.

Wenn ich eines Tages Audio von meinem Funkgeraet mit Linux zugaenglich 
bekomme, werde ich da wohl einen durchlaufenden Raspberry ranhaengen. 
Der koennte natuerlich nebenbei NAS werden.


> Bei Arch ist das /tmp eine RAM-Disk. Wenn ein Dienst meint große 
> Temp-Dateien erstellen zu müssen ist ein Großteil deines RAM dann ganz 
> schnell voll.
> 
> Ich erinnere mich dunkel das man sogar Probleme beim Updaten bekommen 
> konnte wenn kein Swap eingerichtet ist. Das aber mit einem Board mit 64 
> MB RAM.
> 

Bisher ist weder bei Updates noch bei groesserer Roedelei auf der SD 
Card (der Speicher fuer Files bei diesem NAS) die RAM-Belegung gross 
hoch gelaufen.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#114021

On 11.01.21 18:11, Joerg wrote:
> Per Terminal kaeme ich noch rein, nur komme ich bei 
> abgekrachten OS m.W. nicht mehr an das Log. journalctl laeuft dann ja 
> nicht mehr. Erst nach Reboot und danach ist alles fluechtig gespeicherte 
> weg.

Unter "per Terminal kommt man noch rein" verstehe ich schon das 
*irgendein* Befehl noch geht. Also das der Kernel nicht ganz tot ist. In 
dem Fall kommt man auch noch an das Log. Worst-Case holt man sich die 
Journal-Dateien via Z-Modem auf eine andere Linux-Kiste.

> Klar, wegschmeissen und neu kaufen ist immer eine Methode. Ich bin aber 
> kein Anhaenger der Wegewerfgesellschaft und das Dingen hat auch den 
> Vorteil, nur ein Watt zu verbrauchen.

"Wegschmeißen" hab ich nie geschrieben. Da bin ich auch kein Fan von. 
Was noch funktioniert wird nicht weggeschmissen sondern bei eBay 
versteigert. Mir war es irgendwann einfach zu zäh und aufwändig 
exotische Hardware mit kaum Support aus der Community am Laufen zu 
halten. Und ein paar Euro hat jedes Board noch gebracht. Jetzt darf sich 
jemand anders damit rumärgern :P

Ich habe einen Raspberry der ersten Generation als Solar-Logger 24/7 
laufen und der braucht mit deaktivierter Grafikausgabe auch nur knapp 
ein Watt. Auch auf dem ist das Journal nur im RAM und nach oben stark 
limitiert. Letztens hab ich auf dem angeschlossenen 2-Zeilen Text-LCD 
die Uptime abgelesen. Die 1000 Stunden sind bald geknackt. Läuft bisher 
extrem zuverlässig. Nur einmal im Jahr gibt es keine Daten weil mein 
Mobilfunkprovider da die Karte wegen "zu selten aufgeladen" temporär sperrt.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#114054

On 1/14/21 7:47 AM, Manuel Reimer wrote:
> On 11.01.21 18:11, Joerg wrote:
>> Per Terminal kaeme ich noch rein, nur komme ich bei abgekrachten OS 
>> m.W. nicht mehr an das Log. journalctl laeuft dann ja nicht mehr. Erst 
>> nach Reboot und danach ist alles fluechtig gespeicherte weg.
> 
> Unter "per Terminal kommt man noch rein" verstehe ich schon das 
> *irgendein* Befehl noch geht. Also das der Kernel nicht ganz tot ist. In 
> dem Fall kommt man auch noch an das Log. Worst-Case holt man sich die 
> Journal-Dateien via Z-Modem auf eine andere Linux-Kiste.
> 

Das habe ich nicht probiert, dazu muesste ich den irgendwo besser 
zugaenglich betreiben anstatt in einer Ecke links hinter der 
Tiefkuehltruhe. Denn die Stromversorgung muesste dann ununterbrochen 
bleiben. Sieht aber schon tot aus, nichts blinkt mehr.

Jetzt mit Log Volume von 10MB auf 1MB heruntergesetzt laeuft er schon 
seit Montag. Langsam hege ich Zweifel, ob die Haenger am Ueberrollen des 
Logs liegen.


>> Klar, wegschmeissen und neu kaufen ist immer eine Methode. Ich bin 
>> aber kein Anhaenger der Wegewerfgesellschaft und das Dingen hat auch 
>> den Vorteil, nur ein Watt zu verbrauchen.
> 
> "Wegschmeißen" hab ich nie geschrieben. Da bin ich auch kein Fan von. 
> Was noch funktioniert wird nicht weggeschmissen sondern bei eBay 
> versteigert. Mir war es irgendwann einfach zu zäh und aufwändig 
> exotische Hardware mit kaum Support aus der Community am Laufen zu 
> halten. Und ein paar Euro hat jedes Board noch gebracht. Jetzt darf sich 
> jemand anders damit rumärgern :P
> 

Wir nennen das "kicking the can down the road" :-)


> Ich habe einen Raspberry der ersten Generation als Solar-Logger 24/7 
> laufen und der braucht mit deaktivierter Grafikausgabe auch nur knapp 
> ein Watt. Auch auf dem ist das Journal nur im RAM und nach oben stark 
> limitiert. Letztens hab ich auf dem angeschlossenen 2-Zeilen Text-LCD 
> die Uptime abgelesen. Die 1000 Stunden sind bald geknackt.


Sechs Wochen sind jetzt auch nicht gerade viel.


>                                                  ... Läuft bisher 
> extrem zuverlässig. Nur einmal im Jahr gibt es keine Daten weil mein 
> Mobilfunkprovider da die Karte wegen "zu selten aufgeladen" temporär 
> sperrt.
> 

Kenne ich, wobei das bei Euch noch weit billiger ist als in Amiland. Das 
seltenst benutzte Non-Smart Handy meiner Frau kostet inzwischen $5 pro 
Monat plus $0.20/Minute. Die Datenvertraege meiner Kunden kosten zwar 
nur einen Bruchteil davon, aber nur, weil sich das auf jeweils 
zig-tausende Einzel-Accounts summiert.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#114136

On 15.01.21 22:21, Joerg wrote:
>> Letztens hab ich auf dem angeschlossenen 2-Zeilen Text-LCD 
>> die Uptime abgelesen. Die 1000 Stunden sind bald geknackt.
> 
> Sechs Wochen sind jetzt auch nicht gerade viel.

Meinte auch 1000 Tage :P

> Kenne ich, wobei das bei Euch noch weit billiger ist als in Amiland. Das 
> seltenst benutzte Non-Smart Handy meiner Frau kostet inzwischen $5 pro 
> Monat plus $0.20/Minute. Die Datenvertraege meiner Kunden kosten zwar 
> nur einen Bruchteil davon, aber nur, weil sich das auf jeweils 
> zig-tausende Einzel-Accounts summiert.

Interessant. Ich dachte wir sind hier rückständig was das angeht. Ich 
fahre (eigentlich, wenn nicht gerade so ne lästige Pandemie herrscht) 
viel Bahn und um die Zeit zu vertreiben nutze ich viel mobiles Internet. 
In Deutschland nicht nur teuer sondern auch sehr lückenhaft.

Ich hab an dem Raspberry eine Prepaid-Karte. Die 100 KB pro Tag fallen 
kaum ins Gewicht bei volumenbasierter Abrechnung. Das Ding ist ein 
Sparschwein. Ich muss aufladen weil die Karte sonst gesperrt wird. Nicht 
weil ich das Guthaben tatsächlich aufgebraucht kriege. Einmal im Jahr 
hänge ich ein Laptop an den Raspberry und löse mit einem Python-Script 
direkt auf dem Modem SMS-Versand auf Spendennummern aus um das Konto 
leer zu bekommen.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#114153

On 1/18/21 9:43 AM, Manuel Reimer wrote:
> On 15.01.21 22:21, Joerg wrote:
>>> Letztens hab ich auf dem angeschlossenen 2-Zeilen Text-LCD die Uptime 
>>> abgelesen. Die 1000 Stunden sind bald geknackt.
>>
>> Sechs Wochen sind jetzt auch nicht gerade viel.
> 
> Meinte auch 1000 Tage :P
> 
>> Kenne ich, wobei das bei Euch noch weit billiger ist als in Amiland. 
>> Das seltenst benutzte Non-Smart Handy meiner Frau kostet inzwischen $5 
>> pro Monat plus $0.20/Minute. Die Datenvertraege meiner Kunden kosten 
>> zwar nur einen Bruchteil davon, aber nur, weil sich das auf jeweils 
>> zig-tausende Einzel-Accounts summiert.
> 
> Interessant. Ich dachte wir sind hier rückständig was das angeht. Ich 
> fahre (eigentlich, wenn nicht gerade so ne lästige Pandemie herrscht) 
> viel Bahn und um die Zeit zu vertreiben nutze ich viel mobiles Internet. 
> In Deutschland nicht nur teuer sondern auch sehr lückenhaft.
> 

Lueckenhaft ist es hier nicht und wenn man Vielnutzer ist, kostet es um 
$50/Monat. Hat ein Kumpel, 65GB/Monat Flat (danach drosseln sie die 
Geschwindigkeit), Telefon und SMS unendlich.

Teuer wird es hier fuer Wenignutzer wie mich. Der minimale Smart Phone 
Tarif war 500MB/Monat und 250min Telefon, kostet mich mit Steuern 
$22/Monat. Ich verbrauche weniger als ein Zehntel davon.


> Ich hab an dem Raspberry eine Prepaid-Karte. Die 100 KB pro Tag fallen 
> kaum ins Gewicht bei volumenbasierter Abrechnung. Das Ding ist ein 
> Sparschwein. Ich muss aufladen weil die Karte sonst gesperrt wird. Nicht 
> weil ich das Guthaben tatsächlich aufgebraucht kriege. Einmal im Jahr 
> hänge ich ein Laptop an den Raspberry und löse mit einem Python-Script 
> direkt auf dem Modem SMS-Versand auf Spendennummern aus um das Konto 
> leer zu bekommen.
> 

Aber vermutlich zahlst Du einmal im Jahr nur ein paar Euro und das waere 
in Amiland unmoeglich. Diese Kosten erdruecken viele Steuerungsideen von 
Hobbyisten im Keim. Als Funkamateur koennte man das natuerlich 
umschiffen ...

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#114172

Mahlzeit!

Manuel Reimer <manuel.nulldevice@nurfuerspam.de> wrote:

> Ich hab an dem Raspberry eine Prepaid-Karte. Die 100 KB pro Tag fallen 
> kaum ins Gewicht bei volumenbasierter Abrechnung. Das Ding ist ein 
> Sparschwein. Ich muss aufladen weil die Karte sonst gesperrt wird. Nicht 
> weil ich das Guthaben tatsächlich aufgebraucht kriege. Einmal im Jahr 
> hänge ich ein Laptop an den Raspberry und löse mit einem Python-Script 
> direkt auf dem Modem SMS-Versand auf Spendennummern aus um das Konto 
> leer zu bekommen.

Das ist ja mal eine coole Idee!
Muss ich die jetzt selber im Netdigest einreichen?

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
And on the eighth day, we bulldozed it.

[toc] | [prev] | [next] | [standalone]

#114836

On 1/9/21 12:55 PM, Joerg wrote:
> Kleiner 800MHz ARM von Marvell, ArchLinux drauf.
> 
> [joerg@alarm ~]$ cat /etc/os-release
> NAME="Arch Linux ARM"
> PRETTY_NAME="Arch Linux ARM"
> ID=archarm
> ID_LIKE=arch
> BUILD_ID=rolling
> ANSI_COLOR="0;36"
> HOME_URL="https://archlinuxarm.org/"
> DOCUMENTATION_URL="https://archlinuxarm.org/wiki"
> SUPPORT_URL="https://archlinuxarm.org/forum"
> BUG_REPORT_URL="https://github.com/archlinuxarm/PKGBUILDs/issues"
> 
> Um dessen USB Stick nicht durch Logging zu verschleissen, habe ich in 
> /etc/systemd/journald.conf.d eine simple Dafei "usbstick.conf" gesetzt 
> mit folgendem Inhalt:
> 
> # [Journal]
> Storage=volatile
> RuntimeMaxUse=10M [Journal]
> 
> Damit stuerzt das Dingen alle 2-3 Wochen ab. Kein ssh mehr, kein ping 
> mehr, nix. Dann muss ich den Keller fuer einen Power Cycle. Ok, 
> Treppenlaufen haelt auch fit, aber es nervt, wenn das mitten bei der 
> Arbeit passiert. Natuerlich gibt es damit nach dem Absturz kein Log.
> 
> Also habe ich die letzten beiden Zeilen mal auskommentiert, um ein Log 
> zu bekommen und den Uebeltaeter zu stellen. Nur ... stuerzt das 
> Kaestchen dann nicht mehr ab ... <kopfkratz>.
> 
> Weiss jemand, wo ich wuehlen koennte? Koennte irgendwas anecken, wenn 
> die 10M voll sind und das Log anfaengt zu rollen?
> 
> Andere Frage: Das OS belegt 2GB auf einem 32GB Stick und ansonsten wird 
> hoechstens mal 5-10GB an Backup draufgeschrieben und das sehr selten, 
> der Rest bleibt leer. Waere der Verschleiss durch staendiges Logging mit 
> so einem grossen Stick vernachlaessigbar, sodass ich systemd Logging 
> einfach non-volatile laufen lassen koennte?
> 
> Sonst gaebe es vielleicht noch die Methode, jeden Sonntag per cron Job 
> einen Reset machen zu lassen, denn das Dingen dient hier nur als NAS. 
> Waere aber unspochtlich und wohl auch fuer einen Linux-Anfaenger nicht 
> die feine englische.
> 
> Erwaehnen sollte ich noch, dass dieses NAS nur 128MB RAM hat, was aber 
> fuer den Job locker reicht. ArchLinux und die wenigen noetigen Programme 
> belegen keine 40MB.
> 

Nach etwa fuenf Wochen ist das Dingen nun auch mit Non-volatile Logging 
abgestuerzt, wobei der Log File auf 1M begrenzt ist. Mit 10M stuerzte es 
frueher nicht ab. Als Nicht-Experte kann ich im angehaengten Log nichts 
verdaechtiges erkennen. Die Kiste ist gestern irgendwann nach 12:30 UTC 
abgestuerzt, da hatte ich das letzte Mal einen File drauf abgespeichert 
und einige Stunden spaeter war sie weder per Samba Share noch per ssh 
erreichbar. Rauchmeldungen, Todesanzeigen oder aehnliches kurz vor dem 
Absturz kann ich keine im Log sehen.

Seltsam fand ich diese Log-Eintraege:

Nov 06 14:42:21 alarm systemd-timesyncd[237]: System clock time unset or 
jumped backwards, restorin>
-- Reboot --
Feb 12 21:25:39 alarm smbd[21146]: pam_unix(samba:session): session 
opened for user joerg by (uid=0)

Ich habe weder Uhrzeit/Datum per Hand geaendert noch einen Re-Boot 
ausgeloest.

Dann noch eine Fehlermeldung:

Feb 12 21:31:09 alarm dbus-daemon[248]: [system] Activation via systemd 
failed for unit 'dbus-org.f>

Dazu fand ich aber nur Hinweise, dass das eher eine Art "Noisy Bug" sei:

https://forum.manjaro.org/t/systemd-homed-annoyance-when-disabled-the-journal-log-is-literally-spammed/32498

Auszug aus dem Log, sehr lang, vier Kommentare von mir in eckigen Klammern:


[root@alarm joerg]# journalctl -r --utc
-- Logs begin at Wed 2019-11-06 14:42:08 UTC, end at Sat 2021-02-13 
20:00:25 UTC. --

[Heutige normale Eintraege weggelassen]

Feb 13 19:42:36 alarm systemd-logind[262]: Session c1 logged out. 
Waiting for processes to exit.
Feb 13 19:42:36 alarm sshd[298]: pam_unix(sshd:session): session closed 
for user joerg
Feb 13 19:42:36 alarm sshd[323]: Disconnected from user joerg 10.0.0.223 
port 60614
Feb 13 19:42:36 alarm sshd[323]: Received disconnect from 10.0.0.223 
port 60614:11: disconnected by>
Feb 13 19:42:34 alarm systemd[1]: Started Daily man-db regeneration.
Feb 13 19:42:34 alarm systemd[1]: man-db.service: Succeeded.
Feb 13 19:42:24 alarm systemd[1]: Started Rotate log files.
Feb 13 19:42:24 alarm systemd[1]: logrotate.service: Succeeded.
Feb 13 19:42:24 alarm systemd[1]: shadow.service: Succeeded.
Feb 13 19:42:24 alarm systemd[1]: Started Verify integrity of password 
and group files.
Feb 13 19:42:23 alarm systemd[1]: Starting Daily man-db regeneration...
Feb 13 19:42:23 alarm systemd[1]: Starting Rotate log files...
Feb 13 19:42:23 alarm systemd-timesyncd[237]: Initial synchronization to 
time server [2601:603:b7f:>

[Hier war das Kasten abgestuerzt und reagierte nicht mehr auf ssh]

Feb 12 21:31:34 alarm systemd[1]: systemd-hostnamed.service: Succeeded.
Feb 12 21:31:17 alarm systemd[1]: Started Session c1 of user joerg.
Feb 12 21:31:17 alarm systemd[309]: Startup finished in 1.380s.
Feb 12 21:31:17 alarm systemd[309]: Reached target Main User Target.
Feb 12 21:31:17 alarm systemd[1]: Started User Manager for UID 1001.
Feb 12 21:31:17 alarm systemd[309]: Reached target Basic System.
Feb 12 21:31:17 alarm systemd[309]: Reached target Sockets.
Feb 12 21:31:17 alarm systemd[309]: Listening on D-Bus User Message Bus 
Socket.
Feb 12 21:31:17 alarm systemd[309]: Listening on p11-kit server.
Feb 12 21:31:17 alarm systemd[309]: Listening on GnuPG cryptographic 
agent and passphrase cache.
Feb 12 21:31:17 alarm systemd[309]: Listening on GnuPG cryptographic 
agent (ssh-agent emulation).
Feb 12 21:31:17 alarm systemd[309]: Listening on GnuPG cryptographic 
agent and passphrase cache (re>
Feb 12 21:31:17 alarm systemd[309]: Listening on GnuPG cryptographic 
agent and passphrase cache (ac>
Feb 12 21:31:17 alarm systemd[309]: Listening on GnuPG network 
certificate management daemon.
Feb 12 21:31:17 alarm systemd[309]: Starting D-Bus User Message Bus Socket.
Feb 12 21:31:17 alarm systemd[309]: Reached target Timers.
Feb 12 21:31:17 alarm systemd[309]: Reached target Paths.
Feb 12 21:31:16 alarm systemd[309]: pam_unix(systemd-user:session): 
session opened for user joerg b>
Feb 12 21:31:16 alarm systemd[1]: Starting User Manager for UID 1001...
Feb 12 21:31:16 alarm systemd[1]: Started User Runtime Directory 
/run/user/1001.
Feb 12 21:31:15 alarm systemd-logind[262]: New session c1 of user joerg.
Feb 12 21:31:15 alarm systemd[1]: Starting User Runtime Directory 
/run/user/1001...
Feb 12 21:31:15 alarm systemd[1]: Created slice User Slice of UID 1001.
Feb 12 21:31:15 alarm sshd[298]: pam_unix(sshd:session): session opened 
for user joerg by (uid=0)
Feb 12 21:31:15 alarm sshd[298]: Accepted password for joerg from 
10.0.0.223 port 60614 ssh2
Feb 12 21:31:09 alarm dbus-daemon[248]: [system] Activation via systemd 
failed for unit 'dbus-org.f>
Feb 12 21:31:09 alarm dbus-daemon[248]: [system] Activating via systemd: 
service name='org.freedesk>
Feb 12 21:31:09 alarm systemd[1]: Startup finished in 5.138s (kernel) + 
32.643s (userspace) = 37.78>
Feb 12 21:31:09 alarm systemd[1]: Reached target Graphical Interface.
Feb 12 21:31:09 alarm systemd[1]: Reached target Multi-User System.
Feb 12 21:31:09 alarm systemd[1]: Started Samba SMB Daemon.
Feb 12 21:31:06 alarm systemd[1]: Starting Samba SMB Daemon...
Feb 12 21:31:06 alarm systemd[1]: Started Samba NMB Daemon.
Feb 12 21:31:05 alarm systemd[1]: Started Login Service.
Feb 12 21:31:04 alarm systemd-logind[262]: New seat seat0.
Feb 12 21:31:04 alarm systemd[1]: Starting Samba NMB Daemon...
Feb 12 21:31:04 alarm systemd[1]: Reached target Network is Online.
Feb 12 21:31:04 alarm systemd[1]: Started Wait for Network to be Configured.
Feb 12 21:31:04 alarm systemd-timesyncd[237]: Network configuration 
changed, trying to establish co>
Feb 12 21:31:04 alarm systemd[1]: Started Hostname Service.
Feb 12 21:31:04 alarm dbus-daemon[248]: [system] Successfully activated 
service 'org.freedesktop.ho>
Feb 12 21:31:03 alarm sshd[266]: Server listening on :: port 22.
Feb 12 21:31:03 alarm sshd[266]: Server listening on 0.0.0.0 port 22.
Feb 12 21:31:03 alarm haveged[182]: haveged: fills: 0, generated: 0
Feb 12 21:31:03 alarm haveged[182]: haveged: tot tests(BA8): A:1/1 B:1/1 
continuous tests(B):  last>
Feb 12 21:31:03 alarm haveged[182]: haveged: cpu: (VC); data: 16K (D); 
inst: 16K (D); idx: 11/40; s>
Feb 12 21:31:03 alarm haveged[182]: haveged: ver: 1.9.8; arch: generic; 
vend: ; build: (gcc 8.3.0 C>
Feb 12 21:31:03 alarm systemd[1]: Reached target Login Prompts.
Feb 12 21:31:03 alarm systemd[1]: Started Serial Getty on ttyS0.
Feb 12 21:31:03 alarm systemd[1]: Started Getty on tty1.
Feb 12 21:31:03 alarm systemd[1]: Started Permit User Sessions.
Feb 12 21:31:02 alarm systemd[1]: Starting Permit User Sessions...
Feb 12 21:31:02 alarm systemd-timesyncd[237]: Network configuration 
changed, trying to establish co>
Feb 12 21:31:02 alarm systemd-networkd[198]: eth0: DHCPv6 address 
2601:204:4001:49e0::6395/128 time>
Feb 12 21:31:02 alarm systemd[1]: Started OpenSSH Daemon.
Feb 12 21:31:02 alarm systemd-timesyncd[237]: Network configuration 
changed, trying to establish co>
Feb 12 21:31:02 alarm systemd[1]: Reached target Host and Network Name 
Lookups.
Feb 12 21:31:02 alarm systemd[1]: Reached target Network.
Feb 12 21:31:02 alarm systemd[1]: Started Network Name Resolution.
Feb 12 21:31:02 alarm systemd-resolved[236]: Using system hostname 'alarm'.
Feb 12 21:31:01 alarm systemd-networkd[198]: eth0: Gained IPv6LL
Feb 12 21:31:00 alarm systemd[1]: Starting Hostname Service...
Feb 12 21:31:00 alarm systemd-timesyncd[237]: Network configuration 
changed, trying to establish co>
Feb 12 21:31:00 alarm systemd-networkd[198]: eth0: DHCPv4 address 
10.0.0.55/24 via 10.0.0.1
Feb 12 21:31:00 alarm systemd-networkd[198]: eth0: Gained carrier
Feb 12 21:30:58 alarm systemd[1]: Starting Login Service...
Feb 12 21:30:58 alarm systemd[1]: Condition check resulted in SSH Key 
Generation being skipped.
Feb 12 21:30:58 alarm systemd[1]: Started D-Bus System Message Bus.
Feb 12 21:30:58 alarm systemd[1]: Reached target Basic System.
Feb 12 21:30:58 alarm systemd[1]: Reached target Sockets.
Feb 12 21:30:58 alarm systemd[1]: Listening on D-Bus System Message Bus 
Socket.
Feb 12 21:30:58 alarm systemd[1]: Reached target Timers.
Feb 12 21:30:58 alarm systemd[1]: Started Daily verification of password 
and group files.
Feb 12 21:30:58 alarm systemd[1]: Started Daily man-db regeneration.
Feb 12 21:30:58 alarm systemd[1]: Started Daily rotation of log files.
Feb 12 21:30:58 alarm systemd[1]: Reached target System Time Synchronized.
Feb 12 21:30:58 alarm systemd[1]: Reached target System Time Set.
Feb 12 21:30:58 alarm systemd[1]: Started Daily Cleanup of Temporary 
Directories.
Feb 12 21:30:58 alarm systemd[1]: Reached target System Initialization.
Feb 12 21:30:58 alarm systemd[1]: Started Network Time Synchronization.
Feb 12 21:30:58 alarm systemd-resolved[236]: Negative trust anchors: 
10.in-addr.arpa 16.172.in-addr>
Feb 12 21:30:58 alarm systemd-resolved[236]: . IN DS 20326 8 2 
e06d44b80b8f1d39a95c0b0d7c65d08458e8>
Feb 12 21:30:58 alarm systemd-resolved[236]: . IN DS 19036 8 2 
49aac11d7b6f6446702e54a1607371607a1a>
Feb 12 21:31:00 alarm dbus-daemon[248]: [system] Activating via systemd: 
service name='org.freedesk>
Feb 12 21:31:01 alarm kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link 
becomes ready
Feb 12 21:31:01 alarm kernel: mv643xx_eth_port mv643xx_eth_port.0 eth0: 
link up, 1000 Mb/s, full du>

[Weder die Umstellung von Datum/Zeit noch der Re-Boot wurden von mir 
ausgeloest]

Nov 06 14:42:21 alarm systemd-timesyncd[237]: System clock time unset or 
jumped backwards, restorin>
-- Reboot --
Feb 12 21:25:39 alarm smbd[21146]: pam_unix(samba:session): session 
opened for user joerg by (uid=0)
Feb 12 16:55:54 alarm systemd-networkd[200]: eth0: DHCPv6 address 
2601:204:4001:49e0::6395/128 time>
Feb 12 16:34:31 alarm kernel: usb 1-1: reset high-speed USB device 
number 2 using orion-ehci
Feb 12 16:09:02 alarm kernel: usb 1-1: reset high-speed USB device 
number 2 using orion-ehci
Feb 12 08:00:29 alarm systemd[1]: Started Daily man-db regeneration.
Feb 12 08:00:29 alarm systemd[1]: man-db.service: Succeeded.
Feb 12 08:00:20 alarm systemd[1]: Started Rotate log files.
Feb 12 08:00:20 alarm systemd[1]: logrotate.service: Succeeded.
Feb 12 08:00:20 alarm systemd[1]: shadow.service: Succeeded.

[Aeltere Eintraege weggelassen]


Sieht jemand etwas verdaechtiges?

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web