This is a listing and brief explanation of the various results logs available through autotest. It is in no way comprehensive, and is only meant as an introduction to the topic.
High Level Overview:
1. Test runs and dumps its results into /usr/local/autotest/results
2. Server job pulls this entire directory back via log_collector.collect_client_job_results. This does an rsync from the server results dir to the client results dir.
3. GSoffloader uploads these results to google storage.
The rest of this document describes how step 1 occurs, to learn more about the server job or gsoffloader please consult relevant documents.
How are these logs created?
Sysinfo logs are created by executing a command in a subprocess and redirecting it’s stdout to the appropriate file through base_sysinfo.py run(), examples of such commands are 'ls -l /boot' and '/opt/google/chrome/chrome --version', or just executing something like shutil.copyfile through a hook. There are 4 types of hooks:
How does job.run_test trigger one of the loggables?
job.run_test creates a _sysinfo_logger through server/test.py
Before invoking common_lib/test.py runtest, it sets up sysinfo logging by:
How do I collect a random directory as a result?
You should add it as a loggable hook. Say you would like to collect some directory every test iteration, you will first need:
Once you've picked a class and hook:
What follows is an inspection of directories we pull back from the DUT:
The collection of these logs happens through site_sysinfo, base_sysinfo. client/bin base_sysinfo has a set of default commands to run per test/boot/iteration and sets them in base_sysinfo __init__.
----logs from cc files grouped by function.eg: power_manager directory contains log messages from files input.cc, powerd.cc etc. The redirection of their output occurs through LOG macros (eg chromium/src/base/logging.cc: ~307), and autotest pulls the new contents of ‘/var/log’ generated during the test in its log_after_* hooks using site_sysinfo.diffable_logdir (which rsyncs).
On every crash we get a minidmp on the DUT, the server pulls this file back and attempts to symbolicate it with symbols in /build/ and the devserver. how does the server know theres a crash, where does it go looking for a crash dump file and what generates a dump file.
Normal minidumps are uploaded to a crash server which attempts to produce a stack trace txt file. Autotest tries to run stacktrace with the appropriate symbols on a crash server.
[base_sysinfo in bin/base_sysinfo.py]
boot_loggables-cmdline, installed_packages, proc_mounts, uname, meminfo, slabinfo, version, pci, cpuinfo, modules, interrupts, partitions, lspci -vn, gcc--version, ld--version, mount, hostname, uptime.
test_loggables-df, dmesg, installed_packages, schedstat, meminfo, slabinfo, interrupts
If you have come this far, you may also be interested in reading the autotest client tests codelab.