Dotaz: LibreOffice nefunkční pod uživatelským účtem

[Brad]

Zdravím,

mám Mageiu 5 x86-64 a v ní kancelářský balík LibreOffice 4.4.2.2 z repozitáře. Problém mám takový, že pod uživatelským účtem nelze žádný program spustit - při pokusu o zobrazení dokumentu (i jen spuštění samotného programu, např. Calcu, z menu) jen chvíli poskakuje ikona vedle kurzoru a program se nespustí. Pod rootem se program spustit podaří (po předchozím export $(dbus-launch) a následném libreoffice --calc), nicméně to není to, co bych potřeboval, je třeba tvořit a zobrazovat dokumenty pod běžným účtem. Neví někdo, kde je chyba a co s tím?

Podotýkám, že jsem hledal dle svého umu jak na netu, tak zde na fóru, ale nic co by mi pomohlo jsem nenašel... poradíte prosím?

---

---

Odpovědi

[Ruža Becelin]

co se stane kdyz se calc spusti v konzoli pod normalnim uzivatelem?

[Brad]

Jen problikne na pár desetin vteřiny splashscreen LibreOffice a zase se ztratí, jinak nic, program se nespustí. V konzoli to nic nehlásí, na chybové také ne, ani v logu jsem nic nenašel. Zkoušel jsem měnit práva složky libreoffice v uživatelském adresáři, ale to nepomohlo. Nevím jak se dopátrat, kde je chyba.

[Ruža Becelin]

zkus to spustit pres strace, jestli to vyhodi nejakou chybu

[Brad]

Vyřešeno, viz níže. Děkuji za ochotu.

[00000]

zrovna dneska se mi to taky stalo, je potřeba opravit přístupová práva k adresáři /home/uzivatel/.config/libreoffice a tamějším obsahu - tak, aby náležely uživateli a ne rootovi

[Brad]

U mne tento postup nezafungoval, nastavoval jsem jak /home/user/.config/libreoffice, tak /home/user/libreoffice - nepomohlo ani jedno.

[Brad]

Aha, tak zpět - přidal jsem k tomu typický windowsovský postup, tj. restart stroje, a už to funguje. Díky za radu.

[lertimir]

No pokud byly předtím než LO přestal fungovat byly nějaké aktualizace, tak to byl ten důvod. Typicky může při tom nastat nekonzistence verzí knihoven a programů a pak program nejede. Různá distra to řeší různě. Moje openSUSE příkazem zypper ps vypíše běžící procesy, které používají knihovny(soubory), které už nejsou na disku - tedy byly smazány v průběhu aktualizací a mohu se rozhodnout, co s procesy dělat. (typicky restart procesu) U LO mohla část běžet stále v operační paměti část a mezitím aktualizace vyměnila knihovny. U dlouhodobě jedoucích strojů, které se jen uspávají je to dobré hlídat.

[Brad]

Aktualizace nebyly, je to přímo distribuční verze, akorát jsem po instalaci přidal zrcadla zdrojů, nicméně tento kancelářský balík byl přítomen na CD a nainstalován z něj.

Po jisté době testování můžu konstatovat, že se LO nemá rád s Dolphinem, a to až do té míry, že pokud se za pomoci Dolphina otevře jakýkoliv soubor, který je asociován s libovolným z programů kancelářského balíku, tak se nejenže program nespustí a neotevře konkrétní soubor, ale navíc pak nejde až do restartu libovolný program z balíku spustit ani samotný.

Původně jsem podezíral Sambu na firemním serveru, protože se na ni dostanu právě jen přes Dolphina ale nedaří se mi ji připojit na stálo pro celý PC (vidí ji jen Dolphin, jiné programy ne), ale naposledy jsem tak zůstal viset na CDR souboru otevřeném z CD pro LO Draw, takže Samba v tom bude asi nevinně. Je to ovšem poněkud otravné, tím spíš že při připojení jakéhokoliv nového média automountem se automaticky otvírá jako správce souborů právě Dolphin.

