Has anyone else experienced this?  I've been getting it for quite a while on my desktop system and thought I might have a hardware issue.  However, I recently left my notebook computer running for a couple of days and it experienced the problem too.  Basically, after a couple of days, the computer will get sluggish and eventually become unusable.  Sometimes I can get out if it by repeatedly hitting Ctl-Alt-Backspace, until I'm taken to the login screen.  Other times, I have to reboot the computer.  My desktop is 15.1 and notebook 15.0, though the problem also happened with 15.0 on my desktop. On 2019-08-13 08:52 AM, James Knott wrote:

...

My OS 15.1 desktop computer with nvidia goes crazy since yesterday. After two or three days without reboot the KDE desktop suddenly freezed. I had to reset per hardware button. I have also been experiencing this for a while.  Some times I can break out of it by repeatedly hitting Ctrl-Alt-Backspace.  Then, after logging in, it works fine again for a couple of days.  Otherwise, I have to hit

On 2019-08-13 06:59 AM, Daniel Bauer wrote: the power button.  I have even run memtest overnight, to see if anything shows up.  My computer has an Intel Xeon E3-1200 video controller.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2019-09-02 11:14 AM, Patrick Shanahan wrote:

* James Knott [09-02-19 11:05]:

...

Has anyone else experienced this?  I've been getting it for quite a while on my desktop system and thought I might have a hardware issue.  However, I recently left my notebook computer running for a couple of days and it experienced the problem too.  Basically, after a couple of days, the computer will get sluggish and eventually become unusable.  Sometimes I can get out if it by repeatedly hitting Ctl-Alt-Backspace, until I'm taken to the login screen.  Other times, I have to reboot the computer.  My desktop is 15.1 and notebook 15.0, though the problem also happened with 15.0 on my desktop.

On 2019-08-13 08:52 AM, James Knott wrote:

...

...

My OS 15.1 desktop computer with nvidia goes crazy since yesterday. After two or three days without reboot the KDE desktop suddenly freezed. I had to reset per hardware button. I have also been experiencing this for a while.  Some times I can break out of it by repeatedly hitting Ctrl-Alt-Backspace.  Then, after logging in, it works fine again for a couple of days.  Otherwise, I have to hit

On 2019-08-13 06:59 AM, Daniel Bauer wrote: the power button.  I have even run memtest overnight, to see if anything shows up.  My computer has an Intel Xeon E3-1200 video controller.

are you running out of memory? or disc space, perhaps a cache getting too large? or swap space? can to get to a virtual terminal? which is it, intel or nvidia video?

you have not provided much to assess

I'm not sure what I'm running out of.  This system has 16 GB of memory and about 10 GB of swap.  As mentioned above, it's Intel Xeon video.  I have plenty of free disk space. The notebook has Intel integrated video, 8 GB of memory and 4.88 GB swap. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2019-09-02 11:29 AM, James Knott wrote:

On 2019-09-02 11:14 AM, Patrick Shanahan wrote:

...

* James Knott [09-02-19 11:05]:

...

Has anyone else experienced this?  I've been getting it for quite a while on my desktop system and thought I might have a hardware issue.  However, I recently left my notebook computer running for a couple of days and it experienced the problem too.  Basically, after a couple of days, the computer will get sluggish and eventually become unusable.  Sometimes I can get out if it by repeatedly hitting Ctl-Alt-Backspace, until I'm taken to the login screen.  Other times, I have to reboot the computer.  My desktop is 15.1 and notebook 15.0, though the problem also happened with 15.0 on my desktop.

On 2019-08-13 08:52 AM, James Knott wrote:

...

...

My OS 15.1 desktop computer with nvidia goes crazy since yesterday. After two or three days without reboot the KDE desktop suddenly freezed. I had to reset per hardware button. I have also been experiencing this for a while.  Some times I can break out of it by repeatedly hitting Ctrl-Alt-Backspace.  Then, after logging in, it works fine again for a couple of days.  Otherwise, I have to hit

On 2019-08-13 06:59 AM, Daniel Bauer wrote: the power button.  I have even run memtest overnight, to see if anything shows up.  My computer has an Intel Xeon E3-1200 video controller.

are you running out of memory? or disc space, perhaps a cache getting too large? or swap space? can to get to a virtual terminal? which is it, intel or nvidia video?

you have not provided much to assess

I'm not sure what I'm running out of.  This system has 16 GB of memory and about 10 GB of swap.  As mentioned above, it's Intel Xeon video.  I have plenty of free disk space.

The notebook has Intel integrated video, 8 GB of memory and 4.88 GB swap.

