When this happens, is the ksystemstats daemon running? It is supposed to be autostarted when anything that uses it appears, when then tear itself down automatically when the last user quits.

Is this happening only login, or are the widgets blank the moment you add them?

As mentioned, ksystemstats appears to be active and jumps to 100% CPU usage by adding the plasmoids. So it seems to get started appropriately, but then something goes wrong.

The issue is immediately present after adding the plasmoid, not just a login.

I have noticed that other cpu-load related plasmoids that can be downloaded rather than being readily available appear to work, though partially. However, with them, ksystemstats does not seem to run (e.g., I see that the "system load viewer" plasmoid version 0.8 by Martin Yrjölä works, even if the "show CPUs separately" option does not). Is it based on a different approach?

Also running ksysguard works (as mentioned) and does not start ksystemstats.

Hence, my impression is that some plasmoid rely on a "new" framework using the ksystemstats daemon, that the daemon gets started properly when needed, but does not work. It fails to provide data to the plasmoids and it enters some state where it uses all the available resources of the core it runs on.

I wonder if this is ARM specific or RPI4 specific or is due to a packaging or permission problem specific to arch/manjaro.

Could be one or the other, yeah. Are you using systemd startup, or not?

Yes manjaro uses systemd.

No I mean http://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

@Nate Graham sorry I missed your previous question. Catching up...

From the document you linked, I believe that this is the needed info:
'''
systemctl --user status plasma-plasmashell.service
○ plasma-plasmashell.service - KDE Plasma Workspace
     Loaded: loaded (/usr/lib/systemd/user/plasma-plasmashell.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
'''

Possibly not relevant. However, if you try to activate the service manually you get