[lertimir]

Původně jsem podezíral Sambu na firemním serveru, protože se na ni dostanu právě jen přes Dolphina ale nedaří se mi ji připojit na stálo pro celý PC (vidí ji jen Dolphin, jiné programy ne), ale naposledy jsem tak zůstal viset na CDR souboru otevřeném z CD pro LO Draw,takže Samba v tom bude asi nevinně. Je to ovšem poněkud otravné, tím spíš že při připojení jakéhokoliv nového média automountem se automaticky otvírá jako správce souborů právě Dolphin.

Tohle bylo třeba napsat hned na začátku. Pokud připojíte se k souborům pomocí Dolphina na smb share a jinak ne, tak se není co divit, že LO nefunguje. (fakticky ji musí vidět celé KDE) S Dolphinem byste stejně mohl být připojený třeba na SFTP server a pravděpodobně by vás nenapadlo spouště soubory na takto připojeném úložišti. se sambou je to stejně. Lokace souboru je nějaké url tvaru smb://server/adresar/soubor, ale to není lokace, které bude rozumět LO. stejně jako nebude rozumět lokaci sftp://server/soubor. Programy obecně pracují jen se soubory, které jsou v linuxovém stromu. To že některé programy zvládnou i výše jmenované lokace znamená, že k nim přistupují přes nějakou mezivrstvu. V případě KDE je to tuším kio (KDE input/output), které programům z KDE, které otvirají soubory přes kio umožní přístup i k takovéto lokaci. (fakticky stejně proběhne kopie do temporárního souboru, práce na něm a po uložení zase kopie zpět na vzdálený soubor) Jiné programy, které nejsou pro KDE ale takovou lokaci neznají a tím pádem při předhození takového jména souboru mohou padat.

Default automountu se dá nastavit na jakéhokoliv správce. Ale automount vzdálený share připojí do filesystému. pokud Sambu mountnu, nebo pokud si SFTP server připojím pomocí sshfs tak soubory mám ve filovem stromu a mohu se k nim dostat jakýmkoliv programem včetně LO.

[Brad]

Prosím čtěte ty příspěvky celé, psal jsem že je to na Sambě nezávislé, neboť se to stalo i při otevírání souboru z CD.

Navíc je aktuální stav takový, že ani aktualizace nezabrala - dneska se to stalo nezávisle na Dolphinu, pouze jsem se pokoušel otevřít přílohu z Thunderbirdu, a stejně to neprošlo. Někdy to funguje a jindy ne, je to závislé zřejmě na počasí, vlhkosti, tlaku a rosném bodu, nicméně už to neřeším, neboť jsem již předtím situaci obešel tak, že jsem nainstaloval Win do VirtualBoxu. Jak bude chvíle času tak ještě zkusím novější verzi LO, jinak jsem již rezignoval - v práci potřebuji pracovat.

[Brad]

Musím ovšem říci, že po vaší zmínce o aktualizacích mě napadlo se po nich mrknout, nějaké tam byly takže jsem je nainstaloval, a zdá se, že se to zatím chová korektně, zatím to „nemrzne”.

Pokud se dobře pamatuji, podobná situace byla kdysi i u Mageii 3 a Kate, to se taky nespustilo a vyřešila to aktualizace - dají se obecně ty aktualizace ještě někde stahovat, když už není podpora (MGA3 už má ukončenou podporu, totéž potká po čase i současnou distribuci, tak bych to rád věděl)?

[Brad]

Po delší době doplňuji, že problém nevyřešila ani aktualizace na LibreOffice 4.4.5, nicméně mohu též doplnit, že problém se vyskytuje i v i586 verzi systému Mageia 5, a ještě jednu informaci, a to tu že problém se týká i jiných programů LibreOffice Foundation, které ale nejsou zahrnuty v balíku LibreOffice (např LibreOffice Draw, Base)

