Kmail4 ---Kmail5?
... mag sein, mit dem Problem hat das aber m.E. nichts zu tun.
Als das Problem aufgetreten ist, habe ich nur unter 42.2 gearbeitet und habe dort Mails mit und ohne Anhänge völlig problemlos versendet bzw. empfangen. Das auslösende Ereignis ist mir nach wie vor unklar.
Mit der Fehlermeldung selbst kann ich erst recht nichts anfangen, sonst würde ich mal Berechtigungen checken,
Hallo,
ich benutze KMail und Leap 42.2.
Seit gestern meldet KMail bei mir bei allen Operationen, die irgendetwas mit Dateizugriffen zu tun haben (Anhang lösen, Anhang anhängen, Export der KMail-Einstellungen) den Fehler: "Der Prozess für das Protokoll file wurde unerwartet beendet."
Ich bin mir keiner Änderung an KMail bewußt, mal abgesehen davon, daß gestern ein update (per automatische Aktualisierung) eingespielt wurde.
Der Fehler betrifft nur meinen Account. Ein anderer Benutzer kann ohne weiteres Dateien an (seine) Mails anhängen bzw. lösen.
Wenn ich den Rechner unter 13.2 starte, mich mit meinem Benutzer-Namen dort anmelde, dabei die gleiche home-Partition , gleichen $HOME-Ordner benutze (Benutzer-ID / Gruppen-ID sind auch gleich), dann funktioniert dort KMail einwandfrei (inklusive der Anhänge).
Ich sehe unter 42.2 alle Mails im Eingangsordner bzw. im Ordner gesendet, kann Mails ohne Anhänge auch erstellen und versenden.
$HOME-Partition ist zu 38% gefüllt. Es gibt also noch genügend Platz.
Weiß jemand, woran der Fehler liegen könnte? Mir fehlt ein wenig ein Anhaltspunkt.
Aber ohne präzise Info, kann man ebenso blind irgendwelche Tastenkombis mit irgendwas belegen und drücken.
genau das will ich nicht.
Bevor ich hier Blindflüge mache, mache ich etwas mir bekanntes und deshalb verwende ich einen ganz bestimmten Befehl. Wenn es dann weiter zickt, dann kann man den Befehl genauer anschauen.
Ohne dies weiß ich noch nicht einmal, was das System bisher getan hat und da hilft die Detailkenntnis meiner Hardware auch nicht.
ja klar habe ich den Befehl schon in meinem vorletzten Post genannt.
Der Unterschied ist:
Ich benutze kein Script mehr, sondern nutze die Bordmittel von Leap 42.2. Allerdings nutzen diese dann jetzt den genannten Befehl.
... ich habe jetzt unter Einstellungen-Systemeinstellungen-Kurzbefehle den Globalen Kurzbefehl Energieverwaltung-"Standby-Modus" deaktiviert.
Ich habe einen eigenen Kurzbefehl "Sleep" eingerichtet, der auf die Taste "Sleep" reagiert und als Aktion den Befehl
systemctl suspendausführt.
Wäre trotzdem interessant zu wissen, welchen Systembefehl der Standard Standby-Modus aktiviert.
... es ist (für mich wenigstens) gar nicht so leicht herauszufinden, was das System definitiv "tut", wenn ich per Tastatur (also durch einmalige Betätigung einer einzigen Taste) Suspend to ram anfordere. So habe ich es bisher angefordert.
Um das Problem näher einzukreisen, habe ich ein kleines Script geschrieben, welches nur den Befehl
systemctl suspendausführt. Auf den Desktop habe ich eine Verknüpfung gelegt, welche bei Klick darauf mein Script ausführt. Bis auf weiteres führe ich "Suspend to ram" nur noch per Mausklick auf. Mal sehen, ob das oben geschilderte Problem immer noch vorkommt.
Hallo,
Ich benutze seit einiger Zeit Leap42.2. Wenn ich den Rechner nicht nutze, aber weiß, daß ich ihn wenig später wieder benötige, versetze ich ihn in den Energiesparzustand (Suspend to ram). Das Wiederaufwachen geht damit dann sehr schnell. Ich habe eingestellt, daß der Rechner beim Resume den Bildschirm sperrt, ich muß also das Paßwort eingeben.
Unter Leap 42.2 habe ich mit der Funktion nun gelegentlich Probleme. "Gelegentlich" ist schwer zu quantifizieren, ich schätze, daß das Resume jedes 3. oder 4. Mal zickt.
Dabei erscheint dann statt der Anmeldemaske schlicht ein schwarzer Bildschirm. Der Mauszeiger ist sichtbar und kann bewegt werden.
Ich kann in diesem Zustand per ctrl-Alt-F6 eine Konsol-Login erzeugen (und mich dann z.B. als root anmelden und dann ggf per Init 6 den Rechner gezielt neu starten). In meinen graphischen Bildschirm komme ich damit aber nicht zurück.
Ich kann in diesem Zustand auch per ctrl-Alt-backspace den X-server neu starten. Wenn ich das tue, dann erhalte ich die Standard-Anmeldemaske und kann mich auch anmelden. Wenn ich dann aber später den Rechner runterfahren will, dann bleibt er hängen und mir bleibt nur noch der Griff zum Ausschalter.
Probiert habe ich die erfolglos Verwendung des Startparameters acpi_osi="Linux". Das hat zwar nichts geschadet, aber auch nichts genutzt.
Probiert habe ich die ausschließliche Verwendung von kdm (und sämtliche sddm-Pakete rausgeworfen). Das hat auch nichts geschadet, und auch nichts genutzt.
Das "Zicken" kann nach 30 min Suspend-Zeit auftreten, aber auch nach 24h Suspend-Zeit nicht auftreten.
Unter 13.2 habe ich bei gleicher Hardware Suspend to RAM in gleicher Art genutzt, ohne daß jemals ein Problem aufgetreten wäre.
Hat jemand eine Idee, an was das beschriebene Problem liegen könnte?
habe unter Einstellungen->Systemeinstellungen->Energieverwaltung die Bildschirm-Energieverwaltung deaktiviert.
Problem taucht jetzt nicht mehr auf.
Ich habe vorhin geschrieben:
Zitat von Suelkun... Ich habe deshalb Zweifel, ob wirklich der Display-Manager Verursacher des Problems ist.
Wenn ich es mir genau überlege, dann könnte sddm doch Problemverursacher sein. Die beiden Display-Manager (kdm / sddm) unterscheiden sich schon rein optisch voneinander. Gegenwärtig sieht der Anmeldebildschirm bei mir ziemlich ähnlich aus wie er unter 13.2 und nicht so, wie er ausgesieht, wenn ich 42.2 aus der Box neu installiere (das habe ich auch mal durchexerziert).
Nach "Resume from RAM" muß man sich erneut anmelden. Der dabei hochkommende Anmeldebildschirm sieht dem sddm - Anmeldebildschirm ziemlich ähnlich und ähnelt dem kdm-Anmeldebildschirm überhaupt nicht.
Kann das sein, daß nach "resume from RAM" auch dann sddm ins Spiel kommt, wenn man als Display-Manager kdm angewählt hat? Gibt es da irgendwo noch eine Stellschraube?