Parsing log files for test results
Colin Ian King
colin.king at canonical.com
Tue Dec 6 17:52:21 UTC 2011
On 06/12/11 16:49, Marc Tardif wrote:
> * Colin Ian King<colin.king at canonical.com> [2011-12-06 16:40 +0000]:
>> On 05/12/11 22:29, Marc Tardif wrote:
>>> After a user has been running a proposed kernel for a couple days, I would
>>> like to parse the logs of the system to detect what parts of the kernel
>>> might have been tested implicitly during that period. These results could
>>> then be uploaded to Launchpad, with the consent of the user of course,
>>> without having to actually run tests manually. 
>>> First, I would like to consider suspending. I looked in /var/log/syslog
>>> where I found strings that could be parsed to detect a successful wakeup
>> >from suspend:
>>> kernel: [ 137.402845] ACPI: Waking up from system sleep state S3
>>> However, the problem is that syslog does not seem to contain the kernel
>>> version to validate that the proposed kernel is effectively being tested.
>>> So, I then discovered /var/log/pm-suspend.log which contained both the
>>> kernel version and the result of resuming from suspend:
>>> Linux 200910-4253 3.0.0-12-generic #20-Ubuntu SMP Fri Oct...
>>> /var/lib/pm-utils/sleep.d/00kernel-change resume suspend: success.
>>> Second, I would also like to consider the same for hibernating. I looked
>>> at /var/log/pm-suspend.log which also seemed to contain the result of
>>> thawing from hibernate:
>>> /var/lib/pm-utils/sleep.d/000kernel-change thaw hibernate: success.
>>> Would you say that these are reliable ways to detect that suspend and
>>> hibernate were successful?
>>> 1. https://blueprints.launchpad.net/certify-planning/+spec/hardware-p-cert-sru-community
>> This kind of S3 success detection has implemented in fwts. I refer
>> you to the git
>> repo: git://kernel.ubuntu.com/lexical/fwts.git and the relevant source:
>> src/acpi/s3/s3.c - see s3_check_log()
>> src/lib/src/fwts_hwinfo.c - see fwts_hwinfo_get() and
>> src/lib/src/fwts_klog.c and data/klog.json (containing>160
>> regexs to scan the kernel log)
> After looking at the code, I only noticed checking for S3 failure rather
> than S3 success. The distinction is not strictly pedantic but rather to
> make sure I understand correctly: s3_check_log and the patterns in
> klog.json only really check if something went wrong, right?
Sure, one needs to define what success is I suppose.
More information about the kernel-team