[opensuse-support] Unresponsive desktop

older
[opensuse-support] Permission on...

Carlos E. R.

3 Feb 2019 3 Feb '19

13:33

Hi, Last December I reported this problem on my laptop, and now my desktop also exhibits it. After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted. A week before it also froze, but that time I could not observe anything. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Attachments:

signature.asc (application/pgp-signature — 195 bytes)

Show replies by date

Patrick Shanahan

3 Feb 3 Feb

13:46

* Carlos E. R. [02-03-19 08:34]:

...

Hi,

Last December I reported this problem on my laptop, and now my desktop also exhibits it.

After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

A week before it also froze, but that time I could not observe anything.

I have noticed firefox on occasion to decide to use all the memory it could find and had to kill/restart firefox, but never to the point of requiring a reboot. but I have no swap and 36gb of memory. but you don't say which system version or DT or firefox Tumbleweed Plasma5/KDE5 MozillaFirefox-64.0-1.2 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

13:56

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2019-02-03 at 08:46 -0500, Patrick Shanahan wrote:

...

* Carlos E. R. <> [02-03-19 08:34]:

...
Hi,

Last December I reported this problem on my laptop, and now my desktop also exhibits it.

After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

A week before it also froze, but that time I could not observe anything.

I have noticed firefox on occasion to decide to use all the memory it could find and had to kill/restart firefox, but never to the point of requiring a reboot. but I have no swap and 36gb of memory.

I had no chance to kill firefox, system froze while I tried to issue the command. The laptop has 4 gigs, the desktop has 8, so it takes longer to crash. I might have to start firefox with ulimit, but I don't know what limits to give it.

...

but you don't say which system version or DT or firefox

Yes, I do. See signature. Firefox is the default version that comes with it: MozillaFirefox-60.4.0-lp150.3.30.1.x86_64 Desktop is XFCE. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFbzGBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVpUEAn0K6hsdddd+9VDOF4QFA nM1oyQ2TAKCZYek45GCZhWpBYyNJTExjTUrHTw== =Fwqx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Peter Suetterlin

16:35

Carlos E. R. wrote:

...

I had no chance to kill firefox, system froze while I tried to issue the command.

The laptop has 4 gigs, the desktop has 8, so it takes longer to crash.

I might have to start firefox with ulimit, but I don't know what limits to give it.

This sounds similar to my hangs when my image processing started using more RAM than physically available, and it pushed anything from the GUI into swap. So any UI interaction would need swap-in, but that one had been busy due to the processing. In my case it was 'dead' for almost an hour - and then came back as if nothing happened.... My solution had been to limit the process using cgroups to not use more than MEM-2GB physical RAM. In other words, as soon as it wants more than that amount, it starts using swap. That leaves enough memory for the GUI to remain responsive. For my machine here (16GB) the setup script looks like this: lux:~ # cat bin/mk14Ggroup #!/bin/sh mkdir /sys/fs/cgroup/memory/14G echo 15032385536 > /sys/fs/cgroup/memory/14G/memory.limit_in_bytes chown root.users /sys/fs/cgroup/memory/14G/cgroup.procs chmod 775 /sys/fs/cgroup/memory/14G/cgroup.procs Any user can then echo $PID > /sys/fs/cgroup/memory/14G/cgroup.procs and the process $PID will be limited that way. I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine) -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

4 Feb 4 Feb

12:16

On 03/02/2019 17.35, Peter Suetterlin wrote:

...

Carlos E. R. wrote:

...
I had no chance to kill firefox, system froze while I tried to issue the command.

The laptop has 4 gigs, the desktop has 8, so it takes longer to crash.

I might have to start firefox with ulimit, but I don't know what limits to give it.

This sounds similar to my hangs when my image processing started using more RAM than physically available, and it pushed anything from the GUI into swap. So any UI interaction would need swap-in, but that one had been busy due to the processing. In my case it was 'dead' for almost an hour - and then came back as if nothing happened....

My solution had been to limit the process using cgroups to not use more than MEM-2GB physical RAM. In other words, as soon as it wants more than that amount, it starts using swap. That leaves enough memory for the GUI to remain responsive.

Yes, but for that you have to know which process to limit. I don't have a clear culprit. I had been sleeping, the machine was idling. As I recall, I sat on my computer, had a glance at Thunderbird, there was an unsent usenet post, so clicked to send. Machine was responding normally, maybe a bit slow; I noticed on the "Multiload" applet that it was loaded on i/o, so I pressed the key combination to go one workspace to the left, where one terminal was running top, to have a look. Bamm! A terminal was white, failed to refresh. The log terminal displayed content of several hours earlier. The one with top did not respond to keys, as I wanted to kill firefox, which had 10.5 GB of virtual memory. Things finally froze completely.

...

For my machine here (16GB) the setup script looks like this:

lux:~ # cat bin/mk14Ggroup #!/bin/sh mkdir /sys/fs/cgroup/memory/14G echo 15032385536 > /sys/fs/cgroup/memory/14G/memory.limit_in_bytes chown root.users /sys/fs/cgroup/memory/14G/cgroup.procs chmod 775 /sys/fs/cgroup/memory/14G/cgroup.procs

Any user can then echo $PID > /sys/fs/cgroup/memory/14G/cgroup.procs and the process $PID will be limited that way.

I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes

Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine)

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

Peter Suetterlin

13:03

Carlos E. R. wrote:

...

Yes, but for that you have to know which process to limit. I don't have a clear culprit. I had been sleeping, the machine was idling.

In that case you *might* try the top-level limit, I think that should not allow *any* process to use all physical space. You'd still be f****d if two of those would start competeing heavily, but it should be better...

...

As I recall, I sat on my computer, had a glance at Thunderbird, there was an unsent usenet post, so clicked to send. Machine was responding normally, maybe a bit slow; I noticed on the "Multiload" applet that it was loaded on i/o, so I pressed the key combination to go one workspace to the left, where one terminal was running top, to have a look. Bamm! A terminal was white, failed to refresh. The log terminal displayed content of several hours earlier. The one with top did not respond to keys, as I wanted to kill firefox, which had 10.5 GB of virtual memory. Things finally froze completely.

Yes, exactly the same. Try a switch, content and applications on that other screen are swaped out already, and the culprit process is hitting the swap that hard that there's no chance the needed swap is read back :(

...

...
I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes

Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine)

So in your case (6GB limit) # echo 6442450944 > /sys/fs/cgroup/memory/memory.limit_in_bytes As I said, it would not limit the amount of (total) memory the process uses - it just starts swapping when that limit is reached, before all physical mem is used up. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

13:31

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2019-02-04 at 14:03 +0100, Peter Suetterlin wrote:

...

Carlos E. R. wrote:

...
Yes, but for that you have to know which process to limit. I don't have a clear culprit. I had been sleeping, the machine was idling.

In that case you *might* try the top-level limit, I think that should not allow *any* process to use all physical space. You'd still be f****d if two of those would start competeing heavily, but it should be better...

Firefox is divided in five processes. One master and four childs. I don't see how to limit the total of them.

...

...
As I recall, I sat on my computer, had a glance at Thunderbird, there was an unsent usenet post, so clicked to send. Machine was responding normally, maybe a bit slow; I noticed on the "Multiload" applet that it was loaded on i/o, so I pressed the key combination to go one workspace to the left, where one terminal was running top, to have a look. Bamm! A terminal was white, failed to refresh. The log terminal displayed content of several hours earlier. The one with top did not respond to keys, as I wanted to kill firefox, which had 10.5 GB of virtual memory. Things finally froze completely.

Yes, exactly the same. Try a switch, content and applications on that other screen are swaped out already, and the culprit process is hitting the swap that hard that there's no chance the needed swap is read back :(

Sorry, I don't understand this paragarph. What switch? I didn't have a chance to find who was hitting swap heavily.

...

...
...
I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes

Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine)

So in your case (6GB limit)

# echo 6442450944 > /sys/fs/cgroup/memory/memory.limit_in_bytes

As I said, it would not limit the amount of (total) memory the process uses - it just starts swapping when that limit is reached, before all physical mem is used up.

I don't think anything was using 6 GB. But it is possible that the 5 firefox processes in total were hitting it. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFg+vRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVYH0AoJVB0d/S8SwMlpBnQOj8 5SP39Fb2AJ0bh+XYjgZ/qOxlk/0C7V3aqopq/g== =5x0A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Peter Suetterlin