Before the last lockup, swap was around 4 G.  I have been running the system since this morning.  Even with Windows 10 running in VirtualBox, swap is still at 0.  Prior to failing, there is a lot of disk activity, but I have no idea what's causing it or swap to be used. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/09/2019 06.50, David C. Rankin wrote:

On 09/05/2019 11:54 AM, James Knott wrote:

...

...

The notebook has Intel integrated video, 8 GB of memory and 4.88 GB swap.

Before the last lockup, swap was around 4 G.  I have been running the system since this morning.  Even with Windows 10 running in VirtualBox, swap is still at 0.  Prior to failing, there is a lot of disk activity, but I have no idea what's causing it or swap to be used.

It sounds like you have a misbehaving app with a memory leak that is slowly malloc'ing your system to death.

Can you look at top and see if one proc has a virtual memory requirement that is off-scale high?

Start "top" in a terminal, then press "M" to sort by memory. Or "f" to choose fields, select "RES", press "sq". -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 06/09/2019 15.16, James Knott wrote:

On 2019-09-06 12:50 AM, David C. Rankin wrote:

...

On 09/05/2019 11:54 AM, James Knott wrote:

...

...

The notebook has Intel integrated video, 8 GB of memory and 4.88 GB swap.

Before the last lockup, swap was around 4 G.  I have been running the system since this morning.  Even with Windows 10 running in VirtualBox, swap is still at 0.  Prior to failing, there is a lot of disk activity, but I have no idea what's causing it or swap to be used.

It sounds like you have a misbehaving app with a memory leak that is slowly malloc'ing your system to death.

Can you look at top and see if one proc has a virtual memory requirement that is off-scale high?

I have top running now.  Earlier this morning, I was up to about 3.9 G swap.  I then started shutting down Firefox, Seamonkey and Chromium.  That dropped swap down to about 1.4 G.  However, given that I'm not even using all real memory, why is swap used at all?  Memory use is currently about 10 G of 16.

Just tell top to sort by swap used to find the culprit. Start "top" in a terminal, then "f" to choose fields, select "SWAP", press "sq". The change is not permanent, but it can if you wish. Has the machine being hibernated? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 09/06/2019 01:40 PM, James Knott wrote:

On 2019-09-06 02:34 PM, Carlos E. R. wrote:

...

Has the machine being hibernated?

No.  This is my main desktop system, which I leave running 24/7.

With ssd, I leave my laptop running 24/7 for weeks at a time. After 30 years of building and managing PC's (other than minimal energy consumption with the display off), there is no downside. I originally configure my power-button to put the laptop to sleep -- but found actually doing it was more an inconvenience than a benefit (I usually have 5-6 open ssh session running and Linux has not got to the point of restoring active sessions on wake from sleep --- yet :) The running box from which I posted the SUSE 10.0 /etc/SuSE-release info has probably been running continually 12-14 years, and the drive has been spinning since at least the SuSE 10.0 days. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2019-09-06 09:16 AM, James Knott wrote:

...

It sounds like you have a misbehaving app with a memory leak that is slowly malloc'ing your system to death.

Can you look at top and see if one proc has a virtual memory requirement that is off-scale high?

I have top running now.  Earlier this morning, I was up to about 3.9 G swap.  I then started shutting down Firefox, Seamonkey and Chromium.  That dropped swap down to about 1.4 G.  However, given that I'm not even using all real memory, why is swap used at all?  Memory use is currently about 10 G of 16.

I just noticed something curious.  There has been another problem, which requires me to occasionally run the command "kquitapp5 plasmashell && kstart5 plasmashell".  When I did that, swap dropped from about 3.6 G to 0.5. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/20/2019 08:34 AM, James Knott wrote:

...

I just noticed something curious.  There has been another problem, which requires me to occasionally run the command "kquitapp5 plasmashell && kstart5 plasmashell".  When I did that, swap dropped from about 3.6 G to 0.5.

This issue continues and I have not been able to find any app causing it.  Swap keeps increasing, even though not all of the memory is being used.  After killing and restarting the desktop swap is back to zero.  I have tried killing individual apps and while that reduces memory use, it has little effect on swap.

