acrnprobe Configuration¶
Description¶
acrnprobe uses XML as the format of its configuration file, namely
acrnprobe.xml, following the XML standard.
Layout¶
<?xml version="1.0" encoding="UTF-8"?>
<conf>
Root node of configuration.
<senders>
Configuration section of senders.
<sender id='1'>Configuration of sender 1</sender>
<sender id='2'>Configuration of sender 2</sender>
</senders>
<triggers>
Configuration section of triggers.
<trigger id='1'>Configuration of trigger 1</trigger>
<trigger id='2'>Configuration of trigger 2</trigger>
</triggers>
<vms>
Configuration section of virtual machines.
<vm id='1'>Configuration of vm 1</vm>
<vm id='2'>Configuration of vm 2</vm>
</vms>
<logs>
Configuration section of logs.
<log id='1'>Configuration of log 1</log>
<log id='2'>Configuration of log 2</log>
</logs>
<crashes>
Configuration section of crashes.
Note that this section must be configured after triggers and logs, as
crashes depend on these two sections.
<crash id='1'>Configuration of crash 1</crash>
<crash id='2'>Configuration of crash 2</crash>
</crashes>
<infos>
Configuration section of infos.
Note that this section must be configured after triggers and logs, as
infos depend on these two sections.
<info id='1'>Configuration of info 1</info>
<info id='2'>Configuration of info 2</info>
</infos>
</conf>
As for the definition of sender, trigger, crash and info
please refer to acrnprobe.
Properties of group members¶
acrnprobe defined different groups in configuration file, which are
senders, triggers, crashes and infos.
Common properties¶
id: The index, which grows from 1 consecutively, in its group.enable: This group member will be ignored if the value is NOTtrue.
Crash tree in acrnprobe¶
There could be a parent-child relationship between crashes. Refer to the diagrams below, crash B and D are the children of crash A, because crash B and D inherit from crash A, and crash C is the child of crash B.
Match crash at runtime¶
In order to find a more specific type, if one crash type matches
successfully acrnprobe will do a match for each child of it (if it has any)
continually, and return the last successful one.
About how to determine a match is successful, please refer to the content of
Crash.
Supposing these crash trees are like the diagram above at runtime:
If a crash E is triggered, crash E will be returned immediately.
If a crash A is triggered, then the candidates are crash A, B, C and D.
The following diagram describes what acrnprobe will do if the matched
result is crash D.
Figure 50 Match crash at runtime¶
Sections¶
Sender¶
Example:
<sender id="1" enable="true">
<name>crashlog</name>
<outdir>/var/log/crashlog</outdir>
<maxcrashdirs>1000</maxcrashdirs>
<maxlines>5000</maxlines>
<spacequota>90</spacequota>
<uptime>
<name>UPTIME</name>
<frequency>5</frequency>
<eventhours>6</eventhours>
</uptime>
</sender>
name: Name of sender.acrnprobeuses this label to distinguish different senders. For more information about sender, please refer to acrnprobe.outdir: Directory to store generated files of sender.acrnprobewill create this directory if it doesn’t exist.maxcrashdirs: The maximum serial number of generatedcrash directories,stat directoriesandvmevent directories. The serial number will be reset to 0 if it reaches the specified maximum (maxcrashdirs). Only used by sender crashlog.maxlines: If the number of lines in thehistory_eventfile reaches the specifiedmaxlines, thehistory_eventfile will be renamed tohistory_event.bakand logging will continue with a now emptyhistory_eventfile.spacequota:acrnprobewill stop collecting logs if(used space / total space) * 100 > spacequota. Only used by sender crashlog.uptime: Configuration to triggerUPTIMEevent. sub-nodes:name: The name of event.frequency: Time interval in seconds to triggeruptimeevent.eventhours: Time interval in hours to generate a record.
Trigger¶
Example:
<trigger id="1" enable="true">
<name>t_pstore</name>
<type>node</type>
<path>/sys/fs/pstore/console-ramoops-0</path>
</trigger>
<trigger id="2" enable="true">
<name>t_acrnlog_last</name>
<type>file</type>
<path>/tmp/acrnlog/acrnlog_last.[*]</path>
</trigger>
name: The name of trigger. It’s used by crash and info configuration module.typeandpath: These two labels are used to get the content of trigger files.typehave been implemented:node: It means thatpathis a device node on virtual file system, which cannot supportmmap(2)-likeoperations.acrnprobecan use onlyread(2)to get its content.file: It means thatpathis a regular file which supportsmmap(2)-likeoperations.dir: It means thatpathis a directory.rebootreason: It means that the trigger’s content is the reboot reason of system. The content ofrebootreasonis not obtained in a common way. So, it doesn’t work withpath.cmd: It means thatpathis a command which will be launched byexecvp(3).
Some programs often use format
string%dinstead of static file name to generate target file dynamically. Sopathsupports simple formats for these cases:- /…/dir/string[*] –> all files with prefix “string” under dir.
- /…/dir/string[0] –> the first file of files, sorted by
alphasort(3), with prefix “string” under dir. - /…/dir/string[-1] –> the last file of files, sorted by
alphasort(3), with prefix “string” under dir.
Example of formats: If there are 4 files under
/tmp:acrnlog_last.1acrnlog_last.2acrnlog_last.3other.txt/tmp/acrnlog_last.[-1]indicatesacrnlog_last.3./tmp/acrnlog_last.[0]indicatesacrnlog_last.1./tmp/acrnlog_last.[*]indicates the file set includingacrnlog_last.1,acrnlog_last.2andacrnlog_last.3.
Vm¶
Example:
<vm id="1" enable="true">
<name>VM1</name>
<channel>polling</channel>
<interval>60</interval>
<syncevent id="1">CRASH/TOMBSTONE</syncevent>
<syncevent id="2">CRASH/UIWDT</syncevent>
<syncevent id="3">CRASH/IPANIC</syncevent>
<syncevent id="4">REBOOT</syncevent>
</vm>
name: The name of virtual machine.channel: Thechannelname to get the virtual machine events.interval: Time interval in seconds of polling vm’s image.syncevent: Event typeacrnprobewill synchronize from virtual machine’scrashlog. User could specify different types by id. The event type can also be indicated bytype/subtype.
Log¶
Example:
<log id="1" enable="true">
<name>pstore</name>
<type>node</type>
<path>/sys/fs/pstore/console-ramoops-0</path>
</log>
name: By default,acrnprobewill take thisnameas generated log’s name inoutdirof sender crashlog. Ifpathis specified by simple formats (includes [*], [0] or [-1]) the file name of generated logs will be the same as original. More details about simple formats, see Trigger.typeandpath: Same as Trigger.lines: By default, all contents in the original will be copied to generated log. If this label is configured, only thelinesat the end in the original will be copied to the generated log. It takes effect only when thetypeisfile.
Crash¶
Example:
<crash id='1' inherit='0' enable='true'>
<name>UNKNOWN</name>
<trigger>t_rebootreason</trigger>
<channel>oneshot</channel>
<content id='1'>WARM</content>
<log id='1'>pstore</log>
<log id='2'>acrnlog_last</log>
</crash>
<crash id='2' inherit='1' enable='true'>
<name>IPANIC</name>
<trigger>t_pstore</trigger>
<content id='1'> </content>
<mightcontent expression='1' id='1'>Kernel panic - not syncing:</mightcontent>
<mightcontent expression='1' id='2'>BUG: unable to handle kernel</mightcontent>
<data id='1'>kernel BUG at</data>
<data id='2'>EIP is at</data>
<data id='3'>Comm:</data>
</crash>
name: The type of thecrash.trigger: The trigger name of the crash.channel: The name of channel crash use.contentandmightcontent: They’re used to match crash type. The match is successful if all the following conditions are met:- All
contentswith differentidsare included in trigger’s content. - One of
mightcontentswith the sameexpressionis included in trigger’s content at least. - If there are
mightcontentswith differentexpressions, each group with the sameexpressionshould meet condition b.
- All
log: The log to be collected. The value is the configurednamein log module. User could specify different logs byid.data: It is used to generateDATAfields incrashfile.acrnprobewill copy the line which starts with configureddatain trigger’s content toDATAfields. There are 3 fields incrashfileand they could be specified byid1, 2, 3.
Info¶
Example:
<info id='1' enable='true'>
<name>BOOT_LOGS</name>
<trigger>t_boot</trigger>
<channel>oneshot</channel>
<log id='1'>kmsg</log>
<log id='2'>cmdline</log>
<log id='3'>acrnlog_cur</log>
<log id='4'>acrnlog_last</log>
</info>
name: The type of info.trigger: The trigger name of the info.channel: The name of channel info use.log: The log to be collected. The value is the configured name in log module. User could specify different logs by id.