13:45

Carlos E. R. wrote:

...

Firefox is divided in five processes. One master and four childs. I don't see how to limit the total of them.

Good question. I don't really know how the cgroup stuff works :(

...

...
Yes, exactly the same. Try a switch, content and applications on that other screen are swaped out already, and the culprit process is hitting the swap that hard that there's no chance the needed swap is read back :(

Sorry, I don't understand this paragarph. What switch?

Argh. Sorry for my sloppy wording. Yes, *I experienced* exactly the same. I tried to switch *to another virtual screen*, *swapping blocks further gui interaction*

...

I didn't have a chance to find who was hitting swap heavily.

Doesn't even help if you know (I did). There's no way to do something. Either press the power button, or wait. (In my experience) the system is still running, just slow as if it were doing computations using an Abakus.... -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

13:56

* Peter Suetterlin [02-03-19 11:37]:

...

Carlos E. R. wrote:

...
I had no chance to kill firefox, system froze while I tried to issue the command.

The laptop has 4 gigs, the desktop has 8, so it takes longer to crash.

I might have to start firefox with ulimit, but I don't know what limits to give it.

This sounds similar to my hangs when my image processing started using more RAM than physically available, and it pushed anything from the GUI into swap. So any UI interaction would need swap-in, but that one had been busy due to the processing. In my case it was 'dead' for almost an hour - and then came back as if nothing happened....

My solution had been to limit the process using cgroups to not use more than MEM-2GB physical RAM. In other words, as soon as it wants more than that amount, it starts using swap. That leaves enough memory for the GUI to remain responsive.

For my machine here (16GB) the setup script looks like this:

lux:~ # cat bin/mk14Ggroup #!/bin/sh mkdir /sys/fs/cgroup/memory/14G echo 15032385536 > /sys/fs/cgroup/memory/14G/memory.limit_in_bytes chown root.users /sys/fs/cgroup/memory/14G/cgroup.procs chmod 775 /sys/fs/cgroup/memory/14G/cgroup.procs

Any user can then echo $PID > /sys/fs/cgroup/memory/14G/cgroup.procs and the process $PID will be limited that way.

then to include firefox, replace "echo $PID" with echo $(pidof firefox) or a script using at or cron or systemd-timer to repeatedly check for the presence in cgroup.procs of firefox pid's and add/remove to reflect current situation.

...

I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes

Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine) -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Dave Howorth

3 Feb 3 Feb

20:44

On Sun, 3 Feb 2019 14:56:40 +0100 (CET) "Carlos E. R." wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sunday, 2019-02-03 at 08:46 -0500, Patrick Shanahan wrote:

...
* Carlos E. R. <> [02-03-19 08:34]:

...
Hi,

Last December I reported this problem on my laptop, and now my desktop also exhibits it.

After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

A week before it also froze, but that time I could not observe anything.

I have noticed firefox on occasion to decide to use all the memory it could find and had to kill/restart firefox, but never to the point of requiring a reboot. but I have no swap and 36gb of memory.

Hmm, I haven't seen this but sometimes when I have a large number (for me, anyway) of tabs & windows open, the system slows down to the point where I think "I must close all the Firefox pages and restart it". Occasionally Firefox has crashed but I've never understood why so just let it report the crash and restart itself.

...

I had no chance to kill firefox, system froze while I tried to issue the command.

Whenever I try to debug problems like this I find it can be helpful to ssh into the machine with the problem as soon as it is started, su to root and keep the session open in the background. Frequently when the problem machine subsequently 'hangs' it has proven to just be extremely sluggish and it has been possible to kill or suspend the most likely culprit process to recover the machine. Sometimes I have waited for half an hour or more whilst the command executes. Sometimes it is also possible to run things like top or strace through the ssh session to gather more information.

...

...
but you don't say which system version or DT or firefox

Yes, I do. See signature.

You're right in the letter of the law but not the spirit, IMHO. Many people don't notice the signature, or may not even display it to avoid taking offence at some of the things people post there. And the suspicion always remains about whether details in the signature are accurate for the system with the problem, as opposed to the system from which the message is being posted. So I think it's better to be explicit in the body of the message.

...

Firefox is the default version that comes with it:

MozillaFirefox-60.4.0-lp150.3.30.1.x86_64

Desktop is XFCE.

FWIW, I'm using the same OS and FF but run LXDE. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

4 Feb 4 Feb

12:20

On 03/02/2019 21.44, Dave Howorth wrote:

...

On Sun, 3 Feb 2019 14:56:40 +0100 (CET) "Carlos E. R." <> wrote:

...

Hmm, I haven't seen this but sometimes when I have a large number (for me, anyway) of tabs & windows open, the system slows down to the point where I think "I must close all the Firefox pages and restart it". Occasionally Firefox has crashed but I've never understood why so just let it report the crash and restart itself.

...
I had no chance to kill firefox, system froze while I tried to issue the command.

Whenever I try to debug problems like this I find it can be helpful to ssh into the machine with the problem as soon as it is started,

I tried. It did not connect.

...

...
Firefox is the default version that comes with it:

MozillaFirefox-60.4.0-lp150.3.30.1.x86_64

Desktop is XFCE.

FWIW, I'm using the same OS and FF but run LXDE.

I have two machines that started having problems after upgraded to 15.0. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Dave Howorth

15:37

On Mon, 4 Feb 2019 13:20:20 +0100 "Carlos E. R." wrote:

...

On 03/02/2019 21.44, Dave Howorth wrote:

...
On Sun, 3 Feb 2019 14:56:40 +0100 (CET) "Carlos E. R." <> wrote:

...
Hmm, I haven't seen this but sometimes when I have a large number (for me, anyway) of tabs & windows open, the system slows down to the point where I think "I must close all the Firefox pages and restart it". Occasionally Firefox has crashed but I've never understood why so just let it report the crash and restart itself.

...
I had no chance to kill firefox, system froze while I tried to issue the command.

Whenever I try to debug problems like this I find it can be helpful to ssh into the machine with the problem as soon as it is started,

I tried. It did not connect.

Then investigate that problem first! If you boot a machine and cannot immediately ssh into it then there's something seriously wrong. (Unless it hasn't finished booting or sshd isn't enabled, of course). The whole point is to establish the ssh connection long before any problems arise.

...

...
...
Firefox is the default version that comes with it:

MozillaFirefox-60.4.0-lp150.3.30.1.x86_64

Desktop is XFCE.

FWIW, I'm using the same OS and FF but run LXDE.

I have two machines that started having problems after upgraded to 15.0.

Other possible variables are any add-ons you use in FF and the video hardware and drivers. I'd suggest running without add-ons, or at least only a few basic ones, and using the most basic video driver that works. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Jiri Slaby

5 Feb 5 Feb

09:54

New subject: [opensuse-support] Re: Unresponsive desktop

On 03. 02. 19, 14:33, Carlos E. R. wrote:

...

After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

Sometimes, this gets logged as OOM. Have you checked logs from the boot right before the reboot? regards, -- js suse labs -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

10:59

New subject: [opensuse-support] Re: Unresponsive desktop

On 05/02/2019 10.54, Jiri Slaby wrote:

...

On 03. 02. 19, 14:33, Carlos E. R. wrote:

...
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

Sometimes, this gets logged as OOM. Have you checked logs from the boot right before the reboot?

