On 7/31/23 09:49, William Unruh wrote:
> On 2023-07-30, J.O. Aho <user@example.net> wrote:
>> On 7/30/23 19:59, William Unruh wrote:

> ...
>
>>>
>>> How much ram do you have?
>>
>> 64GB, I used to have 32, but I ran into the issue and I was hoping that
>> doubling the amount of RAM should make it less affecting, gosh I was wrong.
>
> I have 8 GB. ps says plasmashell right now has VSZ of 1.9GB and %MEM of
> 3.1% ( which sould be 250MB I guess.

Then your plasmashell is using 250MB at the moment, the VSZ is a in
theory amount of RAM the process would use if it had to load everything
at once, but as you ain't using all the features of plasmahsell this
will not happen.

The RSS amount will include all the memory dependencies may use like
libraries, as most libraries in Linux are shared, then the same shared
library can be reported multiple times (once in each process that uses
it), this applies to the %MEM too.

If your %MEM reaches 25%, then it will use like 2GB mem and the RSS will
also give you something in that region too +/- something as it's more
accurate value than %MEM.

>> If you had been a hour earlier, I think you would maybe caught the
>> slowdown, as it's related to the amount of free RAM you have left, when
>> you don't it's the freeze time.
>
> I have about 8GB of swap, so it should slow down when it starts to use
> swap.

Depends on what has been swapped out, if it's just things that are
seldom used (say hibernated tabs in your browser), then you will not
notice anything until you load a such tab. The issue is when it start
swap in and out data that it's needing, this will lead to that the disk
light will blink really rapidly and everything goes extremely slowly or
seems to have frozen.

"J.O. Aho" <user@example.net> writes:
> Then your plasmashell is using 250MB at the moment, the VSZ is a in
> theory amount of RAM the process would use if it had to load
> everything at once, but as you ain't using all the features of
> plasmahsell this will not happen.

On a 64-bit Linux, VSZ is often way more than the RAM a process could
possibly use. Each shared library has a 2MB PROT_NONE mapping that
contributes to VSZ but can never consume any RAM, and GUI processses
often have huge numbers of shared libraries so this can easily reach
into the hundreds of megabytes.

See https://www.greenend.org.uk/rjk/tech/dataseg.html for discussion.

--
https://www.greenend.org.uk/rjk/

On 2023-07-31 at 04:11 ADT, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Jim Diamond <JimDiamond@jdvb.ca> writes:
>> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>>> How much ram do you have?
>>> Mu plasmashell right now is 2GB VSZ
>>
>> I don't think the VSZ is all that significant.
>
> Indeed VSZ tells you very little - for instance it includes a 2MB dead
> page in the middle of every shared library, which (in a complex process)
> scales up VSZ to something huge, but consumes almost no real resources.
>
>> What is the RSS?
>
> I think the theories about user space memory leaks are a red herring.
> The reported behavior is just not consistent with them.
>

I have not followed the thread too closely, but I suspect you are right.

But when I saw someone reporting VSZ, I thought that they should know that
it wasn't meaningful, just in case they keep barking up that tree.

Cheers.
Jim

On 2023-07-31, Jim Diamond <JimDiamond@jdvb.ca> wrote:
> On 2023-07-31 at 04:11 ADT, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Jim Diamond <JimDiamond@jdvb.ca> writes:
>>> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>>>> How much ram do you have?
>>>> Mu plasmashell right now is 2GB VSZ
>>>
>>> I don't think the VSZ is all that significant.
>>
>> Indeed VSZ tells you very little - for instance it includes a 2MB dead
>> page in the middle of every shared library, which (in a complex process)
>> scales up VSZ to something huge, but consumes almost no real resources.
>>
>>> What is the RSS?
>>
>> I think the theories about user space memory leaks are a red herring.
>> The reported behavior is just not consistent with them.
>>
>
> I have not followed the thread too closely, but I suspect you are right.
>
> But when I saw someone reporting VSZ, I thought that they should know that
> it wasn't meaningful, just in case they keep barking up that tree.

Yes, thanks for that. VSZ seemed much to large to be reasonable. but I
could not see anything else in the ps aux report that could be the
actual memory used (except %MEM and what it was a percentage of I had no
idea.)

On 7/31/2023 12:47 PM, William Unruh wrote:
> On 2023-07-31, Jim Diamond <JimDiamond@jdvb.ca> wrote:
>> On 2023-07-31 at 04:11 ADT, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> Jim Diamond <JimDiamond@jdvb.ca> writes:
>>>> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>>>>> How much ram do you have?
>>>>> Mu plasmashell right now is 2GB VSZ
>>>>
>>>> I don't think the VSZ is all that significant.
>>>
>>> Indeed VSZ tells you very little - for instance it includes a 2MB dead
>>> page in the middle of every shared library, which (in a complex process)
>>> scales up VSZ to something huge, but consumes almost no real resources.
>>>
>>>> What is the RSS?
>>>
>>> I think the theories about user space memory leaks are a red herring.
>>> The reported behavior is just not consistent with them.
>>>
>>
>> I have not followed the thread too closely, but I suspect you are right.
>>
>> But when I saw someone reporting VSZ, I thought that they should know that
>> it wasn't meaningful, just in case they keep barking up that tree.
>
> Yes, thanks for that. VSZ seemed much to large to be reasonable. but I
> could not see anything else in the ps aux report that could be the
> actual memory used (except %MEM and what it was a percentage of I had no
> idea.)
>

Only you know the particulars of your system.

You say you're using Plasma, and "plasma freezes" shows in Google searches.

If you were to note a rising RAM consumption (say, leave top running
when freeze occurs), in the example here, one post mentions
it is possible it's a video card driver issue. The graphics stack
is producing frames, but there is no consumer.

https://bugzilla.redhat.com/show_bug.cgi?id=1399396

In some cases, the NVidia driver has watchdog enabled, the Nouveau
does not. This makes the Nvidia driver capable of doing a VPU recover,
and restoring service before it is too late.

Paul

On 2023-08-01, Paul <nospam@needed.invalid> wrote:
> On 7/31/2023 12:47 PM, William Unruh wrote:
>> On 2023-07-31, Jim Diamond <JimDiamond@jdvb.ca> wrote:
>>> On 2023-07-31 at 04:11 ADT, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> Jim Diamond <JimDiamond@jdvb.ca> writes:
>>>>> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>>>>>> How much ram do you have?
>>>>>> Mu plasmashell right now is 2GB VSZ
>>>>>
>>>>> I don't think the VSZ is all that significant.
>>>>
>>>> Indeed VSZ tells you very little - for instance it includes a 2MB dead
>>>> page in the middle of every shared library, which (in a complex process)
>>>> scales up VSZ to something huge, but consumes almost no real resources.
>>>>
>>>>> What is the RSS?
>>>>
>>>> I think the theories about user space memory leaks are a red herring.
>>>> The reported behavior is just not consistent with them.
>>>>
>>>
>>> I have not followed the thread too closely, but I suspect you are right.
>>>
>>> But when I saw someone reporting VSZ, I thought that they should know that
>>> it wasn't meaningful, just in case they keep barking up that tree.
>>
>> Yes, thanks for that. VSZ seemed much to large to be reasonable. but I
>> could not see anything else in the ps aux report that could be the
>> actual memory used (except %MEM and what it was a percentage of I had no
>> idea.)
>>
>
> Only you know the particulars of your system.
>
> You say you're using Plasma, and "plasma freezes" shows in Google searches.

As I said it is not just plasma that freezes but the whole system. I
cannot log in via ssh on the network, no keyboard entry works (eb
alt-ctrl-del does not reboot the system), no mouse cursor moves when I
more themouse. In the past ( ie over a year ago) when this happened,
there was no precursor. The system did not slow down. before hand. I
know what swapping feels like, and there was no evidence of that. (I
have as much swap space as I have ram, about 8GB each)

>
> If you were to note a rising RAM consumption (say, leave top running
> when freeze occurs), in the example here, one post mentions

The freeze occurs randomly about once every month or so (or rather I
have had two in the past 2 months and none from last Aug to that time)

> it is possible it's a video card driver issue. The graphics stack
> is producing frames, but there is no consumer.

I have an onboard Intel graphics.
lspci says
00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630]
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1399396
>
> In some cases, the NVidia driver has watchdog enabled, the Nouveau
> does not. This makes the Nvidia driver capable of doing a VPU recover,
> and restoring service before it is too late.

