Leap 42.3 - System zerstört sich selbst

Hinweis: In dem Thema Leap 42.3 - System zerstört sich selbst gibt es 59 Antworten auf 6 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Danke.


    Ich war unterwegs, habe Futter (Löwenzahn) für meine Meeris gesucht, deshalb die Pause.
    Ich habe den Befehl eingegeben, hier:


    Befehl, als root an der Textkonsole eingegeben:
    systemctl list-timers > /home/benutzername/ausgabe.txt



    die Ausgabe (aus der Textdatei raus kopiert):



    NEXT LEFT LAST PASSED UNIT ACTIVATES
    Fri 2018-07-13 19:20:51 CEST 11min left n/a n/a systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
    Sat 2018-07-14 00:00:00 CEST 4h 50min left Fri 2018-07-13 13:16:30 CEST 5h 52min ago logrotate.timer logrotate.service
    Mon 2018-07-16 00:00:00 CEST 2 days left Mon 2018-07-09 16:17:45 CEST 4 days ago fstrim.timer fstrim.service



    3 timers listed.
    Pass --all to see loaded but inactive timers, too.


    ******************************************


    als ich unterwegs war, habe ich mir auch so meine Gedanken gemacht.
    Es steht hier nämlich noch ein dritter Rechner rum, mit beinahe der gleichen Konfiguration.
    Ich benutze ihn nicht so oft, und wenn, dann meist nur zum Transcodieren von Filmen.
    Da ist so etwas noch nie passiert, der läuft und läuft, hat noch nie von sich aus Dateien gelöscht.
    Aber es gibt einen großen Unterschied: da ist das komplette System mit dem Dateisystem XFS installiert worden.


    Und weil ich auch am Suchen bin:
    Ich habe in den Ordnern /etc/cron.monthly und /etc/cron.weekly Links gefunden, die sich mit dem
    btrfs Dateisystem befassen.
    - ob das wohl stört ?
    Auf jeden Fall denke ich mal, daß ich dies nicht brauche, weil ich hier das etx4 Dateisystem habe.
    Ob es wohl etwas bringt, wenn ich diese Links in meinen Ordner (vorsichtshalber) verschiebe?
    - auf jeden Fall muss ich dann wieder einen Monat warten, ob das Problem wieder auftritt.
    - - -

  • Danke. Das habe ich jetzt auch gemacht.
    Es kann ja sein, dass dies mein Problem löst.
    Hoffentlich ...

  • Und was Sauerland schon schrieb...
    Dein Kernel ist nicht aktuell.


    Abgesehen davon, dass du noch Leap 42.3 im Einsatz hast, wäre evtl. ein manuelles Update nicht verkehrt, falls noch andere Updates fehlen.


    Als Root:
    zypper clean -a
    zypper ref
    zypper up


    Berichte mal (-:

    Für den Inhalt des Beitrages 122621 haftet ausdrücklich der jeweilige Autor: sterun

  • Ja, vor den Updates erstelle ich aber ein Backup, nur zur Sicherheit.
    Dann lasse ich mal die 3 Befehle zum Aktualisieren drüber, na ja, irgendwann wird dann
    eh die neuste Version von OpenSuSE installiert.
    Vermutlich wird das dann ein XFS Dateisystem ...


    Ich kann es nicht wirklich begründen, aber:
    Tja, und irgendwie habe ich jetzt ein gutes Gefühl, nachdem die Scripte
    für das Dateisystem btrfs weg sind;
    es könnte gut sein, dass in Zukunft das System fehlerlos läuft.


    Leider kann ich darüber erst nach einem längeren Zeitraum berichten,
    weil der Fehler nicht ständig aufgetreten ist, sondern so in etwa einmal im Monat ...


    Ich werde in Zukunft berichten, ob es etwas gebracht hat.
    => Vielen Dank, an alle, die geholfen haben !

  • Ganz sicher nicht.
    Ganz sicher nicht hat dein Problem mit dem aktuellen Dateisystem zu tun.
    Auch die Pakete für Btrfs spielen keine Rolle. Die hängen halt ungenutzt im System rum.


    Es ist egal, ob ein Job via Cron oder via systemd.timer angestossen wird.
    Natürlich sind die Systemd.Timer modern, aber aus Kompatibilitätsgründen tun alle Cronjobs genau das Gleiche. Es bleibt gleich.
    Dein Systemd.Timer Listing zeigt nur Standardjobs. Kein Thema für dein Problem.


    Ob es ein Script gibt, das -egal ob via Cronjob oder sonstwie getriggert- dieses Verhalten verursacht, wirst du erst wissen, wenn der avisierter Grep- Befehl endete.
    Der Rest ist Quark.
    (Und ich glaube nicht an diese Möglichkeit)


    Wenn du kein Btrfs verwendest, kannst du getrost alle zugehörigen Cronjobs löschen. Das gebietet sogar elementare Vernunft. (Es sei denn, man arbeitet für die Bundesanstalt für Arbeit)


    Die Hoffnung, dass es sich mit deinen garantiert nicht hilfreichen Maßnahmen bessere, ist nichtig.


    Dein Problem kann auch nicht mit älteren Kernel zusammenhängen, oder mit irgendwelchen Updates.


    Du hast ein ganz anderes Problem.

  • Hier möchte ich Kononentux antworten:


    wie ich das System im Problemfall wiederherstelle ?
    Nun, aus Bequemlichkeit verwende ich meist Acronis, das boote ich von einem USB Stick.
    Wenn das System gut läuft, dann mache ich von der ext4 Partition von SuSE und von der FAT16 EFI Partition ein Backup auf den NAS.
    Und wenn ein Unglück passiert kann ich wieder von dem Stick booten und beide Partitionen wiederherstellen.
    Das funktioniert gut, aber Acronis kostet Geld.


    Ich weiß noch eine zweite Möglichkeit, die nichts kostet, die verwende ich auch ab und zu:
    man holt sich eine Live CD/DVD – Knoppix oder SuSE Live zum Beispiel.
    Davon boote ich dann, und wechsle als root auf die Textkonsole.
    Dort mache ich im RAM zwei Ordner: /1 und /2 .
    dann mounte ich die Partition, die SuSE enthält, auf /1 und einen externen Datenträger oder eine weitere Partition auf /2 . „blkid“ kann bei der Auswahl helfen.
    Nun in die /1 Partition rein gehen: cd /1
    Jetzt kommt ein längerer Befehl:
    tar -czvpf /2/backup.tgz [hier in der Klammer bitte die Anfangsbuchstaben aller Ordner unter /1 eingeben]*
    als Beispiel – Deine Ordner musst Du selber wissen:
    tar -czvpf /2/backup.tgz [orbdehlmpstuv]*
    Wenn das fertig ist, dann liegt die Backup Datei unter /2 .
    Dann:
    sync
    umount /1
    umount /2


    Wiederherstellen im Problemfall geht so:
    wieder vom Live System booten, und wie oben beschrieben /1 und /2 anlegen und mounten.
    Dann die Datei backup.tgz nach /1 kopieren.
    Nun in die /1 Partition rein gehen: cd /1
    Jetzt kommt der Befehl zum Wiederherstellen:
    tar -xzvpf backup.tgz (also hier ein „x“ statt dem „c“)
    Wenn das erledigt ist kann man unter /1 die Datei backup.tgz löschen.
    Dann:
    sync
    umount /1
    umount /2


    => so kann es beispielsweise gehen, ohne Geld auszugeben ….


    andere Anwender wissen bestimmt noch mehr Möglichkeiten ....

  • borgbackup


    Ist open source, kostet also nichts.
    Dafür schreibt es auch via Netz vollständig deduplizierte Backups, sogar verschlüsselt und Spaswort geschützt, und bringt sogar ein Filesystem mit, womit man jeden verschlüsselten Backup einfach mounten kann.


    Es gibt derzeit nichts, was auch nur annähernd an borgbackup rankommt.

  • Zitat von albert_ernst

    ohne Geld auszugeben ….

    Tip - gehe auf die Suche nach fsarchiver. Sehr umfangreiches aber auch einfach zu bedienendes tool.
    Gibt auch ein Suse Paket mit GUI und eine Boot-CD.


    System kann man im laufenden Betrieb imagen oder alles möglich backupen. Zusammenarbeit mit einem NAS = problemlos, auch mit der Boot-CD.

    Für den Inhalt des Beitrages 122641 haftet ausdrücklich der jeweilige Autor: muck