That all seems to be pointing to one big shell that is filling swap. Is it possible that you may have an old config file (some tag-along from kde4) that might be giving plasma fits? (that's just a guess) If everybody isn't suffering the same gradual slowdown/freeze, then it has to be something unique to your config. I don't know of any quick way to find out what is in the swap file, maybe other can offer something there. If we can find out what data is filling it up, then that would at least point in the right direction. Something like an old screen saver, etc.. that the first part of the generic screen save module sets up and allocates for and then forks waiting on some signal to deallocate that never comes? Or maybe of a second display that is no longer there? Just grasping at straws, but it has to be something that is special about your (and a few others) setup. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 22/09/2019 03.58, James Knott wrote:

On 2019-09-21 09:28 PM, David C. Rankin wrote:

...

On 09/20/2019 08:34 AM, James Knott wrote:

...

...

I just noticed something curious.  There has been another problem, which requires me to occasionally run the command "kquitapp5 plasmashell && kstart5 plasmashell".  When I did that, swap dropped from about 3.6 G to 0.5.

This issue continues and I have not been able to find any app causing it.  Swap keeps increasing, even though not all of the memory is being used.  After killing and restarting the desktop swap is back to zero.  I have tried killing individual apps and while that reduces memory use, it has little effect on swap.

You know that you can use "top" to know precisely what process is using swap? top - 13:28:15 up 5 days, 23:07, 3 users, load average: 0,26, 0,45, 0,55 Tasks: 479 total, 1 running, 477 sleeping, 0 stopped, 1 zombie %Cpu(s): 4,5 us, 1,7 sy, 0,1 ni, 89,0 id, 4,8 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161116 total, 2281060 free, 4781372 used, 1098684 buff/cache KiB Swap: 25165820 total, 19922552 free, 5243268 used. 2956448 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 4416 vscan 20 0 1086788 31788 4260 720144 S 0,000 0,390 7:54.32 clamd 5716 cer 20 0 4382992 1,080g 78204 351276 S 0,000 13,87 239:22.65 thunderbird-bin 5976 cer 20 0 2959464 434296 66256 278816 S 1,190 5,322 43:59.24 Web Content 5923 cer 20 0 2929708 549964 56144 260172 S 0,893 6,739 34:21.23 Web Content 2347 named 20 0 564224 49152 6000 188388 S 0,000 0,602 0:52.50 named 7639 cer 20 0 3914780 5644 1536 178944 S 0,000 0,069 1:15.20 java 6010 cer 20 0 2829244 588560 117052 170712 S 1,786 7,212 41:14.24 Web Content ******

...

That all seems to be pointing to one big shell that is filling swap. Is it possible that you may have an old config file (some tag-along from kde4) that might be giving plasma fits? (that's just a guess) If everybody isn't suffering the same gradual slowdown/freeze, then it has to be something unique to your config. I don't know of any quick way to find out what is in the swap file, maybe other can offer something there. If we can find out what data is filling it up, then that would at least point in the right direction. Something like an old screen saver, etc.. that the first part of the generic screen save module sets up and allocates for and then forks waiting on some signal to deallocate that never comes? Or maybe of a second display that is no longer there? Just grasping at straws, but it has to be something that is special about your (and a few others) setup.

No, it was a fresh install of 15.1, not an update.  I have no idea what might cause this.  I've tried various things, but nothing is consistent.  I'm surprised swap is being used, when there's still plenty of RAM available.

That doesn't surprise me. Swap is used precisely to free some ram. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 22/09/2019 14.22, James Knott wrote:

On 2019-09-22 07:30 AM, Carlos E. R. wrote:

...

You know that you can use "top" to know precisely what process is using swap?

Yes, I have been using top and System Monitor.  However, I have not been able to identify what might be causing this.

You have to configure it to show swap usage. It may not be on by default. And once it displays swap, you have to configure to sort by swap usage.

Also, as I mentioned earlier, this also happened on my notebook computer, after leaving it up for a couple of days.

-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 23/09/2019 14.53, James Knott wrote:

On 2019-09-21 09:28 PM, David C. Rankin wrote:

...

...

...

I just noticed something curious.  There has been another problem, which requires me to occasionally run the command "kquitapp5 plasmashell && kstart5 plasmashell".  When I did that, swap dropped from about 3.6 G to 0.5.

This issue continues and I have not been able to find any app causing it.  Swap keeps increasing, even though not all of the memory is being used.  After killing and restarting the desktop swap is back to zero.  I have tried killing individual apps and while that reduces memory use, it has little effect on swap. That all seems to be pointing to one big shell that is filling swap. Is it

On 09/20/2019 08:34 AM, James Knott wrote: possible that you may have an old config file (some tag-along from kde4) that might be giving plasma fits? (that's just a guess) If everybody isn't suffering the same gradual slowdown/freeze, then it has to be something unique to your config. I don't know of any quick way to find out what is in the swap file, maybe other can offer something there. If we can find out what data is filling it up, then that would at least point in the right direction. Something like an old screen saver, etc.. that the first part of the generic screen save module sets up and allocates for and then forks waiting on some signal to deallocate that never comes? Or maybe of a second display that is no longer there? Just grasping at straws, but it has to be something that is special about your (and a few others) setup.

This morning, when the computer started slowing down again, swap was around 5 G. 

Did you remember to tell top to sort by swap use?

I then shut down everything except top and system monitor.  After an hour, top showed a couple of lines of "Web Content" at about 125% CPU, even though there were no browsers running.  Swap had dropped to about 4 G.

You know that you can kill those "web content" threads. Exiting the browser doesn't always close all threads, specially one that is running away. In fact, if you don't exit the browser, then kill the runaway process, you can then find the dead tabs and narrow on which is the culprit. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 23/09/2019 18.34, James Knott wrote:

On 2019-09-23 09:00 AM, Carlos E. R. wrote:

...

Did you remember to tell top to sort by swap use?

I didn't this time, but have in the past.  I couldn't identify any suspects.

Do it, please. *Show swap, and then and sort by swap*. An then post it here. Or: top -b -n 1 -o SWAP > somefile.txt

...

You know that you can kill those "web content" threads.

Why should that be necessary?  If swap keeps on growing and the system bogs down, then that indicates some problem with process management.

Nope. It means a problem with just one application or even one thread of one application. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 23/09/2019 20.16, James Knott wrote:

On 2019-09-23 02:10 PM, Carlos E. R. wrote:

...

Do it, please. *Show swap, and then and sort by swap*. An then post it here.

Or:

top -b -n 1 -o SWAP > somefile.txt

I'll try, but please bear in mind that I usually can't do anything other than hit the power button when it happens.  Today, I was fortunate that I was able to switch to already running apps, after killing everything else.  I do leave top and system monitor running and check them periodically.

Ah. Ok. Once, to analyze a freeze condition, I did something like: top -d 60 -b -o SWAP | tee less > somefile.txt running in a terminal. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On Mon, 23 Sep 2019 14:41:35 -0400 James Knott wrote:

On 2019-09-23 02:28 PM, Carlos E. R. wrote:

...

Ah. Ok.

Once, to analyze a freeze condition, I did something like:

top -d 60 -b -o SWAP | tee less > somefile.txt

running in a terminal.

When it freezes, about all I can do is ping it from another computer.  I can't even ssh in.  It's locked up solid, with the drive light on constantly.

If you can ssh in before the problem occurs and leave that window running top with Carlos' options, then it should show exactly what is happening when the system freezes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2019-09-23 05:17 PM, Carlos E. R. wrote:

Which is precisely why I told you to leave that terminal running with that command in advance, and examine the resulting file after crash and reboot. Better with REISUB.

Even better if you do it via ssh from another computer - way before the crash.

Most of the time when it locks up, I can't even switch to open apps.  This morning I was able to, as I could see it coming.  As I mentioned in another note, a can't ssh in when it happens.  Most of the time, my only option is to power down and up.  Even repeatedly hitting Ctl-Alt-Backspace usually doesn't work.  That makes it difficult to do anything other than hit the power button.  If I'm at the computer when it starts, I may be able to do something.  If I'm away and then come back, the computer is completely locked up. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/09/2019 00.58, James Knott wrote:

On 2019-09-23 05:17 PM, Carlos E. R. wrote:

...

Which is precisely why I told you to leave that terminal running with that command in advance, and examine the resulting file after crash and reboot. Better with REISUB.

Even better if you do it via ssh from another computer - way before the crash.

Most of the time when it locks up, I can't even switch to open apps.  This morning I was able to, as I could see it coming.  As I mentioned in another note, a can't ssh in when it happens.  Most of the time, my only option is to power down and up.  Even repeatedly hitting Ctl-Alt-Backspace usually doesn't work.  That makes it difficult to do anything other than hit the power button.  If I'm at the computer when it starts, I may be able to do something.  If I'm away and then come back, the computer is completely locked up.

I repeat: you do this *before* it crashes. Hours or days before it crashes. And you leave it running, for hours or days. As long as it takes. After your machine crashes, and after you reboot, preferably with REISUB, you examine the file my proposed command wrote. As it will be large, you upload it to susepaste and tell the link. top -d 60 -b -o SWAP | tee less > somefile.txt -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

* James Knott [09-23-19 21:40]:

On 2019-09-23 09:26 PM, Carlos E. R. wrote:

...

preferably with REISUB

What is "REISUB"?

you don't have google? -- (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 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/09/2019 11.12, Carlos E. R. wrote:

On 24/09/2019 03.37, James Knott wrote:

...

On 2019-09-23 09:26 PM, Carlos E. R. wrote:

...

preferably with REISUB

What is "REISUB"?

https://en.wikipedia.org/wiki/Magic_SysRq_key#Uses

Right-alt or AltGr, + PrintScreen, then the other letter keys in slow sequence. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)