I have a disturbing system, which every once in a while freezes. The
sceen on the monitor is some X scene (usually has Chrome running, but
they again that is often the case) but the keyboard,mouse, do nothing.
Trying to log on from the network fails with no response from the
machine. Alt-ctrl-del does nothing. The only way to recover is via the
power switch on the back.
Afterwards, looking at /var/log/syslog, or /var/log/messages shows
nothingsignificant that I can see just before the freeze.

Updated Mga8. Kernel 5.15.88-desktop-1.mga8.

The only thing in the journalctl logs from just before is

-------------------------------
Jul 24 23:22:34 tunnel.physics.ubc.ca dnf[2573748]: teams 8.9 kB/s | 1.5 kB 00:00
Jul 24 23:22:35 tunnel.physics.ubc.ca dnf[2573748]: Metadata cache created.

Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Succeeded.
Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: Finished dnf makecache.
Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Consumed 1.527s CPU time.
Jul 24 23:28:00 tunnel.physics.ubc.ca kernel: Shorewall:sshd-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=183.106.205.242 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=64660 PROTO=TCP SPT=31651 DPT=22 WINDOW=16988 RES=0x00 SYN URGP=0
Jul 24 23:35:31 tunnel.physics.ubc.ca kernel: Shorewall:net-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=185.225.74.53 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=33231 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
-- Reboot --
---------------------------------------

