[gelöst] Thunderbird- und Firefoxprofil nicht zugänglich

Message

cryptosteve · Post by **cryptosteve** » Mon May 19, 2014 4:15 pm

Moin,
nachdem ich meine ~amd64-Kiste heute gebootet habe, sind meine Firefox- und Thunderbirdprofile plötzlich nicht zugänglich:

Code: Select all

[Mo, 19.05.2014, 18:04:15]
[stell @ sorum:~]% thunderbird

(process:6948): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Error: Access was denied while trying to open files in your profile directory.

Und zusätzlich als Window:

Code: Select all

Your Thunderbird profile cannot be loaded. It may be missing or inaccessible

.

Bei Firefox analog das gleiche. Im Gentooforum.de hat jemand schonmal das gleiche Problem berichtet, aber offenbar ebenfalls ohne Lösung.

Wenn Starten via "-ProfileManager" oder "-safe-mode" bringt genauso wenig Abhilfe, wie das Beiseiteräumen von ~/.thunderbird resp. ~/.mozilla. In diesen Fällen wird das Verzeichnis ohne Inhalt neu eingerichtet.

Die Permissions der Verzeichnisse und Dateien selbst sind in Ordnung, bislang hat das auch reibungslos funktioniert. Die Festplatte ist ebenfalls in Ordnung.

Hat jemand das gleiche Problem? Jemand noch 'ne besondere Idee?

cryptosteve · Post by **cryptosteve** » Mon May 19, 2014 4:15 pm

Verdammt, falsches Forum ... ich beantrage mal eine Verschiebung

Edit: requested via #gentoo-forums, done by jmbsvicetto, thanks

jmbsvicetto · Post by **jmbsvicetto** » Mon May 19, 2014 4:19 pm

Moved from Diskussionsforum to Deutsches Forum (German) as requested by cryptosteve.

frank9999 · Post by **frank9999** » Mon May 19, 2014 4:31 pm

Hast du auch eine NVIDIA GPU?

Wenn ja sieh mal hier:
http://forums.gentoo.org/viewtopic-t-991136.html

cryptosteve · Post by **cryptosteve** » Mon May 19, 2014 4:46 pm

Ja, habe ich, allerdings auch OpenRC. Zudem lief es bis gestern ja einwandfrei.

Auf die Gefahr hin, derzeit etwas begriffsstutzig zu sein, aber ich sehe aktuell nicht ganz, wo mir der genannte Thread weiterhelfen soll.

frank9999 · Post by **frank9999** » Mon May 19, 2014 5:12 pm

cryptosteve wrote:Ja, habe ich, allerdings auch OpenRC. Zudem lief es bis gestern ja einwandfrei.

Auf die Gefahr hin, derzeit etwas begriffsstutzig zu sein, aber ich sehe aktuell nicht ganz, wo mir der genannte Thread weiterhelfen soll.

Nun ich erhalte zumindest den ersten Teil deiner Fehlermeldung ebenfalls:
"glib-critical ** g_slice_set_config assertion 'sys_page_size == 0' failed"

Von daher könnte es dort einen Zusammenhang geben

An systemd oder openrc liegt es bei mir nicht.
Nutzt du auch die x11-drivers/nvidia-drivers ?

Bei mir sind die Probleme aus dem Thread mit dem Nouveau Treiber nun nicht mehr vorhanden, dafür aber andere neue (Temperatur, Leistung, etc.)....

Jean-Paul · Post by **Jean-Paul** » Mon May 19, 2014 5:17 pm

GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

Ich habe den gleichen Fehler in meiner xsession.log, nur läuft Firefox bei mir normal.

Gib diese Meldung mal so in die Google-Suchzeile ein, du wirst erstaunt sein wie lange dieser Bug schon existiert.
Manchmal werden auch "Lösungen" angeboten, die zumindest bei mir nicht greifen.

Sorry, aber auch ich habe eine Lösung.

cryptosteve · Post by **cryptosteve** » Mon May 19, 2014 5:36 pm

Ja, ich nutze auch nvidia-drivers.

