[Dorset] Church website problem - Firefox
I have a problem which only shows on the laptop when logged into our Church Website Member section. First I thought it was the website programme as I'd only logged in on the laptop and the website had been updated with a 'Hub' system. Last week I was on the desktop, that's when I noticed the difference. On the laptop after logging into the website and then going to the /'private'/ area log-in, the menu buttons for the various locations, are overwritten with the programme script names for each button. On the desktop all works fine, and other websites are not affected. Both machines are using the same Mint 21.2, Firefox and are fully updated versions, I can't see any differences in the settings and don't know how to locate the cause of the script button names to show. I assume I'm missing a basic script (Java?) on the laptop. Any help please? -- -- Next meeting: Online, Jitsi, Tuesday, 2023-12-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] My Kubuntu Config is completely trashed
On 15/11/2023 13:20, Ralph Corderoy wrote: I see the kernel version has changed over time. Does one of these match when problems started? Oct 09 06:27:45 Linux version 6.2.0-34-generic Oct 21 06:49:29 Linux version 6.2.0-35-generic Oct 31 06:45:38 Linux version 6.2.0-36-generic Nov 03 07:10:43 Linux version 6.5.0-10-generic There are several instances of chromium being flagged prior to the big crash, which I think was sometime around 0724 (I honestly can't remember when it occurred, but the next reboot at 0726 stayed up until 0916, when I think I was trying to get my desktop back. To be honest, I'm not sure when this all started. The jump from 6.2.0 to 6.5.0 occurred when I upgraded the system from Kubuntu 23.04 to 23.10. I see a couple of recent ‘-- Boot’ which aren't preceded by an orderly shutdown. The first suggests attempts to reduce power consumption. Nov 13 10:09:05 OptiPlex kded5[2241]: window match: "Bing — Konqueror" :OK Nov 13 10:09:05 OptiPlex kded5[2241]: window match: "Bing — Konqueror" :OK Nov 13 10:09:35 OptiPlex kernel: intel_rapl_common: package-0:package:long_term locked by BIOS Nov 13 10:09:35 OptiPlex kernel: intel_rapl_common: package-0:package:long_term locked by BIOS Nov 13 10:09:35 OptiPlex kernel: intel_rapl_common: package-0:package:long_term locked by BIOS Nov 13 10:09:39 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:40 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:41 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:43 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:44 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:46 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:47 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:49 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:50 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:52 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:53 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:54 OptiPlex kernel: perf: interrupt took too long (3163 > 3157), lowering kernel.perf_event_max_sample_rate to 63000 -- Boot ca7b1b0ebca14ef593ca63664a8ef61c -- Nov 13 10:11:30 OptiPlex kernel: microcode: updated early: 0x23 -> 0x2f, date = 2019-02-17 The second just cuts off mid journalling. Nov 14 06:56:28 OptiPlex systemd[1]: Starting update-notifier-download.service - Download data for packages that failed at package install time... -- Boot 28f4f4d1397f4835a7c248aa9505aba1 -- Nov 14 06:57:30 OptiPlex kernel: microcode: updated early: 0x23 -> 0x2f, date = 2019-02-17 I can't say for sure what was going on when the resource hogging occurred in relation to those logs.However, it occurs to me that the one at 06:56 was when I successfully powered down via the button on front of the box, whereas the one from the previous day when I managed to kill Chromium using htop. Is the PSU in your desktop capable of supplying the whole machine at full pelt, including all the peripherals? It might explain the unexpected shutdown when the machine was highly loaded for a while. Though of course what you really want is to stop the runaway load. This PSU is the exact same one that was in the machine when I bought it some years ago (you may recall that you tipped me off that a company in Poole was flogging of computers). I have never seen anything like this before. As far as I can see, the only thing that is likely to be the cause of this is the resource hogging by Chromium. It has never done this before and it only appears to do it when I browse to an Echo newspapers web page with Chromium. I've been trying to video htop when this happens, but I haven't seen the problem since I reinstated the machine yesterday. Maybe Echo Newspapers have fixed their pages of the Chromium snap has been updated (there are several instances of this in the journal). If it does come back I'll try to get a video and post it on my website. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2023-12-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] My Kubuntu Config is completely trashed
Hi Terry, > I have posted the output of journalctl at > https://hadrian-way.co.uk/Misc/journal.txt. I see the kernel version has changed over time. Does one of these match when problems started? Oct 09 06:27:45 Linux version 6.2.0-34-generic Oct 21 06:49:29 Linux version 6.2.0-35-generic Oct 31 06:45:38 Linux version 6.2.0-36-generic Nov 03 07:10:43 Linux version 6.5.0-10-generic > There are several instances of chromium being flagged prior to the big > crash, which I think was sometime around 0724 (I honestly can't > remember when it occurred, but the next reboot at 0726 stayed up until > 0916, when I think I was trying to get my desktop back. I see a couple of recent ‘-- Boot’ which aren't preceded by an orderly shutdown. The first suggests attempts to reduce power consumption. Nov 13 10:09:05 OptiPlex kded5[2241]: window match: "Bing — Konqueror" :OK Nov 13 10:09:05 OptiPlex kded5[2241]: window match: "Bing — Konqueror" :OK Nov 13 10:09:35 OptiPlex kernel: intel_rapl_common: package-0:package:long_term locked by BIOS Nov 13 10:09:35 OptiPlex kernel: intel_rapl_common: package-0:package:long_term locked by BIOS Nov 13 10:09:35 OptiPlex kernel: intel_rapl_common: package-0:package:long_term locked by BIOS Nov 13 10:09:39 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:40 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:41 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:43 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:44 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:46 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:47 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:49 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:50 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:52 OptiPlex kernel: intel_powerclamp: Stop forced idle injection Nov 13 10:09:53 OptiPlex kernel: intel_powerclamp: Start idle injection to reduce power Nov 13 10:09:54 OptiPlex kernel: perf: interrupt took too long (3163 > 3157), lowering kernel.perf_event_max_sample_rate to 63000 -- Boot ca7b1b0ebca14ef593ca63664a8ef61c -- Nov 13 10:11:30 OptiPlex kernel: microcode: updated early: 0x23 -> 0x2f, date = 2019-02-17 The second just cuts off mid journalling. Nov 14 06:56:28 OptiPlex systemd[1]: Starting update-notifier-download.service - Download data for packages that failed at package install time... -- Boot 28f4f4d1397f4835a7c248aa9505aba1 -- Nov 14 06:57:30 OptiPlex kernel: microcode: updated early: 0x23 -> 0x2f, date = 2019-02-17 Is the PSU in your desktop capable of supplying the whole machine at full pelt, including all the peripherals? It might explain the unexpected shutdown when the machine was highly loaded for a while. Though of course what you really want is to stop the runaway load. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2023-12-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] My Kubuntu Config is completely trashed
On 15/11/2023 07:03, Terry Coles wrote: You might find some indication of past problems with ‘sudo -i journalctl’. It will place you in less(1). There's the date to go by and you can search with ‘/’, e.g. ‘oom-killer’. There was only one instance of oom-killer: Nov 02 08:46:48 OptiPlex kernel: systemd invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0 That is some time before all this happened. I've just spent some time manually parsing the journalctl output for any sign of a problem. There are several instances of chromium being flagged prior to the big crash, which I think was sometime around 0724 (I honestly can't remember when it occurred, but the next reboot at 0726 stayed up until 0916, when I think I was trying to get my desktop back. I can see nothing in that period that I can recognise as a problem, but I probably would recognise it if I saw it. I have posted the output of journalctl at https://hadrian-way.co.uk/Misc/journal.txt. (it's a very large file, but I thought it was worth putting all the recent history out there for someone who might see when things started going wrong). -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2023-12-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] My Kubuntu Config is completely trashed
On 15/11/2023 07:03, Terry Coles wrote: On 14/11/2023 12:05, Ralph Corderoy wrote: I'm surprised a Linux machine is configured to shutdown on persistent high CPU or memory load. Rather, the kernel's out-of-memory killer will kick in and guess a process to kill to free memory. It sometimes nobbles the wrong horse. Perhaps it sent some vital process to the glue factory which initiated an orderly shutdown, but I doubt it. I have been very happy using Vivaldi for the past little while. It takes a bit of getting used to, but I like it now. Peter -- Next meeting: Online, Jitsi, Tuesday, 2023-12-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