I recently replaced the power supply thinking it might be the cause.
But although freezes seem to be occuring less frequently, it is still
occasionally freezing. (It seems to be occuring every two or three
months).

On Fri, 28 Jul 2023 01:16:54 -0000 (UTC), William Unruh wrote:
> I have a disturbing system, which every once in a while freezes. The
> sceen on the monitor is some X scene (usually has Chrome running, but
> they again that is often the case) but the keyboard,mouse, do nothing.
> Trying to log on from the network fails with no response from the
> machine. Alt-ctrl-del does nothing. The only way to recover is via the
> power switch on the back.
> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
> nothingsignificant that I can see just before the freeze.
>
> Updated Mga8. Kernel 5.15.88-desktop-1.mga8.
>
> The only thing in the journalctl logs from just before is
>
> -------------------------------
> Jul 24 23:22:34 tunnel.physics.ubc.ca dnf[2573748]: teams 8.9 kB/s | 1.5 kB 00:00
> Jul 24 23:22:35 tunnel.physics.ubc.ca dnf[2573748]: Metadata cache created.
>
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Succeeded.
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: Finished dnf makecache.
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Consumed 1.527s CPU time.
> Jul 24 23:28:00 tunnel.physics.ubc.ca kernel: Shorewall:sshd-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=183.106.205.242 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=64660 PROTO=TCP SPT=31651 DPT=22 WINDOW=16988 RES=0x00 SYN URGP=0
> Jul 24 23:35:31 tunnel.physics.ubc.ca kernel: Shorewall:net-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=185.225.74.53 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=33231 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
> -- Reboot --
> ---------------------------------------
>
>
> I recently replaced the power supply thinking it might be the cause.
> But although freezes seem to be occuring less frequently, it is still
> occasionally freezing. (It seems to be occuring every two or three
> months).

Off hand it seems like the cpu gets into a tight loop and quits processing
interrupts.

I would install lm_sensors, configure/run lm_sensors, sensord and enable core dump.

I have also modified ~/.bash_profile to check for core dump files and
uses xmessage to provide a pop up if any are found.

William Unruh <unruh@invalid.ca> writes:
> I have a disturbing system, which every once in a while freezes. The
> sceen on the monitor is some X scene (usually has Chrome running, but
> they again that is often the case) but the keyboard,mouse, do nothing.
> Trying to log on from the network fails with no response from the
> machine. Alt-ctrl-del does nothing. The only way to recover is via the
> power switch on the back.
> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
> nothingsignificant that I can see just before the freeze.
>
> Updated Mga8. Kernel 5.15.88-desktop-1.mga8.
>
> The only thing in the journalctl logs from just before is
>
> -------------------------------
> Jul 24 23:22:34 tunnel.physics.ubc.ca dnf[2573748]: teams 8.9 kB/s |
> 1.5 kB 00:00
> Jul 24 23:22:35 tunnel.physics.ubc.ca dnf[2573748]: Metadata cache created.
>
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]:
> dnf-makecache.service: Succeeded.
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: Finished dnf makecache.
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]:
> dnf-makecache.service: Consumed 1.527s CPU time.
> Jul 24 23:28:00 tunnel.physics.ubc.ca kernel:
> Shorewall:sshd-fw:DROP:IN=eno1 OUT=
> MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=183.106.205.242
> DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=64660 PROTO=TCP
> SPT=31651 DPT=22 WINDOW=16988 RES=0x00 SYN URGP=0
> Jul 24 23:35:31 tunnel.physics.ubc.ca kernel:
> Shorewall:net-fw:DROP:IN=eno1 OUT=
> MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=185.225.74.53
> DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP
> SPT=33231 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
> -- Reboot --
> ---------------------------------------

