Dotaz: monitoring startu KDE

[lertimir]

Po několika letech se mi rozbil start KDE prostředí. (asi díky mé nedočkavosti.) A teď řeším jak to opravit a nepřijít o spousty konfigurací v KDE. Mám nasledující systém. OpenSUSE 13.1, dual monitor na DisplayPort a DVI. Několik účtů A (hlavní), B (vedlejší) a C (testovací). Hlavní se zmrvil, nebyl funkční pro dualmon a při startu zatuhnul. Vedlejší byl celou dobu v pořádku, ale v krandrrd měl nesmyslný druhý monitor na rozhraní na kterém není připojen. Testovací nebyl funkční pro dualmon ani pro nově vytvořený účet. Už jsem prošel několik etap, kdy jsem zprovoznil dual monitor, ale fakticky nevím moc jak protože měly jet i předchozí konfigurace, ale nejely. Teď je asi poslední etapa v rekonstrukci stavu. Účet je funkční, dual mon také, ale při startu KDE, jak najíždí postupně sada ikonek popisujících start KDE, tak všechny ikonky najedou rychle, ale pak se start zastaví a systém "čeká", po minutě až dvou se start dokončí. Vzhledem k tomu že standardní start je do 5s, tak potřebuji zjistit na, co čeká a co se děje. Současně pořád funguje přepínání session takže ze zatuhlé ho startu session pro účet A se okamžitě přepnu do účtu B, je to tedy čistě lokální záležitost účtu.

To co zatím o problému vím:

1. Hodně závisí na souboru ~/.kde4/share/config/plasma-desktop-appletsrc. Ale nějak divně. Celý adresář config vzatý z backupu z doby, kdy desktop fungoval vytváří stejnou chybu, zatuhnutí. Nově vytvořený konfigurák p-d-as problém nedělá.
2. V lokálním .xsession-errors-:0 se objevilo

   plasmapackage:/ui/NotificationDelegate/NotificationDelegate.qml:209:21: QML TextEdit: Possible anchor loop detected on fill.
   plasmapackage:/ui/NotificationDelegate/NotificationDelegate.qml:163:13: QML Item: Binding loop detected for property "height"
   plasmapackage:/ui/NotificationDelegate/NotificationDelegate.qml:163:13: QML Item: Binding loop detected for property "height"
   plasmapackage:/ui/NotificationDelegate/NotificationDelegate.qml:163:13: QML Item: Binding loop detected for property "height"
   file:///usr/lib64/kde4/imports/org/kde/plasma/components/TabBar.qml:150:5: QML Item: Possible anchor loop detected on fill.
   file:///usr/lib64/kde4/imports/org/kde/plasma/components/TabBar.qml:150:5: QML Item: Possible anchor loop detected on fill.
   file:///usr/share/kde4/apps/plasma/plasmoids/org.kde.notifications/contents/ui/main.qml:139:9: QML Flickable: Possible anchor loop detected on fill.
   file:///usr/share/kde4/apps/plasma/plasmoids/org.kde.notifications/contents/ui/main.qml:139:9: QML Flickable: Possible anchor loop detected on fill.
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   Error while running query  "SELECT filename FROM cache WHERE package = ?" 
   

   Ale netuším v jakém čase se to tam zapsalo. Ani co se hledá v dá databázi? Je .xsession-errors log pouze pro jednu session? Když pustím login s třeba pak s nově vygenerovaným config přepíše se? V logách Xorg a kdm nic, pochopitelně.

Odpovědi

[Pavel 'TIGER' Růžička]

Nejsem uživatelem KDE, ale nestará se o spouštění kwin? Nemělo by se tedy hledat v logu kwinu?

[lertimir]

kwin to skutečně spouští, ale žádný kwin.log nikde není.

[Pavel 'TIGER' Růžička]

No a jaké má parametry kwin, nejde nějak to logování zapnout?

[fricek]

Další, který nepochopil, že systemd se sere úplně do všeho a je téměř neovladatelný. Mimochodem, logy systemd v textovém editoru nepřečtete.

[Pavel 'TIGER' Růžička]

Další, kdo nepochopil, že to se systemd nemá nic společného. Mimochodem, když se vám systemd nelíbí, nepoužívejte ho. Naštěstí jsou i alternativy.

Pavel 'TIGER' Růžička napsal: Mimochodem, když se vám systemd nelíbí, nepoužívejte ho. Naštěstí jsou i alternativy.

To mohl napsat jen úplný začátečník: Asi neví, že do dvou let budou mít systemd prakticky všechny distribuce.

Alternativa je v podstatě jen jedna a není to nic moc: BSD.

Takže, když tu bude začátečník Pavel 'TIGER' Růžička psát blbosti, neberte ho vážně. Naštěstí jsou tu i zkušenější linuxáci.

[Pavel 'TIGER' Růžička]

Pouhý trolling, nic víc.

[Pavel 'TIGER' Růžička]

OT:

