How do you handle high utimes with patches coming in, replacing libraries and gui parts - odd highlevel application behaviors
Hi there all hello list dwellers, i am not very fluent on the gui side of opensuse. When using current opensuse 15.2 systems but also in the years before, every now and then some test machine, simple standard kde gui level opensuse installation, no fancy setups. having such a machine on and up a long time, a kde user logged in, the screen locked, e.g. simple kde desktop gui application itself (dunno whats it even called or concepts for sure, think: this plasma desktop and whatever), eventually this kind of a system become erratic on its gui side of things. revisiting such a machinery, unlocking the desktop shows mess e.g. in a left open firefox gui, tabs becoming unklickable unchangeable, for example mething i remember a situation (dont really take my word for this everything as 100% but you get the idea, roughly ballpark, anyways continue the story) that i could still surf and use that one tab of that fricken firefox, but pretty much everything of it in the sense of frames, borders, resizing, moving around or its menues and elements that (my understanding of it, over the somewhat lengthy experience i myself had in the unix world, all about window managers, gui layers of the linux universe and such stuff) are triggering the operating system layers and libraries.... so these libariers might get exchanged and replaced by up- and in-coming opensuse patches, they get applied so far so fine. I always admired the unix world for being kind of able to overwrite and replace of nearly almost everything in its way in some still working healthy stable ways. in stark contrast to the windows world. so anyhow, these recent years i work myself the gui parts of linux a bit, and i kind of see (or guess) the downsize of all this. so these high level applications such as the desktop plasma application itself and the firefoxen for example, become erratic, only parts of them staying up working, the rest refusing their parts of work. during such times, only a restart of a mal functioning firefox helped, or even a restart of the display.service via systemctl, or even a reboot of a whole machine if that hadnt helped. i figured that it was some very deep down libraries or when kernel updates itself become applied, i think kernel packages also bring in files where some select externalized drivers reside and so on. So simple question is, how do other gui opensuse users live with this. How do you have a nice and incomplicated life where your desktop machine just continues to work. Recently whenever resorting to opensuse, I sometimes think, I reboot the opensuse at a higher frequency than some average windows machine (just kidding, no seriously, you like reboot windows at least once a month when the nightmare microsoft update day finally has arrived or you forced or lulled yourself into allowing yourself to go down that path). Anyone experience same erratics every now and then with high long uptime opensuse machines with gui usage? Is this a know behavior of opensuse, or am I doing it wrong? If the stuff is normal, can one resort to some replace-in-use-files in a different manner, that might avoid such behavior of the high level apps? After reboots and restarts of the various possible layers of the opensuse system, stuff comes back working normally. I observe this type of incidents with the gui opensuse machine, when I forget coming back to it for a number of weeks. Mostly I am still able to work around the little mess with it, sometimes I end up needing to reboot the machine in the end after all. Thanks for your insights on this matter on how you lead a long uptime and happy life with your gui opensuse system. TY.
Hi, Am 10.03.21 um 15:58 schrieb cagsm:
Hi there all hello list dwellers,
i am not very fluent on the gui side of opensuse. When using current ..... ..... .....
Thanks for your insights on this matter on how you lead a long uptime and happy life with your gui opensuse system. TY.
it would be helpful if you provide some info's: what opensuse version? what graphic card, what graphic driver. . . . . "normaly" the opensuse desktop (kde) works for me without problems. since years simoN -- www.becherer.de
W dniu 10.03.2021 o 15:58, cagsm pisze:
So simple question is, how do other gui opensuse users live with this. How do you have a nice and incomplicated life where your desktop machine just continues to work.
I gave up on this long ago. An application is an executable binary and other files. If you install an update, while it's running, you get an old binary still sitting in memory but with other files replaced with newer ones. If they are incompatible it has to go nuts. I used to play with running `zypper ps` to see which programs needs restarting after installing updates. But for example restarting dbus makes whole system deeply broken. I use Tumbleweed and usually once a week I logout from graphical session, go to text console, run zypper dup and then reboot. It's the only safe way. Some interesting links: https://lwn.net/Articles/702629/ https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
* Adam Mizerski <adam@mizerski.pl> [03-10-21 14:18]:
W dniu 10.03.2021 o 15:58, cagsm pisze:
So simple question is, how do other gui opensuse users live with this. How do you have a nice and incomplicated life where your desktop machine just continues to work.
I gave up on this long ago.
An application is an executable binary and other files. If you install an update, while it's running, you get an old binary still sitting in memory but with other files replaced with newer ones. If they are incompatible it has to go nuts.
I used to play with running `zypper ps` to see which programs needs restarting after installing updates. But for example restarting dbus makes whole system deeply broken.
yes, it would as to restart dbus *requires* a reboot.
I use Tumbleweed and usually once a week I logout from graphical session, go to text console, run zypper dup and then reboot. It's the only safe way.
I only reboot when it appears convenient and experience no problems. replaced binaries still have access (in memory) for the lib's they require. "only safe way" is an oxymoron. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
On 2021-03-10 9:58 a.m., cagsm wrote:
Hi there all hello list dwellers,
Anyone experience same erratics every now and then with high long uptime opensuse machines with gui usage?
Is this a know behavior of opensuse, or am I doing it wrong? If the stuff is normal, can one resort to some replace-in-use-files in a different manner, that might avoid such behavior of the high level apps?
After reboots and restarts of the various possible layers of the opensuse system, stuff comes back working normally.
[SNIP] I leave my GUI on with Thunderbird and a few hundred Firefox tables active for weeks at a time. In theory. I also have terminal windows running vmstat -SM -a 15 which is very useful. it shows me the developing trend of swap. Now I also have 'swapiness' set to '10'. Go Google to find out the why/wherefor/arguments about that. After a LOT of visiting new web pages and closing them the swap goes up to about the 4000 mark and the load factor to the 20s and higher and the machine becomes unresponsive until logout, manually purging swap or rebooting to force purge swap. It seems that the way firefox interacts with swap and caching is not good. Either that or the swap is fragmented rather than self contracting stack-like entity that frees up as the web pages get closed. Sometimes, just sometimes, I can swapon -s # to not just how much swapon /dev/vgmain/SWAP2 # which I have previously set up swapoff /dev/SWAP and watch the VMSTAT screen process that until it stabilizes, then swapon -s # to see if its contracted swapon /dev/SWAP swapoff /dev/vgmain/SWAP2 swapon -s and that should have got rid of any fragmentation of swap and brought it down. Well, it works for me, typically bringing the VMSTAT report down from around 5000 to under 1000 But the reality is that there is something broken with swap. maybe it can be turned out with a superior knowledge of the virtual memory settings, but that's beyond me. -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
* Anton Aylward <opensuse@antonaylward.com> [03-10-21 15:53]:
On 2021-03-10 9:58 a.m., cagsm wrote:
Hi there all hello list dwellers,
Anyone experience same erratics every now and then with high long uptime opensuse machines with gui usage?
Is this a know behavior of opensuse, or am I doing it wrong? If the stuff is normal, can one resort to some replace-in-use-files in a different manner, that might avoid such behavior of the high level apps?
After reboots and restarts of the various possible layers of the opensuse system, stuff comes back working normally.
[SNIP]
I leave my GUI on with Thunderbird and a few hundred Firefox tables active for weeks at a time. In theory.
I also have terminal windows running vmstat -SM -a 15 which is very useful. it shows me the developing trend of swap.
Now I also have 'swapiness' set to '10'. Go Google to find out the why/wherefor/arguments about that.
After a LOT of visiting new web pages and closing them the swap goes up to about the 4000 mark and the load factor to the 20s and higher and the machine becomes unresponsive until logout, manually purging swap or rebooting to force purge swap.
It seems that the way firefox interacts with swap and caching is not good. Either that or the swap is fragmented rather than self contracting stack-like entity that frees up as the web pages get closed.
Sometimes, just sometimes, I can
swapon -s # to not just how much swapon /dev/vgmain/SWAP2 # which I have previously set up swapoff /dev/SWAP and watch the VMSTAT screen process that until it stabilizes, then swapon -s # to see if its contracted swapon /dev/SWAP swapoff /dev/vgmain/SWAP2 swapon -s
and that should have got rid of any fragmentation of swap and brought it down.
Well, it works for me, typically bringing the VMSTAT report down from around 5000 to under 1000
But the reality is that there is something broken with swap. maybe it can be turned out with a superior knowledge of the virtual memory settings, but that's beyond me.
and I have no swap at all and >100 firefox pages active and ... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
On 10/03/2021 15.58, cagsm wrote:
Hi there all hello list dwellers,
i am not very fluent on the gui side of opensuse. When using current opensuse 15.2 systems but also in the years before, every now and then some test machine, simple standard kde gui level opensuse installation, no fancy setups.
having such a machine on and up a long time, a kde user logged in, the screen locked, e.g. simple kde desktop gui application itself (dunno whats it even called or concepts for sure, think: this plasma desktop and whatever), eventually this kind of a system become erratic on its gui side of things.
revisiting such a machinery, unlocking the desktop shows mess e.g. in a left open firefox gui, tabs becoming unklickable unchangeable, for example mething i remember a situation (dont really take my word for this everything as 100% but you get the idea, roughly ballpark, anyways continue the story) that i could still surf and use that one tab of that fricken firefox, but pretty much everything of it in the sense of frames, borders, resizing, moving around or its menues and elements that (my understanding of it, over the somewhat lengthy experience i myself had in the unix world, all about window managers, gui layers of the linux universe and such stuff) are triggering the operating system layers and libraries.... so these libariers might get exchanged and replaced by up- and in-coming opensuse patches, they get applied so far so fine. I always admired the unix world for being kind of able to overwrite and replace of nearly almost everything in its way in some still working healthy stable ways. in stark contrast to the windows world. so anyhow, these recent years i work myself the gui parts of linux a bit, and i kind of see (or guess) the downsize of all this.
so these high level applications such as the desktop plasma application itself and the firefoxen for example, become erratic, only parts of them staying up working, the rest refusing their parts of work.
during such times, only a restart of a mal functioning firefox helped, or even a restart of the display.service via systemctl, or even a reboot of a whole machine if that hadnt helped. i figured that it was some very deep down libraries or when kernel updates itself become applied, i think kernel packages also bring in files where some select externalized drivers reside and so on.
So simple question is, how do other gui opensuse users live with this. How do you have a nice and incomplicated life where your desktop machine just continues to work.
Don't update. Seriously, do not run updates till you are prepared to reboot. Many updates require a desktop restart. Say you update Java: well, some desktop applets use java, and you need to restart that component, or easier, just restart the desktop. Other updates require a reboot. Not strictly, but restarting the affected service is not trivial. dbus, systemd... So, to play safe, simply do not update till a day and hour of your choosing when you expect to reboot anyway. Recently I was working on a complicated edit job, and I kept the desktop running for 20 days (no, I was not working all the time on my project, maybe one hour a day). During that time I would not hibernate, because lately hibernate sometimes works, sometimes it crashes or locks. I would not update, lest some update would need a reboot to apply. I did one careful update one day to something, avoiding the rest (and there were many). Maybe I had to restart Thunderbird and/or Firefox once or twice. Specially Thunderbird can grow to 4 gigabytes or RAM and become slow even in this relatively powerful computer. The desktop was fine; I use XFCE (Leap 15.2). I had one problem, still unsolved: the display now doesn't go to sleep when inactive for the configured time, and I did not change configuration or made any update. Later, on next reboot, I noticed that the xscreensaver daemon was not running. Who knows why. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (6)
-
Adam Mizerski -
Anton Aylward -
cagsm -
Carlos E. R. -
Patrick Shanahan -
Simon Becherer