How to find interesting information outside of the user interface
These tips apply to both local installations and server installations, unless specified otherwise.
CI Fuzz usually builds, instrument and runs the software under test in Docker containers. Examining container logs can provide information depending on the application and type of fuzz tests. For Web Applications running in JVMs, you can check whether your application is starting and running correctly, what methods are instrumented and what http requests is the fuzz target sending to it (although for each logged request, a number of following ones is not logged to save space and performance). For C/C++ applications, you can spot problems with compilation or examine the output of your application/library.
When your fuzz test is running, use "docker ps" in your terminal to list containers:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
140d5da059bb maven "bash -eux -c 'expor…" 3 seconds ago Up 1 second watchcov-WebGoat-wwqapcbi
b96d1d35996d maven "bash -eux -c 'expor…" 5 seconds ago Up 2 seconds fuzz-WebGoat-lwtgjawo
9424d1c22539 mongo "docker-entrypoint.s…" About a minute ago Up About a minute 127.0.0.1:27000->27017/tcp ci-mongodb
Pick the container with name starting with fuzz-, followed by the name of your project. If you have two such containers, pick the second one. Then run docker logs, followed by this container name. Example:
docker logs fuzz-WebGoat-lwtgjawo
Now you can examine your build and fuzzing thoroughly.
If you have issues at the project creation stage, you can also examine the logs of build containers. These have the word "build" in their name.
When starting ci-daemon, you can increase log verbosity and see logs on standard error output by providing command line arguments:
$ ci-daemon -v2 --alsologtostderr
On a server, this is enabled by default. You can find the logs in systemd journal:
$ journalctl -u ci-server
However, when looking for messages from the software under test, it is recommended to look in docker logs instead, as they are more complete in that regard than ci-daemon logs.