Das Problem scheint nicht an akonadi oder so direkt zu liegen. Die Datenbank schein beschädigt zu werden wenn Akonadispezifische Daten ausgetauscht werden (upgrade) wärend Akonadi läuft und im Hintergrund eine aktion durchführt (was es logischerweise ständig tut, solange es läuft). Über den Email Indexer wirkt sich das dann auf Nepomuk aus. Nepomuk selbst ist seit Weggang von Strigi ja nun endlich stabil, jedenfalls wenn du nach upgrade auf 4.10 nepomukcleaner gestartet hast..
In Zukunft also akonadi anhalten vor den Upgrade. Besser mit dem Paketbetreuer reden, damit es eine Möglichkeit gefunden wird akonadi automatisch vor dem Upgrade zu stoppen.
In Zukunft also akonadi anhalten vor den Upgrade. Besser mit dem Paketbetreuer reden, damit es eine Möglichkeit gefunden wird akonadi automatisch vor dem Upgrade zu stoppen.
Wie wäre es denn mit vorher ausloggen und dann zypper update...
Ein Update genügt und die ganze Chose zerschießt sich selbst?
Der Updatemechanismus in Linux ist einfach kaputt. Der Paketmanager überschreibt einfach mal die libraries im Dateisystem und das ganze nicht transaktional. Gute Idee. Ich sehe regelmäßig crash reports verursacht wegen Updates.
"Nur meine eigne schwarze Seele sei frei von jeder Schuld und fehle!"
Die Überheblichkeit, die gerade aus Richtung der Entwickler der beiden grossen Desktopumgebungen gegenüber denen die diesen Kram einfach nur benutzen wollen immer wieder zu Tage tritt, kotzt mich nicht erst seit heute an!
ob das ausgerechnet mit diesem problem zusammenhängt, kann ich nicht sagen (was martin beschreibt, führt normalerweise zu einem segfault) aber das problem scheint eigentlich nur bei einer einzigen distribution aufzutreten und es tritt dermaßen häufig auf, daß man davon ausgehen muß, daß, um es vereinfacht auszudrücken, "install" mit "cp" ersetzt wurde, was alles aus dem tritt bringen wird, das auf in den speicher geblendeten festplatteninhalt (im zweifel noch nicht verwendeten code des binaries oder verlinkter libs) zugreift, welcher dann "heimlich" vom installer ausgetauscht wurde.
ob das in diesem fall greift, kann ich nicht sagen, aber nichtsdetotrotz sollte dieses anscheinend distrospezifische verhalten des updaters angepaßt werden und ansonstem wäre ubuntunutzern ganz generell zu raten, updates nur aus runlevel 1, resp. offline (also aus einer parallelinstallation) durchzuführen.
oder man passt das Programm dementsprechend an, so dass es selbst bei "cp" nicht mehr zu solchen Fehlern kommt. Denn:
1. will ich als User nicht wissen, warum etwas nicht funktioniert - ich will schlicht und einfach dass es funktioniert.
2. wenn ich ein Teil konstruiere und es fällt aus, weil es von links nach rechts gebogen wird, statt von rechts nach links - dann muss ich es umkonstruieren, so dass es in allen use-cases hält und funktioniert. Genau so "einfach" stelle ich mir das auch mit KDEPIM und Akonadi/ Nepomuk vor. Es gibt ja schließlich noch andere Datenbanken (Amarok z.B.), die auch nicht von einem Update kaputtgehen = Beweis, dass es auch ohne kaputtgehen geht.
Das "Programm" wäre dann wahlweise das Dateisystem (copy-on-write, ZFS oder btrfs haben das Problem entsprechend nicht mehr) oder evtl. noch der kernel.
Die Anwendung (*jede*) ist völlig Schutzlos wenn unqualifiziert ihr Speicher manipuliert wird (auch sehr beliebt dafür: "bleachbit" -whitelist gesteuertes inodeüberschreiben - ja sicher...) Allenfalls könnte man den Speicher hashen und den hash laufend abgleichen.
Ich will jetzt mal nicht lange diskutieren, ob derartiger overhead noch angemessen wäre...
"Install" und die Mechanismen dahinter existieren schlicht nicht umsonst.
Darüberhinaus und wie deutlich gesagt: ich weiß nicht, was da bei akonadi kaputtgeht (benutze ich nicht) und ob das durch dieses spezielle updateverhalten verursacht wird.
Nur, dieses von Martin angeschnittene spezielle updateverhalten scheint es zu geben und die Schuld für die natürlichen Konsequenzen dessen (es crasht iA. spätestens wenn eine dlopen lib ausgetauscht wird) sind ganz sicher weder bei linux, noch libc oder gar den Anwendungen zu suchen. Die fehlerhafte Komponente wäre (im Fall dieses anscheinenden Verhaltens) dann hier klar der Installer.
Versuch mal folgendes im terminal:
nepomukcleaner
#(Dann diesen starten und durchlaufen lassen)
#(wenn fertig dann noch)
akonadictl stop &&sleep 20
akonadictl fsck
akonadictl vacuum
akonadictl fsck
Das Problem scheint nicht an akonadi oder so direkt zu liegen. Die Datenbank schein beschädigt zu werden wenn Akonadispezifische Daten ausgetauscht werden (upgrade) wärend Akonadi läuft und im Hintergrund eine aktion durchführt (was es logischerweise ständig tut, solange es läuft). Über den Email Indexer wirkt sich das dann auf Nepomuk aus. Nepomuk selbst ist seit Weggang von Strigi ja nun endlich stabil, jedenfalls wenn du nach upgrade auf 4.10 nepomukcleaner gestartet hast..
In Zukunft also akonadi anhalten vor den Upgrade. Besser mit dem Paketbetreuer reden, damit es eine Möglichkeit gefunden wird akonadi automatisch vor dem Upgrade zu stoppen.
Hallo,
platt gefragt: woher weißt du, was da zu tun ist? Wie kann man tiefer in KDE einsteigen, gibt es da eine geeignete Dokumentation?
E.
wo bekommt man nepomukcleaner denn her? finde es nicht mit apt-get
huch, bin noch auf 4.9... problem zwar nicht gelöst, aber erkannt
Ich habe gehört, dass es bald ein neues Tool geben soll, nepomukundakonadieradicator.
Jetzt einmal im Ernst, das ist KDE 4.10.x und die KDEPIM-/Nepomuk-/Akonadi-Softwaregeschichte funktioniert immer noch nicht hundertprozentig?
Ein Update genügt und die ganze Chose zerschießt sich selbst?
Jaja in LINUX ist der kaputt, scheiss Linux mit seinem integrierten...packetsystem
"Nur meine eigne schwarze Seele sei frei von jeder Schuld und fehle!"
Die Überheblichkeit, die gerade aus Richtung der Entwickler der beiden grossen Desktopumgebungen gegenüber denen die diesen Kram einfach nur benutzen wollen immer wieder zu Tage tritt, kotzt mich nicht erst seit heute an!
Ich wollte damit nur darauf hinweisen, dass es andere Gründe geben kann warum es gerade bei einem Update zu Problemen führt.
ob das ausgerechnet mit diesem problem zusammenhängt, kann ich nicht sagen (was martin beschreibt, führt normalerweise zu einem segfault) aber das problem scheint eigentlich nur bei einer einzigen distribution aufzutreten und es tritt dermaßen häufig auf, daß man davon ausgehen muß, daß, um es vereinfacht auszudrücken, "install" mit "cp" ersetzt wurde, was alles aus dem tritt bringen wird, das auf in den speicher geblendeten festplatteninhalt (im zweifel noch nicht verwendeten code des binaries oder verlinkter libs) zugreift, welcher dann "heimlich" vom installer ausgetauscht wurde.
ob das in diesem fall greift, kann ich nicht sagen, aber nichtsdetotrotz sollte dieses anscheinend distrospezifische verhalten des updaters angepaßt werden und ansonstem wäre ubuntunutzern ganz generell zu raten, updates nur aus runlevel 1, resp. offline (also aus einer parallelinstallation) durchzuführen.
oder man passt das Programm dementsprechend an, so dass es selbst bei "cp" nicht mehr zu solchen Fehlern kommt.
Denn:
1. will ich als User nicht wissen, warum etwas nicht funktioniert - ich will schlicht und einfach dass es funktioniert.
2. wenn ich ein Teil konstruiere und es fällt aus, weil es von links nach rechts gebogen wird, statt von rechts nach links - dann muss ich es umkonstruieren, so dass es in allen use-cases hält und funktioniert. Genau so "einfach" stelle ich mir das auch mit KDEPIM und Akonadi/ Nepomuk vor. Es gibt ja schließlich noch andere Datenbanken (Amarok z.B.), die auch nicht von einem Update kaputtgehen = Beweis, dass es auch ohne kaputtgehen geht.
Das "Programm" wäre dann wahlweise das Dateisystem (copy-on-write, ZFS oder btrfs haben das Problem entsprechend nicht mehr) oder evtl. noch der kernel.
Die Anwendung (*jede*) ist völlig Schutzlos wenn unqualifiziert ihr Speicher manipuliert wird (auch sehr beliebt dafür: "bleachbit" -whitelist gesteuertes inodeüberschreiben - ja sicher...)
Allenfalls könnte man den Speicher hashen und den hash laufend abgleichen.
Ich will jetzt mal nicht lange diskutieren, ob derartiger overhead noch angemessen wäre...
"Install" und die Mechanismen dahinter existieren schlicht nicht umsonst.
Darüberhinaus und wie deutlich gesagt:
ich weiß nicht, was da bei akonadi kaputtgeht (benutze ich nicht) und ob das durch dieses spezielle updateverhalten verursacht wird.
Nur, dieses von Martin angeschnittene spezielle updateverhalten scheint es zu geben und die Schuld für die natürlichen Konsequenzen dessen (es crasht iA. spätestens wenn eine dlopen lib ausgetauscht wird) sind ganz sicher weder bei linux, noch libc oder gar den Anwendungen zu suchen.
Die fehlerhafte Komponente wäre (im Fall dieses anscheinenden Verhaltens) dann hier klar der Installer.
Ist nicht oder schwer möglich, je nach Anwendung..