Asi máte křišťálovou kouly, ale do dvou let nebudou mít všechny distribuce systemd. No a napsat, že BSD je nic moc, tak to je také velmi slušný úlet a poukazuje na neznalosti v této oblasti. Možná byste si měl něco přečíst, doporučuji však začít Linuxem.

Konec OT

Tak a nakrmil jsem trolla. :)

[ivdo]

Tak to jste nám opravdu odborně poradil alternativu Linuxu bez systemd.

[Pavel 'TIGER' Růžička]

Účelem tohoto vlákna není poradit distribuci bez systemd, to se řeší ve vedlejším vlákně, stačí do něj nakouknout.

[2X4B-523P]

není třeba něco v .kde/Autostart(.kde4/Autostart; .config/autostart)?

[lertimir]

.kde4/Autostart a .kde4/share/autostart jsou prázdné.

[pavel]

A nemáš tam náhodou systemd ?? Ten se totiž přesně takhle chová (alespoň jeho relativně nové verze). A nedá se s tím v podstatě nic dělat. Systemd je hrozné svinstvo.

[lertimir]

To je blbost. systemd nemá co dělat s rozdílem mezi nájezdem uživatelského prostředí mezi účtem A a účtem B.

[2X4B-523P]

pokud systemd běží, tak by možná šlo použít systemd-analyze a jinak i bootchart by mohl napovědět co zdržuje při přihlášení, ale v obou případech by se na test asi muselo povolit automatické přihlášení...

[lertimir]

bohužel, oba dva nástroje jsou pro ladění bootu, tedy pro init 5 je konečná nastartování X serveru. bootchat jsem používal už dříve, a vždy končil startem kdm/gdm display manageru. systemd-analyze dává

graphical.target @6.041s
└─multi-user.target @6.041s
  └─cron.service @6.041s
    └─postfix.service @5.542s +498ms
      └─time-sync.target @5.536s
        └─ntp.service @5.389s +146ms
          └─remote-fs.target @5.388s
            └─remote-fs-pre.target @5.388s                                                                                        
              └─nfs.service @5.180s +207ms                                                                                        
                └─network.target @5.179s                                                                                          
                  └─NetworkManager.service @4.925s +253ms                                                                         
                    └─SuSEfirewall2_init.service @4.686s +238ms                                                                   
                      └─basic.target @4.654s
                        └─sockets.target @4.652s
                          └─dbus.socket @4.652s
                            └─sysinit.target @4.645s
                              └─apparmor.service @4.359s +285ms
                                └─systemd-tmpfiles-setup.service @4.345s +13ms
                                  └─local-fs.target @4.340s
                                    └─var-lib-nfs-rpc_pipefs.mount @5.293s
                                      └─local-fs-pre.target @1.775s
                                        └─systemd-remount-fs.service @234ms +1.540s
                                          └─systemd-readahead-replay.service @112ms +113ms
     

takže najetí grafického prostředí je poslední záznam. (je to sice jiný komp bootující správně s dočasně vypnutým loginem, ale žádné další rozlišení po najezdu grafiky není. mimo jiné součástí startu účtu je i najetí firefoxu asi s 6 okny a cca 70 panely což trvá mnohem déle než uváděných 6 sec do najetí systému) Procesy uvnitř Xek už nejsou monitorovány systemd, ani na ně nedosáhl bootchart.

[2X4B-523P]

možná když to tam trvá tak dlouho, dalo by se stihnout podívat se do htop, nicméně mi to včera nedalo a ve snaze vyzkoušet systemd jsem si trochu zmrzačil systém, nedaří se mi tam nainstalovat nic z 32-bit části multiarchu, zrovna také nebyl k dispozici balík xserveru s kompatibilním ABI atd. občas je Debian unstable opravdu unstable, ale hlavně že funguju, na Linixu je super, že se nedá snadno položit

asi jsem to měl dotáhnout, jistě mne to čeká znova, ale snad to bude ve stabilním období nestabilní distribuce... jinak jsem toho hodně načetl a skoro všude jinde než na abclinuxu jsou k systemd kladné ohlasy, dokonce na poli operačních systémů jsou linuxové distribuce ostudy, jsou totiž téměř jediné, které nenabízí rychlý binární init systém... jinak čtení logů systemd, no, nevím kdy jsem se koukal do logu sysV, ale když byl problém se službou, hledal jsem ho v logu služby, nikoli initu...

[lertimir]

Zatěží to není. htop mne napadl také, ale zátež je na praktické 0 (cca 3% na všech 4 jádrech). Myslím si, že problém je ten, že start něco chce, nedostane to, a celé prostředí čeká na timeout, až ten pokus vzdá. Jenže nevím co. Domnívám se, že to může být nějaký plazmový applet. Mám jich několik, ale v mnohých je i historie, proto nechci přímo odstřelit celou konfiguraci KDE. V grafickém prostředí jako přímých X kách to také není. Mohu mít rozjeté současně session F7 (správnou) a F8 (tuhnoucí) a jsem schopen přepínat mezi 7 a 8 a když skočím na 8 je to v tom zatuhlém stavu tedy najeté všechny ikonky v rámečku popisující start KDE, ale nic více a když skočím na F7 tak je to normální funkční session. Přeskok je okamžitý, stejně tak jako přeskok do terminálu F1, F2 atd. Prostředí nakonec najede, ale v čase minuty, takže totální problém to není. Taky bych podle tohoto rád pochopil jak KDE a plazma startuje. A možná by porozumění startu mohlo zajímat (a pomoci) i někoho jiného.