Yes, nothing. The word "OOM" is nowhere in the logs from 2019-01-28 to 2019-02-05. /var/log/messages during the event: <3.6> 2019-02-03 13:00:01 Telcontar dbus-daemon 1537 - - [system] Activating service name='org.opensuse.Snapper' requested by ':1.10447' (ui d=0 pid=29269 comm="/usr/lib/snapper/systemd-helper --timeline ") (using servicehelper) <3.6> 2019-02-03 13:00:01 Telcontar dbus-daemon 1537 - - [system] Successfully activated service 'org.opensuse.Snapper' <10.6> 2019-02-03 13:00:01 Telcontar cron 29258 - - pam_unix(crond:session): session opened for user cer by (uid=0) <10.6> 2019-02-03 13:00:01 Telcontar cron 29257 - - pam_unix(crond:session): session opened for user cer by (uid=0) <9.6> 2019-02-03 13:00:01 Telcontar CRON 29292 - - (cer) CMD (/home/cer/bin/dar_la_hora_en_cron hora) <10.6> 2019-02-03 13:00:01 Telcontar CRON 29257 - - pam_unix(crond:session): session closed for user cer <10.6> 2019-02-03 13:00:05 Telcontar CRON 29258 - - pam_unix(crond:session): session closed for user cer <3.6> 2019-02-03 13:06:46 Telcontar smartd 1473 - - Device: /dev/sdc [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 7 8 to 79 <3.6> 2019-02-03 13:06:46 Telcontar smartd 1473 - - Device: /dev/sdc [SAT], SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 7 8 to 79 <3.6> 2019-02-03 13:09:28 Telcontar systemd 1 - - Started Leafnode NNTP server (127.0.0.1:35362). <3.6> 2019-02-03 13:09:28 Telcontar systemd 1 - - Started Leafnode NNTP server (127.0.0.1:35360). <10.6> 2019-02-03 13:20:01 Telcontar cron 30074 - - pam_unix(crond:session): session opened for user cer by (uid=0) <10.6> 2019-02-03 13:20:01 Telcontar CRON 30074 - - pam_unix(crond:session): session closed for user cer <10.6> 2019-02-03 13:24:05 Telcontar unix2_chkpwd - - - gkr-pam: unlocked login keyring <3.6> 2019-02-03 13:24:11 Telcontar systemd 1 - - Started Leafnode NNTP server (127.0.0.1:35744). <3.6> 2019-02-03 13:24:11 Telcontar systemd 1 - - Started Leafnode NNTP server (127.0.0.1:35742). <10.3> 2019-02-03 13:28:54 Telcontar cron 30378 - - pam_systemd(crond:session): Failed to create session: Connection timed out 2019-02-03 13:34:47+01:00 - Booting the system now ================================================================================ Linux T "Started Leafnode NNTP server" is probably when I successful sent one nntp (news) post on Thunderbird on workspace 2, instants before it hanged. Going to the "/var/log/allmessages-20190204.xz" log, I can see some more details: <63>1 2019-02-03T13:24:16.583416+01:00 Telcontar fetchnews 30228 - - <211 0 451 450 comp.os.linux.announce <63>1 2019-02-03T13:24:16.583442+01:00 Telcontar fetchnews 30228 - - >GROUP comp.os.linux.embedded <63>1 2019-02-03T13:24:16.633080+01:00 Telcontar fetchnews 30228 - - <211 4 1842 1845 comp.os.linux.embedded <62>1 2019-02-03T13:24:16.633109+01:00 Telcontar fetchnews 30228 - - comp.os.linux.embedded: no new articles <63>1 2019-02-03T13:24:16.633372+01:00 Telcontar fetchnews 30228 - - >QUIT <62>1 2019-02-03T13:24:16.782370+01:00 Telcontar fetchnews 30228 - - wrote active file with 46702 lines <63>1 2019-02-03T13:24:16.782824+01:00 Telcontar fetchnews 30252 - - Process forked. <62>1 2019-02-03T13:24:16.823734+01:00 Telcontar fetchnews 30228 - - child has process ID 30252 <86>1 2019-02-03T13:24:16.832408+01:00 Telcontar CRON 30219 - - pam_unix(crond:session): session closed for user news <30>1 2019-02-03T13:24:16.837939+01:00 Telcontar systemd 1 - - Stopping User Manager for UID 9... <86>1 2019-02-03T13:24:16.856877+01:00 Telcontar systemd - - - pam_unix(systemd-user:session): session closed for user news <30>1 2019-02-03T13:24:16.857733+01:00 Telcontar systemd 1 - - Stopped User Manager for UID 9. <30>1 2019-02-03T13:24:16.858306+01:00 Telcontar systemd 1 - - Removed slice User Slice of news. <63>1 2019-02-03T13:24:17.825814+01:00 Telcontar fetchnews 30252 - - Process done. <63>1 2019-02-03T13:25:40.081855+01:00 Telcontar leafnode 30240 - - 1 2019-02-03T13:25:40.081890+01:00 Telcontar leafnode 30240 - - rereading /var/spool/news/leaf.node/groupinfo <63>1 2019-02-03T13:25:40.443816+01:00 Telcontar leafnode 30240 - - >340 Go ahead. <63>1 2019-02-03T13:25:40.566794+01:00 Telcontar leafnode 30240 - - >240 Article posted, now be patient <22>1 2019-02-03T13:26:23.993497+01:00 Telcontar dovecot - - - imap(cer)<30193>: Logged out in=3526 out=9193 deleted=0 exp unged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 <22>1 2019-02-03T13:26:25.188125+01:00 Telcontar dovecot - - - imap-login: Login: user=<cer>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mp id=30339, TLS, session= <30>1 2019-02-03T13:28:29.454128+01:00 Telcontar systemd 1 - - Created slice User Slice of news. <30>1 2019-02-03T13:28:29.964244+01:00 Telcontar systemd 1 - - Starting User Manager for UID 9... <30>1 2019-02-03T13:28:30.608901+01:00 Telcontar systemd 1 - - Started Session 4871 of user news. <83>1 2019-02-03T13:28:54.199886+01:00 Telcontar cron 30378 - - pam_systemd(crond:session): Failed to create session: Connection timed out <86>1 2019-02-03T13:28:56.968197+01:00 Telcontar cron 30378 - - pam_unix(crond:session): session opened for user news by (uid=0) <63>1 2019-02-03T13:29:17.142305+01:00 Telcontar fetchnews 30386 - - config: debugmode is 1 <63>1 2019-02-03T13:29:17.279998+01:00 Telcontar fetchnews 30386 - - config: maxfetch is 5000 <63>1 2019-02-03T13:29:17.280033+01:00 Telcontar fetchnews 30386 - - config: maxage is 0 You can see how it is working, then things start to fail at 13:28, yet fetchnews is running correctly <63>1 2019-02-03T13:29:17.280033+01:00 Telcontar fetchnews 30386 - - config: maxage is 0 <63>1 2019-02-03T13:29:17.280053+01:00 Telcontar fetchnews 30386 - - config: postings have max. 500000 bytes <63>1 2019-02-03T13:29:17.280075+01:00 Telcontar fetchnews 30386 - - config: timeout_long is 100 days <63>1 2019-02-03T13:29:17.280097+01:00 Telcontar fetchnews 30386 - - config: timeout_fetchnews is 90 seconds ... trimming <63>1 2019-02-03T13:29:23.735856+01:00 Telcontar fetchnews 30386 - - check_date: News.Individual.NET: server time 1549196963, our time 15491 96963 ... trimming ... trimming <62>1 2019-02-03T13:29:39.454094+01:00 Telcontar fetchnews 30386 - - comp.os.linux.embedded: no new articles <63>1 2019-02-03T13:29:39.581622+01:00 Telcontar fetchnews 30386 - - >QUIT <62>1 2019-02-03T13:29:39.971244+01:00 Telcontar fetchnews 30386 - - wrote active file with 46702 lines <63>1 2019-02-03T13:29:40.107338+01:00 Telcontar fetchnews 30387 - - Process forked. <62>1 2019-02-03T13:29:40.107366+01:00 Telcontar fetchnews 30386 - - child has process ID 30387 <30>1 2019-02-03T13:34:48.596658+01:00 Telcontar systemd 1 - - systemd 234 running in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN default-hierarchy=hybrid) <30>1 2019-02-03T13:34:48.596706+01:00 Telcontar systemd 1 - - Detected architecture x86-64. <30>1 2019-02-03T13:34:48.596715+01:00 Telcontar systemd 1 - - Set hostname to <Telcontar>. <28>1 2019-02-03T13:34:48.596721+01:00 Telcontar systemd 1 - - nss-lookup.target: Dependency Before=nss-lookup.target dropped <30>1 2019-02-03T13:34:48.596727+01:00 Telcontar apparmor.systemd 632 - - Restarting AppArmor <30>1 2019-02-03T13:34:48.596737+01:00 Telcontar apparmor.systemd 632 - - Reloading AppArmor profiles And that's the reboot. Last entry 2019-02-03T13:29:40.107366+01:00. What I could see in the top display (I should have made a photo with camera) was similar to this, taken last December on the laptop, that also has that problem: PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 38 root 20 0 0 0 0 0 S 25.39 0.000 20:48.33 kswapd0 <=== -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Liam Proven

12:02

New subject: [opensuse-support] Re: Unresponsive desktop