'''
systemctl --user start plasma-plasmashell.service

systemctl --user status plasma-plasmashell.service
○ plasma-plasmashell.service - KDE Plasma Workspace
     Loaded: loaded (/usr/lib/systemd/user/plasma-plasmashell.service; disabled; vendor preset: enabled)
     Active: inactive (dead)

Apr 28 09:14:16 systemd[694]: Starting KDE Plasma Workspace...
Apr 28 09:14:17 systemd[694]: plasma-plasmashell.service: Deactivated successfully.
Apr 28 09:14:17 systemd[694]: Started KDE Plasma Workspace.
```

... after which the behavior of the widgets and the systemstat daemon does not change (widgets not working, daemon using 100% of one core).

KDE Frameworks update to 5.81 has not fixed the issue.

Thanks for the info.

Tried to launch ksystemstats manually, from the command line (incidentally, not so nice that there is no documentation at all, nor response to invoking with --help. Unclear to me if there is any way to make it print some debug info).

Also in this case, ksystemstats gets in an "active wait" mode, using up 100% cpu.

Trying to debug using strace, you can see that after some initial steps it enters in a situation where it keeps trying to read from file descriptor 8, but reads nothing.

The latest openat returning file descriptor 8 seems to be /proc/cpuinfo.

So my impression is that ksystemstats does not know how to parse the cpuinfo for ARM (or at least for the RPI4 Broadcom BCM2711 cpu) and remains confused.

A few additional notes:

* just observed that ksystemstats belong to a ksysguard package on my distro. Wonder if the "product" field should be changed to ksysguard.

* ksysguard package on my system comes with plasma 5.21.5

* just learned about the kstatsviewer command. It also hangs on my system when launched as ksytatsviewer --list

Issue is still present as of plasma 5.22.5, frameworks 5.87.0

I think that ksystemstats is uninstalled from your system, it happens to me. Try to install it. Here's the instructions to install ksystemstats.

Enable the repository:
# sudo add-apt-repository ppa:kubuntu-ppa/backports
Update the package index:
# sudo apt-get update
Install ksystemstats deb package:
# sudo apt-get install ksystemstats

More info.
https://ubuntu.pkgs.org/21.04/kubuntu-backports-amd64/ksystemstats_5.22.5-0ubuntu1~ubuntu21.04~ppa1_amd64.deb.html

As mentioned above, ksystemstats is installed.

> As mentioned, ksystemstats appears to be active and jumps to 100% CPU usage by adding the 
> plasmoids. So it seems to get started appropriately, but then something goes wrong.

ps shows /usr/bin/ksystemstats getting autostartd when the plasmoid is added, but then ksystemstats goes in active wait for something using 100% CPU. My feeling is that it may try to parse data from some interface remaining in active wait because it is not getting something that is expected (most likely because it waits for something that is X86 specific and not present on ARM systems).

stracing ksystemstats shows it opening /proc/cpuinfo, reading from it some text (the last string I see on the trace is about some bogomips value, but this may be due to strace string truncation). Then ksystemstats keeps repeating read attempts from that file always getting nothing.

To me this is ksystemstats trying to read the file seeking for something, not finding it (because the virtual file misses some fields on ARM wrt X86 and has a slightly different format) arriving at the end of the file and stubbornly keeping to attempt reads.

I got this bug too on arm, a Mekotronics R58X (RK3588 EDGE LP4x V1.0 BlueBerry Board).

Stracing it, it gets stuck in reading /proc/cpuinfo, like how Sergio reported.

It goes like:
```
mprotect(0x7f9f2a1000, 4096, PROT_READ) = 0
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
openat(AT_FDCWD, "/proc/cpuinfo", O_RDONLY|O_CLOEXEC) = 7
statx(7, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0444, stx_size=0, ...}) = 0
statx(7, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0444, stx_size=0, ...}) = 0
read(7, "processor\t: 0\nBogoMIPS\t: 48.00\nF"..., 16384) = 1923
read(7, "", 14461)                      = 0
read(7, "", 16384)                      = 0
read(7, "", 16384)                      = 0
```
And spams `read(7, "", 16384)                      = 0` forever.

```
[bill88t@r58b | ~]> cat /proc/cpuinfo 
processor       : 0
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 1
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x4
CPU part        : 0xd0b
CPU revision    : 0

processor       : 2
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x4
CPU part        : 0xd0b
CPU revision    : 0

processor       : 3
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x4
CPU part        : 0xd0b
CPU revision    : 0

processor       : 4
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x4
CPU part        : 0xd0b
CPU revision    : 0

processor       : 5
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 6
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 7
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

Serial          : 8d3a9fcd2babbc55
```

```
extra/ksystemstats 5.27.8-2 (171.7 KiB 1023.5 KiB) [plasma] (Installed)
    A plugin based system monitoring daemon
```

Seems to me that bug is in linuxcpuplugin.cpp, row 72:

```
 for (QByteArray line = cpuinfo.readLine(); !line.isEmpty(); line = cpuinfo.readLine()) {
        CpuInfo info;
        // Processors are divided by empty lines
        for (; line != "\n";  line = cpuinfo.readLine()) {
            // we are interested in processor number as identifier for /proc/stat, physical id (the
            // cpu the core belongs to) and the number of the core. However with hyperthreading
            // multiple entries will have the same combination of physical id and core id. So we just
            // count up the core number. For mapping temperature both ids are still needed nonetheless.
            const int delim = line.indexOf(":");
            const QByteArray field = line.left(delim).trimmed();
            const QByteArray value = line.mid(delim + 1).trimmed();
            if (field == "processor") {
                info.id = value.toInt();
            } else if (field == "physical id") {
                info.cpu = value.toInt();
            } else if (field == "core id") {
                info.core = value.toInt();
            } else if (field == "cpu MHz") {
                info.frequency = value.toDouble();
            } else if (field == "siblings") {
                info.siblings = value.toInt();
            }
        }
```

and depends on the fact that inner loop doesn't check for empty line, baseing on assumption that every cpu block in /proc/cpuinfo is terminated by and empty line. Problem is that arm cpuinfo terminates with one or more lines that are not part of any cpu-block, like the following raspi5 example:

```
cat /proc/cpuinfo 
processor	: 0
BogoMIPS	: 108.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x4
CPU part	: 0xd0b
CPU revision	: 1

processor	: 1
BogoMIPS	: 108.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x4
CPU part	: 0xd0b
CPU revision	: 1

processor	: 2
BogoMIPS	: 108.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x4
CPU part	: 0xd0b
CPU revision	: 1

processor	: 3
BogoMIPS	: 108.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x4
CPU part	: 0xd0b
CPU revision	: 1

Hardware	: BCM2835
Revision	: d04170
Serial		: XXXXXXXXXXXXXXXXXXXXXX
Model		: Raspberry Pi 5 Model B Rev 1.0
```

Sorry, in previous snippet from linuxcpuplugin.cpp I missed to report the outer loop closing rows. Here complete snippet is, for clarity:

```
    for (QByteArray line = cpuinfo.readLine(); !line.isEmpty(); line = cpuinfo.readLine()) {
        CpuInfo info;
        // Processors are divided by empty lines
        for (; line != "\n";  line = cpuinfo.readLine()) {
            // we are interested in processor number as identifier for /proc/stat, physical id (the
            // cpu the core belongs to) and the number of the core. However with hyperthreading
            // multiple entries will have the same combination of physical id and core id. So we just
            // count up the core number. For mapping temperature both ids are still needed nonetheless.
            const int delim = line.indexOf(":");
            const QByteArray field = line.left(delim).trimmed();
            const QByteArray value = line.mid(delim + 1).trimmed();
            if (field == "processor") {
                info.id = value.toInt();
            } else if (field == "physical id") {
                info.cpu = value.toInt();
            } else if (field == "core id") {
                info.core = value.toInt();
            } else if (field == "cpu MHz") {
                info.frequency = value.toDouble();
            } else if (field == "siblings") {
                info.siblings = value.toInt();
            }
        }

        cpus.push_back(info);
        cpuCount = std::max(cpuCount, info.cpu);
    }
```

Good catch, would you like to submit a patch at https://invent.kde.org/plasma/ksystemstats/-/merge_requests ?