[Megoldva] Fájlmegnyitás, elmentés idle...

Ubuntu Linux

Sziasztok!

Pár napja kezdődött, hogy bizonyos alkalmazások használatával (Pl. Telegram, GIMP, LibreOffice...) KDE alatt a fájlműveletek akár egy perces időt is igénybe vesznek. Se a strace, se a XYtop-ok nem mutatják, mi történik. Először a dolphinra/KDE-re gyanakodtam, ezért feltettem egy Cinnamon környezetet, de ott is jelentkezik, vagyis inkább hajlok arra, hogy valami ismeretlen Ubuntu probléma lesz.

Esetleg van tippetek, mi lehet ennek a jelenségnek a hátterében?

Előre is köszi a válaszokat.

Szerk.: A megoldás workaround abban állt, hogy a ~/.config/ foldert átneveztem (a backupolhatóság miatt). Fogalmam sincs, melyik konfig volt a ludas, mert több ablakkezelőt is szívatott, de nem is keresem meg, mert nincs rá időm. Köszönöm mindenkinek, aki segített.

Szerk. 2: A megoldás pedig itt lentebb.

  • 376 megtekintés

( Raynes v | 2022. 10. 28., p – 18:31 )

SSD tud így megdögleni, hogy még látszólag megy, de néha ilyen rövidebb fagyásokat, nagy lagokat produkál. A SMART adatokra nézzél rá, smartctl-lel, ha NVMe SSD-ről van szó, akkor az „nvme” paranccsal.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( vfero v | 2022. 10. 29., szo – 01:28 )

Én a magyar fejlesztésű hdsentinel-t javaslom, a kimenetét sokkal egyszerűbb értelmezni, mind a beépített tool-okét - szerintem. ;) A Linux verziója szabad! (Köszi, János +1x ezúton is!)

vfero

( pepo v | 2022. 10. 29., szo – 07:35 )

Köszönöm a válaszokat, megnézem mindegyiket, válaszolok, ha van eredmény.

READY.
󠀠󠀠‎‏‏‎▓

( pepo v | 2022. 10. 29., szo – 08:35 )

Az a helyzet, hogy mindkét program szerint rendben van... 

Ugyanakkor észrevettem egy érdekes jelenséget: ez a hiba csak az egyik - leginkább használt - felhasználóval esik meg. Minden más userrel rendben van. Egyre érdekesebb... 

READY.
󠀠󠀠‎‏‏‎▓

( Raynes v | 2022. 10. 30., v – 03:11 )

Azért én megnéztem volna, hogy melyik konfig volt a ludas a ~/.config/-ban. Mert így nem tudod, és nem tanul senki az esetből. Az .Xauthority fájlra gyanakodnék, ha több ablakkezelőt is érintett, de a nem a ~/.config/-ban van, hanem a ~/-ban. Mindenesetre ilyennel még nem találkoztam.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Szia!

Azt a csibészt ismerem, már dagadt meg nálam is párszor, így azt korábban ellenőriztem.

Na, de azért tényleg nem hagyott a dolog nyugodni. Visszatettem az átnevezett .config mappát és teszteltem egyet.
A Telegramot választottam az egyszerű teszthez: ha fájlt nyitottam meg, vagy akartam elmenteni, azonnal megnőtt az idle.
Mivel a .config részese valami a path-nak, amin elhasal a fájlművelet - mert hát annak az átnevezése workaroundolt -, így úgy döntöttem, specializáltan greppelek a config szóra, miközben Telegrammal fájlműveletet végzek:

strace ~/Telegram/Telegram 2>&1 | grep config

Meg is lett azonnal az elcseszett fájl, a  ~/.config/QtProject.conf fájl. 786 megára hízott. 
Eléggé terjedelmes maga a .config, vagy 20 éve gyűlik, így a fenének sem volt kedve átnyálazni korábban. Őszintén szólva nem gondoltam, hogy a ~/.config-ban is hízhat meg valami ilyen ökör módjára, így valami elkonfigurálásra gyanakodtam.

Egyébként a QtProject.conf belül egy shortcut jelölése csesződött el, így lett benne egy 786 mega nagyságú "fájl név". :-)

Még egyszer köszi mindenkinek.
 

READY.
󠀠󠀠‎‏‏‎▓

Nem, neked kösz, hogy megnézted mi volt a tényleges probléma. Így okulunk belőle mi is. Gyorsan megnéztem nálam mekkora a ~/.config/QtProject.conf és kiderült, hogy csak 561 bájt, nem kiló, nem mega, csak simán bájt. Az is igaz, hogy csak egy Qt-s appnak van benne a cucca, a Goldendict-nek, mert ez az egyetlen Qt-s app, amit használok, igazából meg a használat is kérdőjeles, tesztelni van csak fent, mert igazából a saját stardict-cli megoldásom és szótáraim használom helyette, de azokban vannak még bugok (főleg indexelés és Unicode-megjelenítés), amit tudok debugolni, mert egy másik programmal is ki tudom próbálni. A Goldendict saját maga indexeli a szótárakat, meg a Unicode sem probléma neki, így jó tesztelési pont.

Egyáltalán nem lep meg, hogy egy Qt-s összetevő volt a ludas, azok általában mind nem csak bloatok, de bugosak is szoktak lenni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

969 byte nalam. Nem szokott lenni problemam a Qt-val, pedig Ubuntun nem foglalkoznak vele sokat. Egyebkent KDE meg Win10 alatt is hasznalok PyQt5-os programot, de azzal sincs bajom, pedig en irtam :).

A strange game. The only winning move is not to play. How about a nice game of chess?

Érdekes mód, Windows alatt nekem sem volt még problémám egy Qt-s cuccal sem. Linux alatt KDE-vel viszont volt, állandóan nyomják bele a feature-öket, ami ugyan jó, de cserébe a meglévőknek a bugjával nem nagyon foglalkoznak, nem javítják, csak az újdonságokkal együtt kerülnek be azoknak a bugjai is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”