Problém lze částečně obcházet tak, že hned po startu počítače se spustí a nechá někde na nějaké ploše spuštěný spouštěč balíku LibreOffice, z něj lze kdykoliv spustit cokoliv z tohoto balíku - ovšem jen do doby, dokud si spouštěč (třeba omylem) nezavřete. Pokud se problém již projevil, nespustíte znovu ani tento spouštěč. Další nevýhoda je ta, že i pokud spouštěč spuštěný máte, ale problém se již projevil, nelze otevírat dokumenty kliknutím ve správci souborů (např. Krusaderu), ale je třeba jít přes menu programu (Soubor - Otevřít...).

Programy mimo kancelářský balík ovšem takto spouštět nelze (Base, Draw). Tento problém se nejspíš netýká Libre CADu, ten zatím fungoval vždy.

V hloubi systému jsem se zatím nevrtal, protože popravdě vůbec netuším, čím by to mohlo být a kde začít. Občas, v průběhu dne náhodně, vyskočí na ploše okno s hláškou "nelze otevřít databázi rpmdb" (systém samotný, děje se to i když není používán žádný program, jen spuštěný systém), může to mít souvislost? Děje se to ještě někomu?

[lertimir]

No a co my s takovým popisem chyby. I diagnostika by bylo jen věštění z křištálové koule. Zjistit, co za příkaz se při "zaklikání" spustí. A ten zopakovat z přikazové řádky. U mne je to libreoffice %U a případně s specifikací podmodulu. Nasledně poslat přesné chyby, které nastanou. Ostatně jednak je Draw a Base vnitřní součástí LO (volání libreoffice --base) jedank samotný libreoffice je script, který fakticky spouští soffice.bin, ale také, když se do uživatel podívá, umí spustit strace, je-li třeba hledat pády.

[Brad]

Chápu že to nejsou úplně konkrétní informace, nicméně jedná se o počítač v zaměstnání a nedostanu se k jeho diagnostikování kdy si vzpomenu (resp. zatím nebyla příležitost), tak jsem doplnil co jsem zatím věděl, než to zapomenu.

Navíc si myslím, že to nejsou tak úplně nezajímavé informace, někdy i malá indicie může při následném řešení problému hodně pomoci, ale samozřejmě máte pravdu v tom, že bez konkrétních se nikam výrazně nepohneme. I na ně dojde, jen nevím přesně kdy (doufám, že co nejdříve), pak je samozřejmě urychleně doplním taktéž.

Překvapuje mě, že se to děje na obou architekturách. Nejsem si jist, jestli Base a Draw jsou součástí stejného balíku, protože když jsem distribuční verzi odinstaloval a nainstaloval novější stáhnutou, tak Base a Draw se neodinstalovaly a zůstaly ve starých verzích (a CAD, ten ale potíže nedělá) a není mi ani jasné, kam přesně „se pro ně chodí”, protože ani ve staženém novějším balíku jsem je v té hromadě RPM nikde neviděl (ale třeba jsem jen slepej, ovšem i po instalaci zůstaly Base a Draw staré, a žádné konflikty mi urpmi nehlásil).

Jak jsem již psal, výstupy doplním hned jak budu moci, zatím děkuji za tip na provedení a za trpělivost

[pavele]

Nemůžeš nechat kus programu starého a kus nového.

Doporučuji:

1. Odinstalovat kompletně LibreOffice.

2. Smazat konfigurační adresář uživatele (/home/ty/.config/libreoffice)

3. Nainstalovat LibreOffice

4. Pokud vím, Mandriva měla grafické klikátko k připojení sdílených adresářů ze sítě v MCC.