On 2/3/19 2:33 PM, Carlos E. R. wrote:

...

I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

I would observe that RAM starvation seems to be the related to a number of your problems. I also note your fondness for running a local IMAP server, _with_ virus scanning too, on multiple machines. I suggest that these problems are related. I would further suggest: * stop running local IMAP servers. Put them on a dedicated host. Consider putting virus scanning on a separate dedicated host, too. (Others have said this too. I know you don't want to. I know you have reasons. Re-evaluate them. Listen to the advice.) * Investigate compcache and other measures to swap compressed data for greater efficiency. * Buy more RAM. If an old machine won't take more RAM, replace it with a slightly less-old machine. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

13:13

New subject: [opensuse-support] Re: Unresponsive desktop

On 05/02/2019 13.02, Liam Proven wrote:

...

On 2/3/19 2:33 PM, Carlos E. R. wrote:

...
I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

I would observe that RAM starvation seems to be the related to a number of your problems.

I also note your fondness for running a local IMAP server, _with_ virus scanning too, on multiple machines.

I suggest that these problems are related.

I would further suggest:

* stop running local IMAP servers. Put them on a dedicated host. Consider putting virus scanning on a separate dedicated host, too. (Others have said this too. I know you don't want to. I know you have reasons. Re-evaluate them. Listen to the advice.)

I might move clamav, but not dovecot. It is not memory hungry. And further, I need dovecot on all my laptops, the home server is not accessible to them all time. At worst, dovecot would be served from the desktop machine precisely. And, 42.3 did not exhibit this hanging problem, with the same load. Being slow is one thing, crashing is another.

...

* Investigate compcache and other measures to swap compressed data for greater efficiency.

* Buy more RAM. If an old machine won't take more RAM, replace it with a slightly less-old machine.

That needs funds. Are you doing a donation for a new PC? :-p -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Peter Suetterlin

14:20

New subject: [opensuse-support] Re: Unresponsive desktop

Carlos E. R. wrote:

...

And, 42.3 did not exhibit this hanging problem, with the same load. Being slow is one thing, crashing is another.

It might not have been triggered. The problem itself is there if something is using more memory than RAM is installed. Been there, done that :P -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

19:24

New subject: [opensuse-support] Re: Unresponsive desktop

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2019-02-05 at 15:20 +0100, Peter Suetterlin wrote:

...

Carlos E. R. wrote:

...
And, 42.3 did not exhibit this hanging problem, with the same load. Being slow is one thing, crashing is another.

It might not have been triggered. The problem itself is there if something is using more memory than RAM is installed. Been there, done that :P

Yes, but Linux is prepared for that. I have used in the past (with SuSE) machines with 20 times more used memory than available RAM, swapping like hell. Yes, very slow, but more responsive with a Pentium V than this. It is some sort of race condition, the kernel doesn't manage to assign memory to the processes that need ram or some process is demanding unreasonable amounts. Maybe Firefox or Thunderbird or some unknown demands so much ram that the GUI starves. I have removed btrfsmaintenance package, same as I did on the laptop. No, I don't think it is because it triggereded now and not then. I use the same tools and in the same manner. Two different computers exhibit the same problem after being updated to 15.0, I think that is significative. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFni6hwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVeF4AnidUwGVUHmC+eMnHO/Pa TZ0J30e+AJ9QZsh6ZclMyE0igYfAIysBdv2Gng== =QuBo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Peter Suetterlin

14:13

New subject: [opensuse-support] Re: Unresponsive desktop

Liam Proven wrote:

...

On 2/3/19 2:33 PM, Carlos E. R. wrote:

...
I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

I would observe that RAM starvation seems to be the related to a number of your problems.

Might be, but the core issue is that the system behaves bad when running short of memory. You can easily trigger the behavior by having an application requesting more memory than physically available (though less than RAM+swap), and make (heavy) use of it so stuff gets permanently swapped in and out. For me it happens during image processing. The laptop now has 32GB. I still manage to trigger this if I'm not careful.... JFTR, the system is *not* crashed or dead, just totally unresponsive. One can wait until the heavy swap io is over, and the system will be normal again, without *any* notice in the logs. The proper solution is not to mute the symptoms by running less applications or buying more RAM (although it clearly helps). Somehow a desktop setup should have some sort of protection that makes sure at least the core GUI stuff doesn't get swapped out. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

9 Feb 9 Feb

04:34

New subject: [opensuse-support] Unresponsive desktop - more and accurate data captured

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2019-02-03 at 14:33 +0100, Carlos E. R. wrote:

...

Hi,

Last December I reported this problem on my laptop, and now my desktop also exhibits it.

After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

A week before it also froze, but that time I could not observe anything.

Well, it happened tonight and I got data: the culprit appears to be alsa, of all things. I was writing an email. I send it, then I think of seeing a google search I had clicked minutes before, and then I notice the mouse does not respond (nor the keyboard LEDs). I look on another computer that has an ssh open to this one, running top, and top is also frozen. Nevertheless, I type "k" to try kill something. On another tab, I try to open an ssh shell, but does not respond. Back to top, the "k" has responded and asks for the PID. I give the one for Firefox (for no reason, except that it is big ram). Typing is slow, one char per second. A few seconds later I notice that Thunderbird updates and the mouse is again responsive. Recovery! On a terminal, I was running "top -d 60 -b > top_01.log &" for days. I stop it and look at the log - 185M. This is the relevant part: Here think it was acting normal: top - 03:36:13 up 3 days, 13:42, 3 users, load average: 0,20, 0,39, 0,53 Tasks: 438 total, 2 running, 435 sleeping, 0 stopped, 1 zombie %Cpu(s): 9,2 us, 1,7 sy, 0,6 ni, 87,3 id, 1,2 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 457912 free, 6722988 used, 980500 buff/cache KiB Swap: 25165820 total, 20518908 free, 4646912 used. 930768 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5089 cer 20 0 3911352 1,224g 73108 167316 S 14,28 15,72 286:13.57 Web Content 4233 cer 20 0 10,501g 916988 218760 296076 S 7,042 11,24 248:14.02 firefox ... top - 03:37:13 up 3 days, 13:43, 3 users, load average: 0,51, 0,46, 0,55 Tasks: 433 total, 2 running, 430 sleeping, 0 stopped, 1 zombie %Cpu(s): 9,9 us, 1,7 sy, 0,6 ni, 86,7 id, 1,2 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 790104 free, 6544820 used, 826476 buff/cache KiB Swap: 25165820 total, 20515068 free, 4650752 used. 1128644 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5089 cer 20 0 3911352 1,085g 72988 167412 S 12,60 13,94 286:21.14 Web Content 4237 cer 20 0 4469680 989,6m 64872 415528 R 10,17 12,42 270:39.08 thunderbird-bin 4233 cer 20 0 10,515g 839364 196276 296368 S 5,992 10,28 248:17.62 firefox 5118 cer 20 0 4120348 989144 82060 401296 S 5,443 12,12 206:04.71 Web Content 4680 cer 39 19 2066432 17936 0 22908 S 2,730 0,220 141:46.84 tracker-extract 5910 root 20 0 56480 10888 2164 4844 S 2,480 0,133 119:53.00 iotop 5136 cer 20 0 2909700 798180 37236 274392 S 2,330 9,780 123:13.72 Web Content 3868 root 20 0 642944 138192 100996 21996 S 1,531 1,693 28:58.50 X 5041 cer 20 0 3449000 1,048g 22120 404768 S 1,431 13,47 76:04.77 Web Content 5871 cer 20 0 40396 804 0 248 S 0,599 0,010 29:51.17 top 11922 root 20 0 41584 968 172 256 S 0,549 0,012 29:41.31 top 4169 cer 9 -11 2479296 5276 3608 2408 S 0,350 0,065 34:27.52 pulseaudio 4234 cer 20 0 301208 6220 4112 13900 S 0,250 0,076 12:34.62 gkrellm 4324 cer 20 0 523528 15388 8264 15244 S 0,216 0,189 10:18.53 panel-6-weather 52 root 20 0 0 0 0 0 S 0,200 0,000 3:20.59 kswapd0 4330 cer 20 0 523268 15364 8388 13388 S 0,200 0,188 10:21.99 panel-14-weathe 4702 cer 20 0 732548 38432 72 3692 S 0,200 0,471 10:45.17 tracker-store 4196 cer 20 0 473192 5224 1768 9440 S 0,150 0,064 5:13.63 gvfs-udisks2-vo 4242 cer 20 0 738936 31148 8280 21180 S 0,067 0,382 4:18.89 xfce4-terminal 4322 cer 20 0 251216 2840 1952 15268 S 0,067 0,035 2:59.17 panel-23-multil 4181 cer 20 0 425860 11584 6560 15104 S 0,050 0,142 1:11.06 xfce4-panel I say it was normal here because each capture happened at the 13 second. The next one is delayed and kswapd0 is going mad: top - 03:39:26 up 3 days, 13:45, 3 users, load average: 61,19, 21,98, 8,28 Tasks: 436 total, 2 running, 433 sleeping, 0 stopped, 1 zombie %Cpu(s): 7,1 us, 12,7 sy, 0,3 ni, 13,9 id, 65,7 wa, 0,0 hi, 0,4 si, 0,0 st KiB Mem : 8161400 total, 117196 free, 7740016 used, 304188 buff/cache KiB Swap: 25165820 total, 20514556 free, 4651264 used. 20184 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 52 root 20 0 0 0 0 0 D 83,74 0,000 4:17.49 kswapd0 4237 cer 20 0 4491088 1,263g 10332 417144 D 29,80 16,22 270:59.33 thunderbird-bin 5118 cer 20 0 4137756 1,518g 36252 402496 D 17,35 19,50 206:16.50 Web Content 4233 cer 20 0 10,467g 865432 157420 296732 D 9,154 10,60 248:23.84 firefox 5089 cer 20 0 3911352 1,246g 23044 175308 D 5,151 16,01 286:24.64 Web Content 4680 cer 39 19 2066432 17936 0 22908 S 2,414 0,220 141:48.48 tracker-extract 5136 cer 20 0 2909700 767112 7208 274476 D 1,840 9,399 123:14.97 Web Content 5910 root 20 0 56480 8828 0 4808 D 1,413 0,108 119:53.96 iotop 2318 mysql 20 0 1887764 8052 0 63360 S 1,030 0,099 1:24.20 mysqld 5041 cer 20 0 3449000 1,026g 0 405020 D 0,986 13,18 76:05.44 Web Content 3868 root 20 0 636132 124360 86816 21944 D 0,898 1,524 28:59.11 X 6744 cer 20 0 4057688 69632 16 120816 S 0,824 0,853 2:10.61 java 3828 vscan 20 0 882152 0 0 628960 S 0,515 0,000 1:06.06 clamd 5871 cer 20 0 40396 1636 832 248 R 0,515 0,020 29:51.52 top 11922 root 20 0 41584 800 0 252 D 0,515 0,010 29:41.66 top 2307 named 20 0 532424 95288 0 99532 S 0,486 1,168 2:16.24 named 4169 cer 9 -11 2479296 2156 452 2376 S 0,368 0,026 34:27.77 pulseaudio 4234 cer 20 0 301208 2108 0 13900 D 0,309 0,026 12:34.83 gkrellm 4250 cer 20 0 1074168 20364 16 16208 D 0,309 0,250 1:01.59 konversation 4149 cer 20 0 240120 276 0 136 S 0,294 0,003 0:12.73 gpg-agent 4330 cer 20 0 523268 7296 356 13424 D 0,280 0,089 10:22.18 panel-14-weathe 4324 cer 20 0 523528 7504 332 15196 D 0,265 0,092 10:18.71 panel-6-weather 2929 ntp 20 0 53120 188 0 568 D 0,206 0,002 0:10.89 ntpd ... top - 03:40:42 up 3 days, 13:46, 3 users, load average: 57,19, 29,27, 11,83 Tasks: 433 total, 2 running, 430 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,1 us, 7,1 sy, 0,0 ni, 0,0 id, 92,3 wa, 0,0 hi, 0,5 si, 0,0 st KiB Mem : 8161400 total, 130404 free, 7719124 used, 311872 buff/cache KiB Swap: 25165820 total, 20509948 free, 4655872 used. 37236 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 52 root 20 0 0 0 0 0 S 12,26 0,000 4:34.80 kswapd0 4233 cer 20 0 10,436g 865072 157416 297044 D 0,489 10,60 248:24.53 firefox 4237 cer 20 0 4491088 1,265g 10332 418312 D 0,319 16,25 270:59.78 thunderbird-bin 2307 named 20 0 532424 95276 0 99544 S 0,262 1,167 2:16.61 named 5118 cer 20 0 4137756 1,517g 36252 403572 D 0,227 19,49 206:16.82 Web Content 6744 cer 20 0 4057688 69364 16 121084 S 0,212 0,850 2:10.91 java 2318 mysql 20 0 1887764 8052 0 63360 S 0,205 0,099 1:24.49 mysqld 4250 cer 20 0 1074168 20364 16 16208 D 0,149 0,250 1:01.80 konversation 3868 root 20 0 636132 124808 87176 21864 S 0,120 1,529 28:59.28 X 5089 cer 20 0 3911352 1,244g 23044 177360 D 0,120 15,99 286:24.81 Web Content 1 root 20 0 158452 3004 0 772 D 0,113 0,037 1:03.57 systemd 5136 cer 20 0 2909700 766300 7208 275288 D 0,113 9,389 123:15.13 Web Content 5871 cer 20 0 40396 804 0 248 R 0,113 0,010 29:51.68 top 4686 cer 39 19 936648 44816 4 12380 D 0,106 0,549 1:44.15 tracker-miner-f 5041 cer 20 0 3449000 1,026g 0 405288 D 0,106 13,18 76:05.59 Web Content 4234 cer 20 0 301208 2108 0 13900 D 0,085 0,026 12:34.95 gkrellm 4315 cer 20 0 710624 3976 44 15404 S 0,085 0,049 2:44.29 panel-19-pulsea 4322 cer 20 0 251216 1012 44 15188 D 0,085 0,012 2:59.43 panel-23-multil 4772 cer 20 0 463636 6232 0 15788 S 0,078 0,076 0:54.68 contarcorreo 11922 root 20 0 41584 828 0 224 S 0,078 0,010 29:41.77 top 4169 cer 9 -11 2479296 2136 432 2376 S 0,071 0,026 34:27.87 pulseaudio 663 root 20 0 82288 5740 5396 456 D 0,064 0,070 0:44.02 systemd-journal and back to normal after killing firefox: top - 03:41:43 up 3 days, 13:47, 4 users, load average: 24,51, 25,39, 11,62 Tasks: 427 total, 1 running, 425 sleeping, 0 stopped, 1 zombie %Cpu(s): 2,9 us, 2,2 sy, 0,8 ni, 80,3 id, 13,6 wa, 0,0 hi, 0,2 si, 0,0 st KiB Mem : 8161400 total, 5307944 free, 2265236 used, 588220 buff/cache KiB Swap: 25165820 total, 22424060 free, 2741760 used. 5610332 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 4237 cer 20 0 4490112 1,297g 41488 418224 S 5,156 16,67 271:02.92 thunderbird-bin 4680 cer 39 19 2066432 20592 2652 22904 S 2,709 0,252 141:50.13 tracker-extract 52 root 20 0 0 0 0 0 S 2,512 0,000 4:36.33 kswapd0 5910 root 20 0 56480 13328 4472 4792 S 1,839 0,163 119:55.16 iotop 3868 root 20 0 507876 78808 41164 21852 S 0,821 0,966 28:59.78 X 4169 cer 9 -11 1430364 6500 4696 2276 S 0,624 0,080 34:28.25 pulseaudio 5871 cer 20 0 40396 900 96 248 S 0,575 0,011 29:52.03 top 11922 root 20 0 41584 984 156 224 S 0,542 0,012 29:42.10 top 4196 cer 20 0 473192 7124 3676 9464 S 0,509 0,087 5:13.94 gvfs-udisks2-vo 4702 cer 20 0 732548 44488 6116 3660 S 0,296 0,545 10:45.47 tracker-store 4234 cer 20 0 301208 10440 8332 13900 S 0,230 0,128 12:35.09 gkrellm 4242 cer 20 0 738936 32448 9312 20916 S 0,230 0,398 4:19.09 xfce4-terminal 2307 named 20 0 532424 95276 0 99544 S 0,197 1,167 2:16.73 named 23937 cer 20 0 21484 11452 3368 0 S 0,197 0,140 0:00.12 bash 4330 cer 20 0 523268 13144 6208 13428 S 0,181 0,161 10:22.38 panel-14-weathe 4207 cer 20 0 775472 49928 16244 14340 S 0,164 0,612 0:36.44 xfdesktop 4324 cer 20 0 523528 13480 6316 15204 S 0,164 0,165 10:18.90 panel-6-weather 1 root 20 0 240380 7116 3984 688 S 0,115 0,087 1:03.64 systemd 5907 cer 20 0 217984 7020 3144 8828 S 0,115 0,086 0:46.97 dirmngr 663 root 20 0 82592 8028 7416 428 S 0,099 0,098 0:44.08 systemd-journal 4315 cer 20 0 710624 8924 4956 15368 S 0,099 0,109 2:44.35 panel-19-pulsea 4250 cer 20 0 1074168 27412 7064 16208 S 0,082 0,336 1:01.85 konversation 6744 cer 20 0 4057688 69368 16 121080 S 0,082 0,850 2:10.96 java So the issue happened betwen 03:37:13 and 03:39:26 hours. As the 3:38:13 entry is missing, at that moment things were already wrong. Let's go see syslog - as this time I was sitting there and killed something, it is properly registered. This is postfix sending an email, everything normal: <22>1 2019-02-09T03:37:27.328452+01:00 Telcontar postfix 23861 - - A584E3209C9: to=<...@opensuse.org>, relay=mail.gmx.es ... status=sent (250 Requested mail action okay, completed: id=...) <22>1 2019-02-09T03:37:27.330347+01:00 Telcontar postfix 23861 - - > mail.gmx.es[212.227.17.184]:25: QUIT <22>1 2019-02-09T03:37:27.330518+01:00 Telcontar postfix 23861 - - name_mask: resource <22>1 2019-02-09T03:37:27.331005+01:00 Telcontar postfix 23861 - - name_mask: software <22>1 2019-02-09T03:37:27.385482+01:00 Telcontar postfix 23861 - - disposing SASL state information <22>1 2019-02-09T03:37:27.385789+01:00 Telcontar postfix 3974 - - A584E3209C9: removed <39>1 2019-02-09T03:37:34.187629+01:00 Telcontar gcr-prompter 23840 - - 10 second inactivity timeout, quitting <39>1 2019-02-09T03:37:34.187844+01:00 Telcontar gcr-prompter 23840 - - Gcr: unregistering prompter <39>1 2019-02-09T03:37:34.190225+01:00 Telcontar gcr-prompter 23840 - - Gcr: disposing prompter <39>1 2019-02-09T03:37:34.190251+01:00 Telcontar gcr-prompter 23840 - - Gcr: finalizing prompter Here definitely things are going bad (no edited lines here), but we know it started earlier, before 3:38:13 and after 3:37:27 - the gcr-prompter entry above may be suspicious, but the alsa entries below definitely indicate a problem: <30>1 2019-02-09T03:39:04.102993+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 4553784 bytes (25815 ms). <30>1 2019-02-09T03:40:01.963938+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. <30>1 2019-02-09T03:40:29.388806+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: snd_pcm_dump(): <30>1 2019-02-09T03:40:38.256922+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Soft volume PCM <30>1 2019-02-09T03:40:47.447909+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Control: PCM Playback Volume <30>1 2019-02-09T03:40:49.856184+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: min_dB: -51 <30>1 2019-02-09T03:40:49.931352+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: max_dB: 0 <30>1 2019-02-09T03:40:49.931597+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: resolution: 256 <30>1 2019-02-09T03:40:49.931769+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Its setup is: <30>1 2019-02-09T03:40:49.931930+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stream : PLAYBACK <30>1 2019-02-09T03:40:49.932090+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: access : MMAP_INTERLEAVED <30>1 2019-02-09T03:40:49.932249+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: format : S16_LE <30>1 2019-02-09T03:40:49.932408+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: subformat : STD <30>1 2019-02-09T03:40:49.932566+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: channels : 2 <30>1 2019-02-09T03:40:49.932734+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: rate : 44100 <30>1 2019-02-09T03:40:49.932893+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: exact rate : 44100 (44100/1) <30>1 2019-02-09T03:40:49.933052+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: msbits : 16 <30>1 2019-02-09T03:40:49.933222+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: buffer_size : 88192 <30>1 2019-02-09T03:40:49.933396+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_size : 44096 <30>1 2019-02-09T03:40:49.933559+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_time : 999909 <30>1 2019-02-09T03:40:49.933717+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_mode : ENABLE <30>1 2019-02-09T03:40:49.933876+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_type : MONOTONIC <30>1 2019-02-09T03:40:49.934035+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_step : 1 <30>1 2019-02-09T03:40:49.934194+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: avail_min : 84401 <30>1 2019-02-09T03:40:49.934352+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_event : 0 <30>1 2019-02-09T03:40:49.934511+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: start_threshold : -1 <30>1 2019-02-09T03:40:49.934676+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stop_threshold : 6205960286516543488 <30>1 2019-02-09T03:40:49.934841+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_threshold: 0 <30>1 2019-02-09T03:40:49.934999+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_size : 0 <30>1 2019-02-09T03:40:49.935157+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: boundary : 6205960286516543488 <30>1 2019-02-09T03:40:49.935316+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Slave: Hardware PCM card 0 'HDA Creative' device 0 subdevice 0 <30>1 2019-02-09T03:40:49.935560+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Its setup is: <30>1 2019-02-09T03:40:49.935724+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stream : PLAYBACK <30>1 2019-02-09T03:40:49.935886+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: access : MMAP_INTERLEAVED <30>1 2019-02-09T03:40:49.936044+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: format : S16_LE <30>1 2019-02-09T03:40:49.936202+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: subformat : STD <30>1 2019-02-09T03:40:49.936361+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: channels : 2 <30>1 2019-02-09T03:40:49.936524+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: rate : 44100 <30>1 2019-02-09T03:40:50.047919+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: exact rate : 44100 (44100/1) <30>1 2019-02-09T03:40:50.048217+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: msbits : 16 <30>1 2019-02-09T03:40:50.048390+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: buffer_size : 88192 <30>1 2019-02-09T03:40:50.048549+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_size : 44096 <30>1 2019-02-09T03:40:50.048708+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_time : 999909 <30>1 2019-02-09T03:40:50.048866+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_mode : ENABLE <30>1 2019-02-09T03:40:50.049029+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_type : MONOTONIC <30>1 2019-02-09T03:40:50.049189+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_step : 1 <30>1 2019-02-09T03:40:50.049347+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: avail_min : 84401 <30>1 2019-02-09T03:40:50.049505+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_event : 0 <30>1 2019-02-09T03:40:50.049662+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: start_threshold : -1 <30>1 2019-02-09T03:40:50.049919+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stop_threshold : 6205960286516543488 <30>1 2019-02-09T03:40:50.050079+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_threshold: 0 <30>1 2019-02-09T03:40:50.050237+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_size : 0 <30>1 2019-02-09T03:40:50.050400+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: boundary : 6205960286516543488 <30>1 2019-02-09T03:40:50.050571+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: appl_ptr : 12514060050 <30>1 2019-02-09T03:40:50.050729+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: hw_ptr : 12515110304 <30>1 2019-02-09T03:40:50.050892+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: snd_pcm_delay() returned a value that is exceptionally large: -26371280 bytes (-149497 ms). <30>1 2019-02-09T03:40:50.051052+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. <30>1 2019-02-09T03:40:50.051261+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: snd_pcm_dump(): <30>1 2019-02-09T03:40:50.051431+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Soft volume PCM <30>1 2019-02-09T03:40:50.051589+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Control: PCM Playback Volume <30>1 2019-02-09T03:40:50.051747+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: min_dB: -51 <30>1 2019-02-09T03:40:50.051909+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: max_dB: 0 <30>1 2019-02-09T03:40:50.052067+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: resolution: 256 <30>1 2019-02-09T03:40:50.052230+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Its setup is: <30>1 2019-02-09T03:40:50.052394+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stream : PLAYBACK <30>1 2019-02-09T03:40:50.052557+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: access : MMAP_INTERLEAVED <30>1 2019-02-09T03:40:50.052716+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: format : S16_LE <30>1 2019-02-09T03:40:50.052875+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: subformat : STD <30>1 2019-02-09T03:40:50.053033+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: channels : 2 <30>1 2019-02-09T03:40:50.053191+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: rate : 44100 <30>1 2019-02-09T03:40:50.053349+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: exact rate : 44100 (44100/1) <30>1 2019-02-09T03:40:50.053512+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: msbits : 16 <30>1 2019-02-09T03:40:50.053670+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: buffer_size : 88192 <30>1 2019-02-09T03:40:50.053828+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_size : 44096 <30>1 2019-02-09T03:40:50.053987+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_time : 999909 <30>1 2019-02-09T03:40:50.054146+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_mode : ENABLE <30>1 2019-02-09T03:40:50.054305+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_type : MONOTONIC <30>1 2019-02-09T03:40:50.054476+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_step : 1 <30>1 2019-02-09T03:40:50.054635+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: avail_min : 84401 <30>1 2019-02-09T03:40:50.054801+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_event : 0 <30>1 2019-02-09T03:40:50.054959+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: start_threshold : -1 <30>1 2019-02-09T03:40:50.055117+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stop_threshold : 6205960286516543488 <30>1 2019-02-09T03:40:50.055275+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_threshold: 0 <30>1 2019-02-09T03:40:50.055456+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_size : 0 <30>1 2019-02-09T03:40:50.055615+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: boundary : 6205960286516543488 <30>1 2019-02-09T03:40:50.055773+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Slave: Hardware PCM card 0 'HDA Creative' device 0 subdevice 0 <30>1 2019-02-09T03:40:50.081352+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Its setup is: <30>1 2019-02-09T03:40:50.081608+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stream : PLAYBACK <30>1 2019-02-09T03:40:50.081768+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: access : MMAP_INTERLEAVED <30>1 2019-02-09T03:40:50.081927+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: format : S16_LE <30>1 2019-02-09T03:40:50.082085+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: subformat : STD <30>1 2019-02-09T03:40:50.082243+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: channels : 2 <30>1 2019-02-09T03:40:50.082400+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: rate : 44100 <30>1 2019-02-09T03:40:50.082557+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: exact rate : 44100 (44100/1) <30>1 2019-02-09T03:40:50.082714+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: msbits : 16 <30>1 2019-02-09T03:40:50.082871+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: buffer_size : 88192 <30>1 2019-02-09T03:40:50.083034+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_size : 44096 <30>1 2019-02-09T03:40:50.083192+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_time : 999909 <30>1 2019-02-09T03:40:50.083349+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_mode : ENABLE <30>1 2019-02-09T03:40:50.083537+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_type : MONOTONIC <30>1 2019-02-09T03:40:50.083703+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_step : 1 <30>1 2019-02-09T03:40:50.083862+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: avail_min : 84401 <30>1 2019-02-09T03:40:50.084019+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_event : 0 <30>1 2019-02-09T03:40:50.084177+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: start_threshold : -1 <30>1 2019-02-09T03:40:50.084337+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stop_threshold : 6205960286516543488 <30>1 2019-02-09T03:40:50.084501+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_threshold: 0 <30>1 2019-02-09T03:40:50.084665+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_size : 0 <30>1 2019-02-09T03:40:50.084824+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: boundary : 6205960286516543488 <30>1 2019-02-09T03:40:50.084981+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: appl_ptr : 12514102116 <30>1 2019-02-09T03:40:50.085140+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: hw_ptr : 12520694936 <4>1 2019-02-09T03:40:50.580980+01:00 Telcontar kernel - - - [308811.279237] show_signal_msg: 45 callbacks suppressed <6>1 2019-02-09T03:40:50.580996+01:00 Telcontar kernel - - - [308811.279240] Chrome_~dThread[5139]: segfault at 0 ip 00007fe7cca17cd3 sp 00007fe7c987bb10 error 6 in libxul.so[7fe7cc4fd000+5874000] <6>1 2019-02-09T03:40:50.596756+01:00 Telcontar kernel - - - [308811.303156] Socket Thread[5100]: segfault at 0 ip 0000560342364c51 sp 00007f9566efe670 error 6 in firefox[56034235f000+31000] <6>1 2019-02-09T03:40:50.618242+01:00 Telcontar kernel - - - [308811.324121] Cameras IPC[9191]: segfault at 0 ip 000055c3285a8c51 sp 00007f9ade5fd8b0 error 6 in firefox[55c3285a3000+31000] <6>1 2019-02-09T03:40:50.683429+01:00 Telcontar kernel - - - [308811.390212] Chrome_~dThread[5044]: segfault at 0 ip 00007fef1d717cd3 sp 00007fef1a57bb10 error 6 in libxul.so[7fef1d1fd000+5874000] <30>1 2019-02-09T03:40:51.102534+01:00 Telcontar systemd 1 - - Created slice User Slice of news. <30>1 2019-02-09T03:40:51.103841+01:00 Telcontar systemd 1 - - Starting User Manager for UID 9... <30>1 2019-02-09T03:40:51.104264+01:00 Telcontar systemd 1 - - Created slice system-systemd\x2dcoredump.slice. <30>1 2019-02-09T03:40:51.147417+01:00 Telcontar systemd 1 - - Started Process Core Dump (PID 23890/UID 0). <30>1 2019-02-09T03:40:51.149551+01:00 Telcontar systemd 1 - - Started Process Core Dump (PID 23888/UID 0). <86>1 2019-02-09T03:40:51.156209+01:00 Telcontar systemd - - - pam_unix(systemd-user:session): session opened for user news by (uid=0) <30>1 2019-02-09T03:40:51.156952+01:00 Telcontar systemd 1 - - Started Process Core Dump (PID 23887/UID 0). <30>1 2019-02-09T03:40:51.163051+01:00 Telcontar systemd 1 - - Started Process Core Dump (PID 23889/UID 0). <30>1 2019-02-09T03:40:51.173282+01:00 Telcontar systemd 1 - - Started Session 1722 of user news. <30>1 2019-02-09T03:40:51.180118+01:00 Telcontar systemd 1 - - Started Session 1721 of user cer. <86>1 2019-02-09T03:40:51.186204+01:00 Telcontar cron 23880 - - pam_unix(crond:session): session opened for user cer by (uid=0) <30>1 2019-02-09T03:40:51.275496+01:00 Telcontar systemd-coredump 23896 - - Resource limits disable core dumping for process 5136 (Web Content). <10>1 2019-02-09T03:40:51.288537+01:00 Telcontar systemd-coredump 23896 - - Process 5136 (Web Content) of user 1000 dumped core. <30>1 2019-02-09T03:40:51.294905+01:00 Telcontar systemd-coredump 23894 - - Resource limits disable core dumping for process 5041 (Web Content). <10>1 2019-02-09T03:40:51.295785+01:00 Telcontar systemd-coredump 23894 - - Process 5041 (Web Content) of user 1000 dumped core. <30>1 2019-02-09T03:40:51.306329+01:00 Telcontar systemd-coredump 23898 - - Resource limits disable core dumping for process 5118 (Web Content). <10>1 2019-02-09T03:40:51.306830+01:00 Telcontar systemd-coredump 23898 - - Process 5118 (Web Content) of user 1000 dumped core. <30>1 2019-02-09T03:40:51.308720+01:00 Telcontar systemd-coredump 23895 - - Resource limits disable core dumping for process 5089 (Web Content). <10>1 2019-02-09T03:40:51.309167+01:00 Telcontar systemd-coredump 23895 - - Process 5089 (Web Content) of user 1000 dumped core. <30>1 2019-02-09T03:40:51.379583+01:00 Telcontar systemd 1 - - Started User Manager for UID 9. <86>1 2019-02-09T03:40:51.380313+01:00 Telcontar cron 23881 - - pam_unix(crond:session): session opened for user news by (uid=0) <63>1 2019-02-09T03:40:51.517680+01:00 Telcontar fetchnews 23921 - - config: debugmode is 1 <63>1 2019-02-09T03:40:51.517970+01:00 Telcontar fetchnews 23921 - - config: maxfetch is 5000 <63>1 2019-02-09T03:40:51.517993+01:00 Telcontar fetchnews 23921 - - config: maxage is 0 <63>1 2019-02-09T03:40:51.518051+01:00 Telcontar fetchnews 23921 - - config: postings have max. 500000 bytes <63>1 2019-02-09T03:40:51.518074+01:00 Telcontar fetchnews 23921 - - config: timeout_long is 100 days <63>1 2019-02-09T03:40:51.518095+01:00 Telcontar fetchnews 23921 - - config: timeout_fetchnews is 90 seconds <63>1 2019-02-09T03:40:51.518115+01:00 Telcontar fetchnews 23921 - - config: newsadmin is postmaster@telcontar.valinor <63>1 2019-02-09T03:40:51.518136+01:00 Telcontar fetchnews 23921 - - config: allow_8bit_headers is 1 <86>1 2019-02-09T03:40:52.037118+01:00 Telcontar CRON 23880 - - pam_unix(crond:session): session closed for user cer <63>1 2019-02-09T03:40:54.518456+01:00 Telcontar fetchnews 23921 - - leafnode 1.11.11: verbosity level is 2, debugmode is 1 <63>1 2019-02-09T03:40:54.518488+01:00 Telcontar fetchnews 23921 - - try_lock(timeout=5), fqdn="Telcontar.valinor" <63>1 2019-02-09T03:40:54.707342+01:00 Telcontar fetchnews 23921 - - Last LIST done 1666132 seconds ago: NEWGROUPS <63>1 2019-02-09T03:40:54.831086+01:00 Telcontar fetchnews 23921 - - <200 The server welcomes 208.red-83-32-232.dynamicip.rima-tde.net (83.32.232.208). Authorization required for reading and posting. <62>1 2019-02-09T03:40:54.831118+01:00 Telcontar fetchnews 23921 - - News.Individual.NET: connected to 130.133.4.11:119, reply: 200 <63>1 2019-02-09T03:40:54.831480+01:00 Telcontar fetchnews 23921 - - >AUTHINFO USER robinson <63>1 2019-02-09T03:40:54.892724+01:00 Telcontar fetchnews 23921 - - <381 PASS required <63>1 2019-02-09T03:40:54.892755+01:00 Telcontar fetchnews 23921 - - >AUTHINFO PASS <password not shown> things are back to normal here, as the nntp daemon is starting a fetch loop normally. Telcontar:~ # coredumpctl TIME PID UID GID SIG COREFILE EXE Sat 2019-02-09 03:40:51 CET 5136 1000 100 11 none /usr/lib64/firefox/firefox Sat 2019-02-09 03:40:51 CET 5041 1000 100 11 none /usr/lib64/firefox/firefox Sat 2019-02-09 03:40:51 CET 5118 1000 100 11 none /usr/lib64/firefox/firefox Sat 2019-02-09 03:40:51 CET 5089 1000 100 11 none /usr/lib64/firefox/firefox Telcontar:~ # No coredump files, sorry (I don't remember if I disabled them or it is a system limit not my doing). dmesg -e log has almost nothing registered: [Feb 9 02:51] usb 4-2: USB disconnect, device number 3 [Feb 9 03:41] show_signal_msg: 45 callbacks suppressed [ +0,000003] Chrome_~dThread[5139]: segfault at 0 ip 00007fe7cca17cd3 sp 00007fe7c987bb10 error 6 in libxul.so[7fe7cc4fd000+5874000] [ +0,023916] Socket Thread[5100]: segfault at 0 ip 0000560342364c51 sp 00007f9566efe670 error 6 in firefox[56034235f000+31000] [ +0,020965] Cameras IPC[9191]: segfault at 0 ip 000055c3285a8c51 sp 00007f9ade5fd8b0 error 6 in firefox[55c3285a3000+31000] [ +0,066091] Chrome_~dThread[5044]: segfault at 0 ip 00007fef1d717cd3 sp 00007fef1a57bb10 error 6 in libxul.so[7fef1d1fd000+5874000] cer@Telcontar:~> There are some strange lines above: <4>1 2019-02-09T03:40:50.580980+01:00 Telcontar kernel - - - [308811.279237] show_signal_msg: 45 callbacks suppressed <6>1 2019-02-09T03:40:50.580996+01:00 Telcontar kernel - - - [308811.279240] Chrome_~dThread[5139]: segfault at 0 ip 00007fe7cca17cd3 sp 0000 <6>1 2019-02-09T03:40:50.596756+01:00 Telcontar kernel - - - [308811.303156] Socket Thread[5100]: segfault at 0 ip 0000560342364c51 sp 00007f <6>1 2019-02-09T03:40:50.618242+01:00 Telcontar kernel - - - [308811.324121] Cameras IPC[9191]: segfault at 0 ip 000055c3285a8c51 sp 00007f9a <6>1 2019-02-09T03:40:50.683429+01:00 Telcontar kernel - - - [308811.390212] Chrome_~dThread[5044]: segfault at 0 ip 00007fef1d717cd3 sp 0000 Chrome? I don't remember having Chrome running. I may have started it once to check something, but it should have been exited. Cameras IPC? No idea what is that. My "top" log doesn't show any "chrome" process except this one much earlier, and none afterwards: top - 10:37:54 up 1 day, 20:43, 3 users, load average: 2,05, 1,44, 0,91 ... 10299 cer 20 0 293572 21076 384 0 S 0,000 0,258 0:00.35 chrome-gnome-sh So, what do you think? The system is running, I can do tests. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXF5YYhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVm80AoI8J4x3Q6MvDSE1/4Wmx VwCqBKgbAJoCTCYcCViGl35P8WhE5KOaDavXMA== =5td3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Peter Suetterlin

11 Feb 11 Feb

11:39

New subject: [opensuse-support] Unresponsive desktop - more and accurate data captured

Carlos E. R. wrote:

...

So, what do you think?

Two things came to my mind looking at those: - I first suspected thunderbird, as it was at higher load than firefox, but then realized that of course a process waiting for swap IO won't use too much CPU... - I don't think alsa is the cause. The messages you get are rather a consequence, as audio is extremely timing critical, and is also affected by the general slowness. I did see similar in my cases of hitting the swap deathmill: Sound started stuttering, until it would eventually stop completely. But it came back once swapping stopped. Maybe not too enlightening, but all I can come up with. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

19:41

New subject: [opensuse-support] Unresponsive desktop - more and accurate data captured

On 11/02/2019 12.39, Peter Suetterlin wrote:

...

Carlos E. R. wrote:

...
So, what do you think?

Two things came to my mind looking at those:

- I first suspected thunderbird, as it was at higher load than firefox, but then realized that of course a process waiting for swap IO won't use too much CPU...

Right. And that top runs once per minute - possibly the thing tells the average of the minute, or perhaps just that instant.

...

- I don't think alsa is the cause. The messages you get are rather a consequence, as audio is extremely timing critical, and is also affected by the general slowness.

It is certainly probable.

...

I did see similar in my cases of hitting the swap deathmill: Sound started stuttering, until it would eventually stop completely. But it came back once swapping stopped.

Maybe not too enlightening, but all I can come up with.

Thanks. I think I will report in bugzilla what I know, and try to update to the tumbleweed kernel. Unless someone knows some command to try when it crashes to obtain more info, and I write it in a postit... Maybe log iotop output as well. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

Christian Boltz

10 Feb 10 Feb

15:35

Hello, Am Sonntag, 3. Februar 2019, 14:33:24 CET schrieb Carlos E. R.:

...

After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

It's probably not the answer you are looking for, but I'll propose it nevertheless: Disable your swap. Obviously that means that you'll have less "memory" available, but IMHO that has some advantages: - you avoid the "swap to death" situation (freezing the system while swapping) - programs eating up RAM get killed earlier, and you get an OOM killer log entry that tells you which process ate too much RAM Personally, I don't use swap since years [1], and I'm completely happy with it. I remember a few rare cases where a program ate up memory and was killed, but the alternative would have been to let it swap, fill the swap, and then being killed - after freezing the system (aka "swap to death") for a while ;-) Regards, Christian Boltz [1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running -- Aber was macht [KDE] bei mir? Es zeigt xterms und Hintergrundbilder an. Aus meiner Sicht ist letzteres die Funktion, die es am besten beherrscht. Sehr schöne Bilder sind das. [Lars Müller in opensuse-de] -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

11 Feb 11 Feb

08:30

On 10/02/2019 16.35, Christian Boltz wrote:

...

Hello,

Am Sonntag, 3. Februar 2019, 14:33:24 CET schrieb Carlos E. R.:

...
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.

It's probably not the answer you are looking for, but I'll propose it nevertheless:

Disable your swap.

Not viable. This minute I have 5 GB of swap in use. Without swap, the system would simple not work, several programs I use would be killed.

...

[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running

But I have only 8. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)