feat: add dmesg log plugin

[reubenmiller]

Proposed changes

Add a dmesg log plugin to the out-of-the-box features. The dmesg plugin only provide one type called "all" due to the vast differences in the dmesg implementations (e.g. busybox/bsd don't support filtering by log facility or datetime).

The plugin will attempt to call dmesg with a datetime filter, however if it fails for any reason, then dmesg will be called without any arguments (and in this case all the messages will be returned). This is due to the various implementations of dmesg.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s. You can activate automatic signing by running just prepare-dev once)
• I ran just format as mentioned in CODING_GUIDELINES
• I used just check as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
716	0	3	716	100	2h13m42.769500999s

[albinsuresh]

The standard set seems to be 15 although I came across a few other blogs where that number was 11. But most of the online docs had 15 listed.

[reubenmiller]

@rina23q @albinsuresh Ok, since the list seems to vary significantly (depends on the dmesg implementation), I'll refactor to remove all the types (as it will be more predictable for users), and just have a single "all" type.

Do you both agree?

[reubenmiller]

Though I'll still have to add a check to find out when the datetime filtering can be used (as that is also dependent on the implementation).

[rina23q]

I'm fine to keep only all.
The 15 facilities are based on RFC5424 (syslog protocol). I assume and it seems dmesg doesn't have to align with the facilities defined on RFC5424?

[reubenmiller]

Though the problem is that I don't think that all dmesg implementations support it anyway...so it would just be adding an extra 15 items to the types, where we don't know which ones would work or not.

So if we keep things simple for now, and just have one type, as it is anyway for more advanced usecases (as this is more for powerusers who want to monitor kernel messages to debug driver problems etc.)

[reubenmiller]

I've updated the PR to used the single "all" type. The PR's description also reflects the updated scope.

[rina23q]

LGTM

[didier-wenzek]

Something is wrong with these defaults. I got no entries when no values is given for --since and --until.

[reubenmiller]

Though that might be because there are no values within the time range (which isn't uncommon)

[reubenmiller]

But you can confirm this by just increasing the look back.

/var/share/tedge/log-plugins/dmesg get all --since "180 days ago" --until "0 second ago"

[reubenmiller]

We could change the default to something higher, like 90 days?