5. Doporučoval bych instalaci Samby (samba-server a samba-client) a její nastavení do tvé pracovní skupiny (v /etc/samba/smb.conf je řádek "workgroup = tvoje_pracovni_skupina). Nemusí běžet, ale některé programy z ní berou tu pracovní skupinu/doménu.

6. Firewall by měl mít minimálně povolené porty 137, 138, 139, 445.

[Brad]

Řešme prosím pouze ten kancelářský balík, se Sambou to nijak nesouvisí, to už je zjištěno.

1. Ujišťuji Vás, že jsem odinstaloval kompletně celý balík, tak jak má nastaveny závislosti. Já se teď nepodívám jaké verze má která aplikace z balíku, přeinstalovaný počítač je v zaměstnání a doma to přeinstalovávat nebudu, tam zůstává distribuční verze, ale právě teď jsem zjistil, že LibreCAD vůbec nepochází od LibreOffice konsorcia, jen se tak matoucně jmenuje.

2. hrátky s tímto adresářem již proběhly, vizte výše, bez úspěchu - na věc nemají vliv.

3. stalo se.

4. neřešme, nesouvisí.

5. Samba client je, Samba server není a nebude, v síti už jeden je a nedělalo by to dobrotu (kvůli uživatelům, ne kvůli systémům, oni jsou tam někteří vyplesklí i z toho, když někdo do sítě zapojí notebook); pracovní skupina je správná, to jsem měnil hned - nicméně nesouvisí.

6. Proč? Kvůli Sambě? nesouvisí (!), stejná věc se děje i přes NFS, přímo z lokálního disku přes Krusader i např. z CD nebo flash.

[pavele]

1. Byl odinstalován kompletně celý balík, tak jak má nastaveny závislosti, nebo skutečně kompletně celý balík LibreOffice?

Například já když odinstalovávám předchozí verzi, musím některé balíčky "vyzobat" - přímo najít a označit z mé grafické nadstavby na správu balíčků/software.

5. Napsal jsem, že Samba-server nemusí běžet.

Pochopil jsem to správně, že problémy vznikly až po Vaší instalaci nové verze LibreOffice do PC?

Pokud se jedná o firemní počítač, bylo by spíše vhodné kontaktovat Vašeho správce sítě/IT a přednést Vaše problémy jemu.

Popravdě, divím se firemnímu použití distribuce Mageia.

[Brad]

Pochopil jsem to správně, že problémy vznikly až po Vaší instalaci nové verze LibreOffice do PC?

Ne, problémy jsou už s distribuční verzí LO balíku, resp. vypadá to, že to možná bude problém přímo linuxové distribuce, nikoliv kancelářského balíku, jen se to zrovna na něm bohužel projevuje.

Pokud se jedná o firemní počítač, bylo by spíše vhodné kontaktovat Vašeho správce sítě/IT a přednést Vaše problémy jemu.

Bohužel tam víceméně zastupuji roli správce sítě já, ten kdo tam je v této pozici oficiálně ani nedokázal (nebo nechtěl) správně nastavit na serveru sdílení NFS, musel jsem si to udělat sám.

Mageiu jsem použil proto, že je následovníkem Mandrivy, kterou jsem celkem dobře znal a celkem dobře fungovala (a navíc ten klikací správce je velká výhoda, funguje jak má, to v Mandrivě udělali celkem dobře, je propracovaný hodně do hloubky a nechá se v něm nastavit kdeco poměrně do detailů). Z Mageii popravdě taky moc nadšený nejsem, už od trojky se to chová chvílema prazvláštně, ale je pořád nejpodobnější tomu, s čím mám zkušenosti, v práci není čas učit se novou distribuci, a ani nevím na jakou bych měl případně obměnit (RPM/KDE a dobrá funkčnost už ze startu jsou podmínky; na žádné "sudo" by default nejsem zvědavý).

[pavele]

Na fóru mageia jsem našel uživatele se stejným problémem, nakonec to řešil odinstalací LibreOffice, stáhnutím a instalací OpenOffice.

Dále, podle jiných zdrojů by to mohlo souviset s nenainstalovanou Javou nebo nainstalovat místo openjdk Javu od Oracle:

https://wiki.mageia.org/en/Install_java_oracle

Dále jinému uživateli se to spustilo po nainstalování "libpng".

Podle Errata Mageia 5 a podle některých uživatelů se LibreOffice spustil po odinstalování balíčku libreoffice-kde.

Dále mám z historických verzí OpenOffice v /etc/hosts přidaný řádek:

#Melo by zrychlit start OpenOffice
127.0.0.1      localhost.(none)

Předpokládám, že SELINUX nepoužíváš a v MCC máš zabezpečení nastavené dobře.

Jinak Osobně jsem používal Mandrake/Mandrivu přes 1O let. Grafické rozhraní je pěkné, ale nebylo vždy funkční, takže jsem stejně nakonec nastavoval vše ručně.

Doporučuji doma si zkusit instalaci Debianu nebo CentOS. Změna není zas tak velká a odměnou bude, že najdeš stabilnější prostředí, něco nového se naučíš a najdeš zde více odpovědí na chyby v těchto distrech.

[pavele]

Jo, a v tom gdb.log:

chyba: cannot open Packages index using db5 - Operace zamítnuta (13)

Měl bys zkusit rebuild rpm databáze - jako root v terminálu:

mkdir /root/backup-var-lib-rpm
cp -avx /var/lib/rpm /root/backup-var-lib-rpm/
rm -f /var/lib/rpm/__db*
rpm -vv --rebuilddb

[00000]

Náhrada OpenJDK Javy za origoš Javu skutečně zabrala, navíc jsou teď programy z balíku znatelně živější co se týče reakce na události i samotného spouštění.

[lertimir]

Klikací RPM distribuce s propracovaným přizpůsobením KDE je jednoznačně openSUSE. Jednak se tomu věnuje více lidí, KDE je dlouho dobu primární volba při instalaci. Ve správci yast se nakliká v podstatě vše, co je třeba. a jen tak mimochodem žádnou javu v závislostech libreoffice nemá.

[Brad]

Se SUSE linuxem jsem shodou okolností začínal, tehdy verze 7, dnes bych se k němu ovšem nevracel - nebudu přeci utíkat od M$ zpět k M$, ta společnost u mě, po všech těch věcech co lidem provedla a provádí, nemá důvěry už ani kousíček.

Už jednomu kolegovi jsem tu psal, cituji

vypadá to, že to možná bude problém přímo linuxové distribuce, nikoliv kancelářského balíku, jen se to zrovna na něm bohužel projevuje

Že LO nemá v závislostech Javu je dost dobře možné, nic to ovšem nemění na tom, že problém s tímto postupem zmizel (tedy nerad bych to zakřiknul jak už se mi tu jednou povedlo, ale dnes jsem s tím balíkem pracoval celý den bez sebemenšího zaškobrtnutí, rozdíl byl jasně patrný, předtím to tak hladké a bez zádrhelů rozhodně nebylo). Beru to jako kompliment dobrému pozorovateli, děkuji

[lertimir]

No já jsem to nikdy nebral jako otázku linux x MS jako souboj my x oni. To že licenční politika MS mi vadí natolik, že je používám jedině když v práci musím je v podstatě moje věc. Ale to, že se nějaké linuxové distro s MS domluví hlavně na tom aby SLED bylo možné provozovat v MS virtuálním prostředí je zcela jiný segment než, co mne mne zajímá. Podstatné je, že openSUSE je linuxové distro s dostupným zdrojákem a také že do komunity rozumně přispívá pohybuje se stabilně v první 5 firem s RH, Intelem, IBM příspěvků do jádra. V tom linuxovém světe mne mnohem více připadá kontroverzní Canonical než SUSE. V jistém směru Oracle mne svou licenční politikou a přístupem štve podobně a pokud bych měl mít jeho JAVU tak odkliknu EULU s niž nesouhlasím.

Ale nechci z toho udělat zase flame. Respektuji výhrady. A obávám se že jiné RPM distro, které se hodně stará o KDE není.

[Brad]

V pohodě, taky respektuji, flame nevyhledávám.

Co se týče distribucí, tak nějak jsem přemýšlel nad Fedorou (jsem si vědom toho, že je to testovací distro), nebo, jak tu již někdo radil, CentOSem. Pokud by to nebylo lepší, možná bych se, za podmínek které jste mi o nich sdělil, pouvažoval i nad SUSE, nicméně - jak jsou na tom s ovladači? Pokud vím, někteří výrobci HW pro Linux neuvolňují zdrojáky, ale pouze binární bloby, není to v tomto případě trochu překážka?

[lertimir]

openSUSE v základu je poměrně puristické open distro. To znamená žádné proprietální kodeky, žádné proprietální grafické bloby. vše je samozřejmě dostupné z dalších komunitních repozitářů, které si uživatel musí připojit. To že výrobce neuvolní zdrojáky ovlivňuje všechna distra stejně. Protože nepotřebuji grafické bloby tak jsem s hw už mnoho let neměl problémy.

[Brad]

Aha, tak jsme doma, už víme proč to M$ dělá - data ze směrovačů ho zajímají. Rád bych se pletl, ale tak nějak jsem tušil, že to nedělá jen pro srandu králíkům nebo lásku komunity.

http://www.root.cz/clanky/microsoft-vyviji-linuxovy-system-pro-sitove-prvky/#utm_source=rss&utm_medium=text&utm_campaign=rss

Váš komentář respektuji, jen tím chci říct, že ten odkaz staví snažení oné společnosti do poněkud jiného světla (mohou dělat i dobré věci, ale když je úmysl zlý... však víte).

[lertimir]

Tedy nevím které společnosti, jestli SUSE nebo MS. Ale na to přece nepotřebuje SUSE ani nikoho jiného. Kód linuxu je volně k dispozici a MS jistě má dost schopných programátorů, aby si ho ohnul sám. Rozhodně mnohem více než SUSE. A to také dělá. MS přiznal že jeho Azure Cloud Switch jede na linuxu.

To o čem se SUSE dohodlo s MS je funkcionalita jeho serveru v Azure. Samozřejmě že se dá rozjet i jiný linuxový server, ale není to certifikované. Proč tolik firem má RHEL a platí stovky tisíc ročně, když by stejně mohli mít CentOS. Protože když by nastal jakýkoliv problém, tak technici Oracle, nebo SASu nebo jakékoliv jiné komerční aplikace od toho dají ruce pryč. Jedete na nepodporovaném OS, vyřešte si to sami.

A data ze směrovačů v podstatě je těžké stabilně sbírat. Jeden MTU Ethernet paket je 12000 bitů. Gigabitový router tedy routuje cca 80000 MTU paketů, pokud k němu zaznamenáme IP hlavičku plus 64bitu IP datagramu jak je např v CRC součtu je to 28 bytů a to je 2MB/s datového toku z každého jednotlivého routeru. obvykle více, díky tomu že mnoho paketů je malých. Navíc veškerý monitoring funkci router zpomalí. Většina Cisco mašinek to má, ale je to v provozu velmi velmi výjmečně a na lokální bázi. Na to aby to nebylo poznat by musel být HW výkonnější. (a kdyby šlo o to tenhle zámer mít a utajit ho, tak proč by to dělal na linuxu.)

[Brad]

Přílohy:

• gdb.log (112704 bytů)
• strace.log.bz2 (279504 bytů)

Právě se mi to stalo i doma na i586 Mga5, tak přikládám... dělal jsem to podle návodu zde, tak snad to k něčemu bude (přiznám, že pořádně nevím, co jsem právě udělal)

[Brad]

Nevím, jestli to ještě někomu pomůže, ale vzhledem k tomu, že distribuce Mageia přešla na KDE Plasma a už 4 vydání se moc nedaří tomu vychytat všechny mouchy, takže spousta lidí zůstala u MGA5, tak budu věřit, že by to někomu pomoci mohlo…

Libre Office začalo korektně fungovat a spouštět se vždy po tom, co byl doinstalován CUPS server a tiskárna HP LJ1100.