Und ich könnte schwören, dass ich den hier gequoteten Fehler schon seit gefühlten Ewigkeiten habe. Das hat hier bislang aber nie als Showstopper fungiert. Nee nee, irgendwas anderes muss hier plötzlich suggerieren, das Profil sei verlustig oder schreibgeschützt.

Und ich stelle gerade fest, dass mein spotify-blob auch maulig ist:

Code: Select all

[ 9945.937199] blob[19689]: segfault at 0 ip 00007f6adabbbebc sp 00007fff7fb8e9c0 error 4 in libspotify.so.12.1.45[7f6adaa1e000+25c000]
[ 9949.161377] blob[19699]: segfault at 0 ip 00007fc7d9aecebc sp 00007fff0b883140 error 4 in libspotify.so.12.1.45[7fc7d994f000+25c000]
[ 9950.511370] blob[19707]: segfault at 0 ip 00007f129ce76ebc sp 00007ffff46d37e0 error 4 in libspotify.so.12.1.45[7f129ccd9000+25c000]

So'n Ärger, ich hab gerade gar keine Lust zu basteln

cryptosteve · Post by **cryptosteve** » Tue May 20, 2014 4:47 pm

Moin,
so, nachdem ich verzweifelt rumgebaut und ausprobiert habe (mit nouveau wurde nichts besser), konnte ich dem Problem heute nach planlosem Brainstorming in #gentoo.de auf den Grund gehen.

Ich habe gemäß Gentoo-Wiki SSD mein XDG_CACHE ins tmpfs nach /tmp/cache gelegt. Seit neustem stimmen dort offenbar die Berechtigungen nicht mehr, denn das Verzeichnis hatte jetzt plötzlich

Code: Select all

[stell @ sorum:/tmp]% ls -ld cache 
drwxr-xr-x 3 kdm kdm 60 20. Mai 18:38 cache

Nach einem testweisen "chmod 0777" funktioniert der Aufruf aller oben genannten Programme wieder. Man, da soll mal einer drauf kommen.

Und jetzt gehe ich ermitteln, warum die Rechte plötzlich nicht mehr passen ....

cryptosteve · Post by **cryptosteve** » Tue May 20, 2014 5:34 pm

Als Ergänzung im englischen Forenteil: http://forums.gentoo.org/viewtopic-t-990616.html

Jean-Paul · Post by **Jean-Paul** » Tue May 20, 2014 6:02 pm

cryptosteve wrote:Und jetzt gehe ich ermitteln, warum die Rechte plötzlich nicht mehr passen ....

Der Firefox-Cache liegt bei mir auch in /tmp bzw. im RAM.

Die 30xdg-data-local

cat /etc/env.d/30xdg-data-local
XDG_DATA_DIRS="/usr/local/share"
COLON_SEPARATED="XDG_DATA_DIRS XDG_CONFIG_DIRS"
XDG_CACHE_HOME="/tmp/.cache"

In der fstab gebe ich die Rechte aber mit (mode=1777)

tmpfs /tmp tmpfs nodev,nosuid,mode=1777 0 0

Und es funktioniert Out of the Box

ls -al /tmp
drwx------ 3 jean jean 60 20. Mai 19:51 .cache

cryptosteve · Post by **cryptosteve** » Tue May 20, 2014 6:30 pm

Hi,

Jean-Paul wrote:In der fstab gebe ich die Rechte aber mit (mode=1777)

das ist hier genauso, aber funktionieren tut es neuerdings leider nicht mehr out of the box.

Darf ich mal fragen, ob Du stable oder testing hast?

Jean-Paul · Post by **Jean-Paul** » Tue May 20, 2014 6:38 pm

Ich fahre im Prinzip stable.

ACCEPT_KEYWORDS="amd64"

Einige Pakete habe ich jedoch in die keywords eingetragen (kernel, firefox, pekwm, ...).
Also eigentlich so, wie man es nicht machen soll, aber mein System läuft super.

cryptosteve · Post by **cryptosteve** » Tue May 20, 2014 6:50 pm

Ok, hier läuft ~amd64 und die Änderung hat sich erst kürzlich eingeschlichen.

Ich habe es jetzt vorerst mit einem Workaround via /etc/local.d/ umschifft und überlege, ob ich nicht gänzlich darauf verzichte, den XDG_CACHE auszulagern.