[2X4B-523P]

pokud je tam plasmoid network-manager, tak ten by to mohl dělat, jestli je tam nějaká konfigurace VPN, nebo nějaká statická, ono se to asi snaží zobrazit plochu až když je to na síti... myslím že by mohlo mít vliv i nastavení ntp serveru pro hodiny...

[lertimir]

je tam plazmoid monitoring sítě. Network manager ne, systém má statickou konfiguraci IP bez DHCP. ntpd najíždí v části init 3 před nájezdem grafického prostředí. (a pravda že v době když jsem dostával adresu z DHCP a nekdy měla zpoždění tak ntp se zlobilo a tuhlo.)

[2X4B-523P]

neměl jsem na mysli klasického ntp klienta, ale toho, co má ten plasmoid přímo v sobě, můžou se jednak prát a jednak může být špatně nastavena adresa ntp serveru, takže KDE čeká, než to plasmoid vzdá a použije systémový čas, který je nastaven standardním klientem... že by plasmoid používal ntpd a muselo by se to explicitně zapínat, by bylo divné, ale blíž jsem plasmoid nezkoumal...

[petr_p]

Nechci vám kazit radost, ale systemd se nyní stará o vytváření uživatelských relací, nastavuje PTY, přístupová práva, přiřazuje kontrolní skupiny. S příchodem Waylandu a bezrootového Xorgu bude řešit i vstupní zařízení. Je to jeden z důvodů, proč Gnome3 je oficiálně podporováno jen se systemd. Například GDM3 už bez systemd nefunguje vůbec.

[Peter Golis]

Uvedené vlastnosti mi pripadajú užitočnejšie ako napríklad pridávanie užívateľa do kadejakých pofidérnych skupín ako napríklad audio (ak chce využívať zvukovku), cdrom a podobne.

[rADOn]

Pusť si holý xterm nebo nějaký malý dm (twm by měl být všude) a spusť "startkde", pak terminálu uvidíš celý log. Jinak mě takovyhle problémy vždycky dělaly bugnutý plasmidy stažený z netu.

[rADOn]

BTW ten select tam padá z packagekitu, asi jsi mu nějak rozbil databázi.

[Milan Uhrák]

No, možná je to brutální postup, ale smazal bych z konzole (ještě před přihlášním) session, nastavení plasmy a databáze akonadi nebo jak se ten shit jmenuje a pak se zkusil přihlásit, jak se chová přihlašování

~/.kde4/share/config/plasma-desktop-appletsrc
~/.local/share/akonadi/* (asi přijdeš o "hodnocení" souborů, komentáře a hlavně : nastavení pošty a kalendáře KdePIM (kmail, kontakt ..)!! ). 
~/.kde4/share/config/akonadi_*
~/.kde4/share/config/ksmserverrc

[2X4B-523P]

je to brutální postup, který může aktivovat akonadi i nepomuk, lepší je ji celou přejmenovat a zkusit se přihlásit... když to bude trvat i potom, tak to bude znamenat, že je někde uživatelský skript, který se zpracuje při každém přihlášení a může být klidně v ~/.config/autostart/, to co je tam se zpracuje vždy a co je v ~/.kde4/Autostart se zpracuje jen při přihlášení do KDE...

[lertimir]

No to je vážně brutální postup. Už v dotazu jsem psal, že mi stačí vyměnit ~/.kde4/share/config/plasma-desktop-appletsrc za takový, který se nově vygeneruje, a start je rychlý. Jádro dotazu není, jak opravit instalaci smazáním, ale jak odmonitorovat, co se a v jakých posloupnostech děje. No v hodnocení souborů mám atagovaných asi 8000 souborů takže tohle smáznutí je také nemožné.

[xxx]

+ 1

[2X4B-523P]

ještě jsem si vzpomněl, že to může udělat v Kmenu odkaz, nebo odkaz na symlink, který vede na odpojenou jednotku, nebo odpojenou síťovou jednotku, jednou jsem si dělal zkratku na skript a když byl ten druhý stroj odpojen, tak mi to také zdržovalo přihlášení, ale teď jsem to nezkoušel, ale zkusil jsem ~/.config/autostart/ a skript mi to při přihlášení do KDE nespustilo, přitom mám pocit, že mi to kdysi šlo, tak tam to určitě nebude... podíval bych se tedy jestli v Kmenu, nebo možná na liště není nefunkční odkaz... jestli by to dělal i folderview nevím, když mi po přechodu na KDE4 zmizely ikony z plochy, zajásal jsem a od těch dob na ploše nic nemám...