There’s a chance that the kernel had something to say that couldn’t be
written to the logs due to the crash; unfortunately that can be rather
hard to get hold of in this case. If the machine has a serial port then
you might be able to get it to write kernel logs to that. But you might
just be out of luck l-(

--
https://www.greenend.org.uk/rjk/

On 7/28/23 03:16, William Unruh wrote:
> I have a disturbing system, which every once in a while freezes. The
> sceen on the monitor is some X scene (usually has Chrome running, but
> they again that is often the case) but the keyboard,mouse, do nothing.
> Trying to log on from the network fails with no response from the
> machine. Alt-ctrl-del does nothing. The only way to recover is via the
> power switch on the back.
> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
> nothingsignificant that I can see just before the freeze.

This reminds me of the issue I have had with running two plasma5
sessions, after a while they will just eat up the memory and when all is
gone, then everything freezes, you can't login from remote and local
login takes too long from entering username to entering password that
the login is canceled.

I would run a memory check once in a while, for example use crontab to
run this one liner:

date && ps -Ao user,uid,comm,pid,pcpu,pmem --sort=-pmem | head -n 11 &&
echo "----" >> /var/log/memusage.log

Then you can see if there is a process that grows.

--
//Aho

On Fri, 28 Jul 2023 10:27:47 +0200, J.O. Aho wrote:
> On 7/28/23 03:16, William Unruh wrote:
>> I have a disturbing system, which every once in a while freezes. The
>> sceen on the monitor is some X scene (usually has Chrome running, but
>> they again that is often the case) but the keyboard,mouse, do nothing.
>> Trying to log on from the network fails with no response from the
>> machine. Alt-ctrl-del does nothing. The only way to recover is via the
>> power switch on the back.
>> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
>> nothingsignificant that I can see just before the freeze.
>
> This reminds me of the issue I have had with running two plasma5
> sessions, after a while they will just eat up the memory and when all is
> gone, then everything freezes, you can't login from remote and local
> login takes too long from entering username to entering password that
> the login is canceled.
>
> I would run a memory check once in a while, for example use crontab to
> run this one liner:
>
> date && ps -Ao user,uid,comm,pid,pcpu,pmem --sort=-pmem | head -n 11 &&
> echo "----" >> /var/log/memusage.log
>
> Then you can see if there is a process that grows.

Cute, and with just a little bit of scripting/coding you could automate
the check by flagging any line with value above some watermark for cpu
and memory percentage.

If it was me, I would print any greater than 1.0 for ether one.

Since values have a decimal I would guess that I would have to
use bc to test greater than watermark value if using bash.

Simple case statement to change watermark values based on command.
where needed.

If you want a journal entry it would be something like
echo 'msg_here' | systemd-cat -t app_name_here -p type_msg_here

message types emerg, alert, crit, err, warning, notice, info, debug

In a multi-node set up I send an email to LAN admin.

On Fri, 28 Jul 2023 01:16:54 +0000, William Unruh wrote:

> I have a disturbing system, which every once in a while freezes. The
> sceen on the monitor is some X scene (usually has Chrome running, but
> they again that is often the case) but the keyboard,mouse, do nothing.
> Trying to log on from the network fails with no response from the
> machine. Alt-ctrl-del does nothing. The only way to recover is via the
> power switch on the back.
> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
> nothingsignificant that I can see just before the freeze.
>
> Updated Mga8. Kernel 5.15.88-desktop-1.mga8.
>
> The only thing in the journalctl logs from just before is
>
> -------------------------------
> Jul 24 23:22:34 tunnel.physics.ubc.ca dnf[2573748]: teams 8.9 kB/s | 1.5 kB 00:00
> Jul 24 23:22:35 tunnel.physics.ubc.ca dnf[2573748]: Metadata cache created.
>
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Succeeded.
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: Finished dnf makecache.
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Consumed 1.527s CPU time.
> Jul 24 23:28:00 tunnel.physics.ubc.ca kernel: Shorewall:sshd-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=183.106.205.242 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=64660 PROTO=TCP SPT=31651 DPT=22 WINDOW=16988 RES=0x00 SYN URGP=0
> Jul 24 23:35:31 tunnel.physics.ubc.ca kernel: Shorewall:net-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=185.225.74.53 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=33231 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
> -- Reboot --
> ---------------------------------------
>
>
> I recently replaced the power supply thinking it might be the cause.
> But although freezes seem to be occuring less frequently, it is still
> occasionally freezing. (It seems to be occuring every two or three
> months).

Pure speculation, but I think a update to the lib rpms months ago
introduced something that now and then causes the Gnome desktop
on Wayland to lock up.

My main machine and backup are both Intel 64-bit quad-core cpu, with
ram 32 GB for the former and 4 GB for the latter. Loads imposed are
trivial (mostly Opera browser, with firefox the alternative for any
siteopera does not work well with).

Now and then the desktop would lock up. When things were worst, the
backup would lock up every few days or maybe few weeks, and the main
machine less often.

Often, it would prove impossible to kill the browser or desktop.
Power switch restart is easier than shifting to the other
machine and trying to ssh in to reboot so that was my remedy.

Inability to come up with any hint of why, but rarity of lock-up,
has led me to just wait in expectation that someday (Mageia 9
perhaps) such problems will be ironed out.

Lockup has been less often in the past couple of months.

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely
expects users to be computer friendly.

On 2023-07-27 21:16, William Unruh wrote:

> Updated Mga8. Kernel 5.15.88-desktop-1.mga8.

Did you mean you updated FROM that kernel?

I hope so. Latest Mageia 8 kernel is 5.15.122-1.

TJ

On 7/27/2023 9:16 PM, William Unruh wrote:
> I have a disturbing system, which every once in a while freezes. The
> sceen on the monitor is some X scene (usually has Chrome running, but
> they again that is often the case) but the keyboard,mouse, do nothing.
> Trying to log on from the network fails with no response from the
> machine. Alt-ctrl-del does nothing. The only way to recover is via the
> power switch on the back.
> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
> nothingsignificant that I can see just before the freeze.
>
> Updated Mga8. Kernel 5.15.88-desktop-1.mga8.
>
> The only thing in the journalctl logs from just before is
>
> -------------------------------
> Jul 24 23:22:34 tunnel.physics.ubc.ca dnf[2573748]: teams 8.9 kB/s | 1.5 kB 00:00
> Jul 24 23:22:35 tunnel.physics.ubc.ca dnf[2573748]: Metadata cache created.
>
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Succeeded.
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: Finished dnf makecache.
> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Consumed 1.527s CPU time.
> Jul 24 23:28:00 tunnel.physics.ubc.ca kernel: Shorewall:sshd-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=183.106.205.242 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=64660 PROTO=TCP SPT=31651 DPT=22 WINDOW=16988 RES=0x00 SYN URGP=0
> Jul 24 23:35:31 tunnel.physics.ubc.ca kernel: Shorewall:net-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=185.225.74.53 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=33231 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
> -- Reboot --
> ---------------------------------------
>
>
> I recently replaced the power supply thinking it might be the cause.
> But although freezes seem to be occuring less frequently, it is still
> occasionally freezing. (It seems to be occuring every two or three
> months).

This bug does not yield to linear thinking, unfortunately.

It's not a hardware issue. There's something in the middle
of the graphics stack, which runs at frame rate (VSYNC), and
it has debounce for mouse built into it. (Like, your Razor mouse ?
Bad bad idea. You want a moldy old mouse with low DPI right now. Switch to PS/2 ports,
if ya gottem.) It uses a timer. It gets behind. And, it lunches the input subsystem.

We're seeing this elsewhere. Or, at least, log messages of the same type
as the bug. Have a look in your /var/log.

Try a radical change of DE, and see if stability returns.

As one developer described it "it's not your CPU which is too slow,
it is the Mutter architecture which is too slow".

Now, it's either that, or something has changed which has brought
an old bug back.

Paul

On 7/28/23 11:56, Bit Twister wrote:
> On Fri, 28 Jul 2023 10:27:47 +0200, J.O. Aho wrote:
>> On 7/28/23 03:16, William Unruh wrote:
>>> I have a disturbing system, which every once in a while freezes. The
>>> sceen on the monitor is some X scene (usually has Chrome running, but
>>> they again that is often the case) but the keyboard,mouse, do nothing.
>>> Trying to log on from the network fails with no response from the
>>> machine. Alt-ctrl-del does nothing. The only way to recover is via the
>>> power switch on the back.
>>> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
>>> nothingsignificant that I can see just before the freeze.
>>
>> This reminds me of the issue I have had with running two plasma5
>> sessions, after a while they will just eat up the memory and when all is
>> gone, then everything freezes, you can't login from remote and local
>> login takes too long from entering username to entering password that
>> the login is canceled.
>>
>> I would run a memory check once in a while, for example use crontab to
>> run this one liner:
>>
>> date && ps -Ao user,uid,comm,pid,pcpu,pmem --sort=-pmem | head -n 11 &&
>> echo "----" >> /var/log/memusage.log
>>
>> Then you can see if there is a process that grows.
>
> Cute, and with just a little bit of scripting/coding you could automate
> the check by flagging any line with value above some watermark for cpu
> and memory percentage.
>
> If it was me, I would print any greater than 1.0 for ether one.
>
> Since values have a decimal I would guess that I would have to
> use bc to test greater than watermark value if using bash.

You could use awk, have to always point out this great tool as it bears
my name

date && ps -Ao user,uid,comm,pid,pcpu,pmem --sort=-pmem | awk -v
min="0.3" '$6 >= min || $6=="%MEM"' && echo "----"

Just change the -v min="0.3" to the value you think it has be or more to
be displayed, we also keep displaying the column names, sure there is
better ways of doing this, but my skills not that great.

> In a multi-node set up I send an email to LAN admin.

In a multi node setup I would use icinga or nagios to monitor things,
sure you can do the same with elk too.

--
//Aho

On 2023-07-28, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Fri, 28 Jul 2023 01:16:54 -0000 (UTC), William Unruh wrote:
>> I have a disturbing system, which every once in a while freezes. The
>> sceen on the monitor is some X scene (usually has Chrome running, but
>> they again that is often the case) but the keyboard,mouse, do nothing.
>> Trying to log on from the network fails with no response from the
>> machine. Alt-ctrl-del does nothing. The only way to recover is via the
>> power switch on the back.
>> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
>> nothingsignificant that I can see just before the freeze.
>>
>> Updated Mga8. Kernel 5.15.88-desktop-1.mga8.
>>
>> The only thing in the journalctl logs from just before is
>>
>> -------------------------------
>> Jul 24 23:22:34 tunnel.physics.ubc.ca dnf[2573748]: teams 8.9 kB/s | 1.5 kB 00:00
>> Jul 24 23:22:35 tunnel.physics.ubc.ca dnf[2573748]: Metadata cache created.
>>
>> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Succeeded.
>> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: Finished dnf makecache.
>> Jul 24 23:22:35 tunnel.physics.ubc.ca systemd[1]: dnf-makecache.service: Consumed 1.527s CPU time.
>> Jul 24 23:28:00 tunnel.physics.ubc.ca kernel: Shorewall:sshd-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=183.106.205.242 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=64660 PROTO=TCP SPT=31651 DPT=22 WINDOW=16988 RES=0x00 SYN URGP=0
>> Jul 24 23:35:31 tunnel.physics.ubc.ca kernel: Shorewall:net-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=185.225.74.53 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=33231 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
>> -- Reboot --
>> ---------------------------------------
>>
>>
>> I recently replaced the power supply thinking it might be the cause.
>> But although freezes seem to be occuring less frequently, it is still
>> occasionally freezing. (It seems to be occuring every two or three
>> months).
>
>
> Off hand it seems like the cpu gets into a tight loop and quits processing
> interrupts.
>
> I would install lm_sensors, configure/run lm_sensors, sensord and enable core dump.
>
> I have also modified ~/.bash_profile to check for core dump files and
> uses xmessage to provide a pop up if any are found.
>

OK, Here are the last two sensord reports just before the freeze
I do not see anything out of the ordinary here. The last one (23:28:55)
occured. The freeze ( as inferred from the last entry into /var/log/syslog
occured aroung 23:35:31

(
--------------------------------
Jul 24 23:35:31 tunnel kernel: [1181287.585321] Shorewall:net-fw:DROP:IN=eno1 OUT= MAC=4c:ed:fb:c2:2a:f3:a0:ab:1b:88:6e:58:08:00 SRC=185.225.74.53 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=33231 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jul 25 09:13:25 tunnel kernel: [ 0.000000] microcode: microcode updated early to revision 0xf0, date = 2021-11-12
--------------------------------------

----------------------------------
Jul 24 23:08:55 tunnel sensord: Chip: nvme-pci-0600
Jul 24 23:08:55 tunnel sensord: Adapter: PCI adapter
Jul 24 23:08:55 tunnel sensord: Composite: 24.9 C (min = -40.1 C, max = 83.8 C)
Jul 24 23:08:55 tunnel sensord: Sensor 2: 24.9 C (min = -40.1 C, max = 83.8 C)
Jul 24 23:08:55 tunnel sensord: Chip: coretemp-isa-0000
Jul 24 23:08:55 tunnel sensord: Adapter: ISA adapter
Jul 24 23:08:55 tunnel sensord: Package id 0: 29.0 C
Jul 24 23:08:55 tunnel sensord: Core 0: 28.0 C
Jul 24 23:08:55 tunnel sensord: Core 1: 27.0 C
Jul 24 23:08:55 tunnel sensord: Core 2: 28.0 C
Jul 24 23:08:55 tunnel sensord: Core 3: 27.0 C
Jul 24 23:08:55 tunnel sensord: Chip: acpitz-acpi-0
Jul 24 23:08:55 tunnel sensord: Adapter: ACPI interface
Jul 24 23:08:55 tunnel sensord: temp1: 27.8 C
Jul 24 23:28:55 tunnel sensord: Chip: nvme-pci-0600
Jul 24 23:28:55 tunnel sensord: Adapter: PCI adapter
Jul 24 23:28:55 tunnel sensord: Composite: 24.9 C (min = -40.1 C, max = 83.8 C)
Jul 24 23:28:55 tunnel sensord: Sensor 2: 24.9 C (min = -40.1 C, max = 83.8 C)
Jul 24 23:28:55 tunnel sensord: Chip: coretemp-isa-0000
Jul 24 23:28:55 tunnel sensord: Adapter: ISA adapter
Jul 24 23:28:55 tunnel sensord: Package id 0: 29.0 C
Jul 24 23:28:55 tunnel sensord: Core 0: 28.0 C
Jul 24 23:28:55 tunnel sensord: Core 1: 27.0 C
Jul 24 23:28:55 tunnel sensord: Core 2: 27.0 C
Jul 24 23:28:55 tunnel sensord: Core 3: 27.0 C
Jul 24 23:28:55 tunnel sensord: Chip: acpitz-acpi-0
Jul 24 23:28:55 tunnel sensord: Adapter: ACPI interface
Jul 24 23:28:55 tunnel sensord: temp1: 27.8 C
----------------------------------------------

I cannot find any core files, and I do not think I am suppressing them.

On 2023-07-28, J.O. Aho <user@example.net> wrote:
> On 7/28/23 03:16, William Unruh wrote:
>> I have a disturbing system, which every once in a while freezes. The
>> sceen on the monitor is some X scene (usually has Chrome running, but
>> they again that is often the case) but the keyboard,mouse, do nothing.
>> Trying to log on from the network fails with no response from the
>> machine. Alt-ctrl-del does nothing. The only way to recover is via the
>> power switch on the back.
>> Afterwards, looking at /var/log/syslog, or /var/log/messages shows
>> nothingsignificant that I can see just before the freeze.
>
> This reminds me of the issue I have had with running two plasma5
> sessions, after a while they will just eat up the memory and when all is
> gone, then everything freezes, you can't login from remote and local
> login takes too long from entering username to entering password that
> the login is canceled.

Except in my case, nothing I type does anything, the mouse cursor does
not move, Teh Alt-ctrl-F keys do nothing, alt-ctrl-det or alt-ctrl-bksp
do nothing, gkrellm stops updating. Usually when I have run out of
memory, somethings still work, and the machine slows down drastically as
it starts to swap. This is just a complete sudden freeze. (Unlike this
past time, sometimes this has happened while I am working on the
machine. This time it happened while I was asleep)
>
> I would run a memory check once in a while, for example use crontab to
> run this one liner:
>
> date && ps -Ao user,uid,comm,pid,pcpu,pmem --sort=-pmem | head -n 11 &&
> echo "----" >> /var/log/memusage.log
>
> Then you can see if there is a process that grows.
>