Bug #11428
closedCPU details are incorrect in the System Information widget after resetting log files
100%
Description
Some CPU Type information disappear after reset the log files under Status.
This happen on VMWare with 2.5.0 RC and same happen on build computer.
Files
Updated by B. B. almost 4 years ago
First reported here:
https://forum.netgate.com/topic/160762/cpu-info-disappear-on-pfsense-2-5-0-rc/2
Updated by Jim Pingle almost 4 years ago
- Subject changed from CPU Type, some information disappear on 2.5.0 RC to CPU core details disappear after resetting log files
- Priority changed from Normal to Very Low
- Target version changed from 2.6.0 to Future
- Private changed from Yes to No
This is because the number of packages and cores is currently scraped from /var/log/dmesg.boot, and when you reset all log files, that file gets reset since it's also a log file.
There doesn't appear to be any way to get the equivalent information out of sysctl (e.g. under kern.smp.*
), since that seems to only count the total number of cores and not the number of physical CPUs ("packages"). We can't rely on it being in the kernel message buffer either since that gets cycled out as new messages come in.
It's cosmetic only and only affects the rare occasion someone resets log files, so given the very low impact and lack of easy workaround, I don't see it being worth dedicating a lot of resources to fix. If someone happens to come up with a viable workaround, feel free to submit a PR.
Updated by B. B. almost 4 years ago
Jim Pingle wrote:
This is because the number of packages and cores is currently scraped from /var/log/dmesg.boot, and when you reset all log files, that file gets reset since it's also a log file.
There doesn't appear to be any way to get the equivalent information out of sysctl (e.g. under
kern.smp.*
), since that seems to only count the total number of cores and not the number of physical CPUs ("packages"). We can't rely on it being in the kernel message buffer either since that gets cycled out as new messages come in.It's cosmetic only and only affects the rare occasion someone resets log files, so given the very low impact and lack of easy workaround, I don't see it being worth dedicating a lot of resources to fix. If someone happens to come up with a viable workaround, feel free to submit a PR.
Hi Jim,
Okay, thanks for the information. It didn't happen with previous pfSense versions so that's why I report it :)
But, what about AES-NI CPU Crypto: Yes (active) change to AES-NI CPU Crypto: NO after RESET LOG FILES. I do have Intel CPU that supports AES and I use couple of OpenVPN too. :)
Updated by Jim Pingle almost 4 years ago
Same issue with finding the CPU flags to see what the CPU supports.
On older versions, dmesg.boot wasn't cleared, but also on older versions there wasn't a log tab for dmesg.boot and there is now (Status > System Logs, System tab, OS Boot sub-tab).
Updated by Steve Y almost 4 years ago
Would it work to just copy the file to dmesg.boot.current or whatever, after each boot, and then parse that? It should always be small (?) and dmesg.boot could be rotated on demand.
e.g. cron:
@reboot sleep 120 && cp /var/log/dmesg.boot /var/log/dmesg.boot.current
Updated by Jim Pingle almost 4 years ago
The dmesg.boot file is the copy of the kernel message buffer for that purpose.
Resetting log files should not be necessary on 2.5.0/21.02 and forward often enough for this to be a concern.
People may have been in the habit of doing it for various reasons on old versions with clog (like changing log sizes/options) but that isn't necessary anymore.
Updated by Viktor Gurov almost 4 years ago
Jim Pingle wrote:
The dmesg.boot file is the copy of the kernel message buffer for that purpose.
Resetting log files should not be necessary on 2.5.0/21.02 and forward often enough for this to be a concern.
People still need to reset log files in some cases (e.g. clearing history)
keep dmesg.boot on log reset, as it is the copy of the kernel message buffer, and not a log file:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/173
Updated by Jim Pingle almost 4 years ago
- Status changed from New to Pull Request Review
- Target version changed from Future to CE-Next
Updated by Jim Pingle almost 4 years ago
- Target version changed from CE-Next to 2.5.1
Updated by Renato Botelho almost 4 years ago
- Status changed from Pull Request Review to Waiting on Merge
- Assignee set to Viktor Gurov
PR has been merged. Thanks!
Updated by Viktor Gurov almost 4 years ago
- Status changed from Waiting on Merge to Feedback
- % Done changed from 0 to 100
Applied in changeset f3fd77ee3cbb6e547b6154d13eab5019f36025d6.
Updated by Jim Pingle almost 4 years ago
To test:
On a system without the fix:
- Check System Information Widget on the Dashboard for "AES-NI CPU Crypto: Yes"
- Reset all log files from Status > System Logs, Settings tab
- View the OS Boot log at Status > System Logs, System, OS Boot. It will be empty.
- Check System Information Widget on the Dashboard and it now displays "AES-NI CPU Crypto: No"
- Reboot and check the widget again, and the expected value has returned.
Repeat the test again on a snapshot with the fix and resetting the log files will not change the dashboard output nor will it clear the OS boot log.
Updated by Jim Pingle almost 4 years ago
- Subject changed from CPU core details disappear after resetting log files to CPU details are incorrect in the System Information widget after resetting log files
Updating subject for release notes.
Updated by B. B. almost 4 years ago
Bearny B. wrote:
Some CPU Type information disappear after reset the log files under Status.
This happen on VMWare with 2.5.0 RC and same happen on build computer.
Jim Pingle wrote:
Updating subject for release notes.
It has been fixed in 2.5.1 RC (latest snapshot) and 2.6.0 DEV (latest snapshot)
Updated by Renato Botelho almost 4 years ago
- Status changed from Feedback to Resolved
Updated by Michael Spears over 3 years ago
Bearny B. wrote:
Bearny B. wrote:
Some CPU Type information disappear after reset the log files under Status.
This happen on VMWare with 2.5.0 RC and same happen on build computer.Jim Pingle wrote:
Updating subject for release notes.
It has been fixed in 2.5.1 RC (latest snapshot) and 2.6.0 DEV (latest snapshot)
Tested on 21.02.2-RC (amd64) built on Thu Apr 01 11:53:58 EDT 2021, fix confirmed.