ok, dann ist ja alles in Butter.
Sleep und wakeup funktioniert mit meiner Mimik immer noch. Ich schließe deshalb diesen Thread.
Vielen Dank an alle, die mit ihren Kommentaren dazu beigetragen haben, daß ich eine Lösung für das Problem habe.
ok, dann ist ja alles in Butter.
Sleep und wakeup funktioniert mit meiner Mimik immer noch. Ich schließe deshalb diesen Thread.
Vielen Dank an alle, die mit ihren Kommentaren dazu beigetragen haben, daß ich eine Lösung für das Problem habe.
... derzeitiger Status:
Das aufgerufene Skript lautet nun:
Mit diesem Skript schläft das System auf Mausklick zuverlässig ein und wacht (bisher) ebenso zuverlässig wieder auf.
Ich habe außerdem die Taste "Sleep" so abgeändert, daß das gleiche Skript auf Tastendruck ausgeführt wird.
Die Anmerkung
Wenn du eh schon ein Script verwendest, dann solltest du dort NICHT den
Link aufrufen, sondern wirklich den tatsächlichen systemctl Aufruf samt
korrekten Argumenten.
verstehe ich nicht ganz. Ich verwende im Script den einen ganz normalen systemctl-Befehl. Ist das so, daß die Befehlsoption (in meinem Fall jetzt: hybrid-sleep) immer noch ein Link ist?.
... das sind eine ganze Reihe von Vorschlägen. Wird eine Zeitlang dauern, bis ich das alles durchgeschaut habe. Einiges kann ich aber jetzt schon sagen:
su -c "file $(which reboot)" liefert: /sbin/reboot: symbolic link to /usr/bin/systemctl
Meine swap-Partition (5 GB) ist tatsächlich deutlich kleiner als mein Memory (24 GB). Wenn ich die swap-Partition aber auf 30GB vergrößere, ändert das am beschriebenen Verhalten von hibernate nichts.
hibernate fährt bei mir den Rechner runter, dieses fatalerweise unter Umgehung meines Sicherungsskripts, mit dem ich alle Benutzer-Dateien auf eine Extra-Platte sichere, die dort noch nicht gesichert sind. Weil ich von außen nicht sehe, ob der Rechner per hibernate oder per shutdown gestoppt wurde, entsteht dabei die Gefahr, daß Dateien nicht gesichert sind (und wenn es meine eigene Schlamperei ist).
Ich habe aber beim Rumstöbern gesehen, daß ich auch noch einen Zustand hybrid-sleep habe. Den habe ich (bei größerer swap-Partition) mal aktiviert. Dabei fährt der Rechner auch in einen Zustand, bei dem keine Power-Lampe blinkt, das Erreichen dieses Zustands dauert auch keine 2-3s sondern ca. 30s, aber beim Start (Taste oder Maus-Bewegung) fährt der Rechner in den Sperr-Bildschirm hoch. Wenn ich das Paßwort eingabe, sind alle offenen Applikationen da.
Ich werde den Zustand hybrid-sleep erst einmal einige Zeit ausprobieren, ob der Rechner zuverlässig hochkommt. Die 20-30s wären mir egal.
Für die übrigen Vorschläge brauche ich noch ein wenig Zeit.
sterun, vielen Dank für den Hinweis. Im Zitat steht ja, daß diese Zustände ggf. je nach Hardware-Konfiguration nicht richtig funktionieren können.
Um es kurz zu machen: Auch hibernate funktioniert bei mir nicht richtig. Ich hatte oben auf den Post von Sauerland einige Unterschiede notiert. Hier noch ein paar neue:
4. Nach Suspend blinkt bei mir die Powerlampe, nach Hibernate ist sie aus. (das wäre für mich natürlich jetzt nicht unbedingt wichtig), aber daran habe ich sonst immer gesehen, ob der Rechner "richtig" runtergefahren ist oder nicht.
5. Ich hatte es oben schon bemerkt: Der Rechner bootet bei mir nach dem hibernate normal über Bios und grub ins normale Start-Menu. Wenn ich mich dort dann anmelde, dann fehlen die Applikationen, die ich bei Hibernate offen hatte. Das war ja das schöne an Suspend, daß die Applikationen offen blieben. D.h. ich konnte auch ein libreoffice-Dokument mitten im Text offen lassen und Suspend aufrufen. und danach waren alle Applikationen wieder da, ohne daß auch nur 1 Zeichen verloren gegangen wäre (wenn suspend denn funktionierte).
Diese Eigenschaft von Hibernate könnte allerdings auch damit zusammenhängen, daß ich als Kernel-Parameter in grub die Option "noresume" verwende. Ich habe eine swap-Partition, aber nach dem gewöhnlichen Booten will ich den Rechner clean.
In Kürze die ersten Unterschiede:
1. Es dauert einiges länger, bis der Rechner sich Schlafen legt (1-2s (suspend) vrs. 30 - 60s (hibernate))
2. Der Rechner bootet ganz normal übers Bios (Bei suspend (wenn es funktioniert): der Bios-Schirm wird gar nicht eingeblendet))
3. Es kommt der ganz normale Anmeldebildschirm (Bei suspend: der Sperr-Bildschirm).
ok, das ist ein Leichtes.
Ich versuche es mal und melde mich wieder, mit den Erfahrungen
Hallo,
Ich benutze Leap 42.3 und habe dort ein kleines Script geschrieben, mit dem ich den Rechner per Mausklick schlafen legen kann. Dieses nutze ich, wenn ich weiß, daß ich den Rechner eine Zeitlang nicht brauche, aber ggf. eine kürzere Zeit später wieder nutzen werde. Damit will ich erreichen, daß er schneller wieder hochkommt
Das Problem: Der Rechner schläft bei entsprechendem Mausklick zuverlässig ein, kommt aber bei Druck auf die Tastatur (oder Bewegen der Maus) nur unzuverlässig wieder hoch. Im Regelfall (wenn der Rechner richtig hochkommt) sehe ich den Sperrbildschirm, kann mich anmelden und weiterarbeiten. Im Fehlerfall läuft der Rechner zwar an (d.h. Lüfter fängt an zu laufen), ich sehe dabei keinen Sperrbildschirm und kann nichts eingeben. In diesem Zustand kann ich nur mit (längerem Druck) auf den Ausknopf den Rechner hart ausschalten und anschließend neu starten.
"Unzuverlässig hochkommen" heißt: jedes 3. oder 4. Mal startet das System nicht mehr richtig.
Das Skript:
Den Befehl "sync" habe ich eingebaut, damit das System wenigstens alles auf die Platten geschrieben hat, wenn ich später den Ausschalter betätigen muß.
Ich habe an Hardware:
Motherboard Asus M5A97, 24 GB Memory, CPU Phenom II / X6 1090T, Graphikkarte AMD HD 6450 1GB Sapphire, Graphikkartentreiber. drm
Um offen zu sein: Ich kämpfe schon einige Zeit mit dem Problem, komme z.Zt. nicht mehr weiter und bräuchte wenigstens Ideen.
Na gut, eine einfache Lösung für das geschilderte Problem scheint es nicht zu geben.
Ich habe:
1. eine neue home-Partition angelegt und den gesamten Inhalt der "alten" home-Partition unter Erhaltung deren Berechtigungen dahin kopiert
2. den Eintrag des Accounts mit den Schwierigkeiten umbenannt (_sav an den Ordnernamen angehängt)
3. die Sicherungskopie des fehlerhaften Accounts eingespielt (leider war diese etwas älter)
4. Mails und Adressbuch unter Verwendung von 13.2 vom fehlerhaften Account exportiert
5. fstab entsprechend angepaßt.
6. Mails und Adressbuch unter Verwendung von 42.2 in die restaurierte Sicherungskopie importiert.
7. Doppelte Mail-Einträge rausgeputzt.
Wenn noch etwas fehlen sollte, kann ich es mir vom gesicherten Home-Eintrag holen.
Ein paar Mal mußte ich dabei neu booten, aber jetzt läuft es wieder.
Zitat von Sauerlandzypper se -si kmail akonadi nepo
Mozart:/home/konrad # zypper se -si kmail akonadi nepo
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
S | Name | Typ | Version | Arch | Repository
---+------------------------------+-------+---------------+--------+--------------------------------
i+ | akonadi | Paket | 4.14.10-6.5.1 | x86_64 | Hauptaktualisierungs-Repository
i | akonadi-contact | Paket | 16.08.2-1.1 | x86_64 | Haupt-Repository (OSS)
i | akonadi-mime | Paket | 16.08.2-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | akonadi-runtime | Paket | 1.13.0-4.5 | x86_64 | Haupt-Repository (OSS)
i+ | akonadi-search | Paket | 16.08.2-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | kmail | Paket | 4.14.10-6.5.1 | x86_64 | Hauptaktualisierungs-Repository
i | libKF5AkonadiAgentBase5 | Paket | 16.08.2-2.1 | x86_64 | Haupt-Repository (OSS)
i | libKF5AkonadiContact5 | Paket | 16.08.2-1.1 | x86_64 | Haupt-Repository (OSS)
i | libKF5AkonadiCore5 | Paket | 16.08.2-2.1 | x86_64 | Haupt-Repository (OSS)
i | libKF5AkonadiMime5 | Paket | 16.08.2-1.1 | x86_64 | Haupt-Repository (OSS)
i | libKF5AkonadiPrivate5 | Paket | 16.08.2-2.1 | x86_64 | Haupt-Repository (OSS)
i | libKF5AkonadiSearch | Paket | 16.08.2-1.1 | x86_64 | Haupt-Repository (OSS)
i | libKF5AkonadiWidgets5 | Paket | 16.08.2-2.1 | x86_64 | Haupt-Repository (OSS)
i+ | libakonadi4 | Paket | 4.14.10-4.8 | x86_64 | Haupt-Repository (OSS)
i+ | libakonadiprotocolinternals1 | Paket | 1.13.0-4.5 | x86_64 | Haupt-Repository (OSS)
i+ | python-kde4-akonadi | Paket | 4.14.3-3.46 | x86_64 | Haupt-Repository (OSS)
Alles anzeigen
... ich glaube aber eher nicht, daß es ein allgemeines Problem ist. Andere Benutzer des Rechners haben das geschilderte Problem nicht. Soweit ich es verstehe, sind Probleme, deren Ursache im Paket-Bereich liegen, eher allgemeiner Natur.
Noch einen Hinweis: Der Fehler tritt auf, wenn ich in irgendeiner Art eine Datei aus einer Anwendung heraus referenzieren will. z.B. KMail mit Datei anhängen oder auch Firefox mit Datei hochladen.
Es öffnet sich darauf der Datei-Dialog und dann passiert der Fehler.
Zitat von SauerlandKmail aus der Konsole starten und dann die Ausgabe nach dem Fehler hier posten?????
ok.
Ich habe:
1. Eine Konsolfenster aufgemacht
2. Dort erst einmal das Kommando
eingegeben. Dann sieht man, welche Versionen (Qt, KDE, kmail) ich hier einsetze.
Dann das Kommando
kmail kam hoch und öffnete das Nachrichtenübersichtsfenster.
Ich bin auf den Punkt "Neue Nachricht" gegangen. Ein leeres Nachrichtenfenster kam hoch.
In diesem neuen Nachrichtenfenster bin ich auf den Punkt auf den Punkt "Anhängen" gegangen.
Dann kam der beschriebene Fehler.
Ich habe OK in der Fehlermeldung bestätigt und
Kmail beendet.
Ich habe alles an Ausgaben im Konsolfenster kopiert und in die unten angehängte Datei eingefüĵgt. Es war einfach zu viel, um die Ausgabe direkt zu posten.
Wenn ich richtig beobachtet habe, dann kam der Fehler mit der Zeile
Im übringen war es mir unmöglich, unter 42.2 aus dem Schreiben dieses Posts heraus eine Datei an den Post anzuhängen.
Ich mußte die Datei irgendwo speichern, dann 42.2 beenden, 13.2 anbooten und dann unter 13.2 diesen Post schreiben. Beim Versuch zum Anhängen der Datei an diesen Post kam der Fehler auch.