Antithesis’ multiverse debugger gives you two superpowers.
You can time-travel to pull information from the past, present, or future of a reproduction of your bug, with extreme precision. This allows you to ask questions like:
What was the last network packet that was sent before your process died?
What was the internal state of your Raft algorithm at the moment a leader has been chosen?
What was the eventual health-check result of your system after minutes of quiescence?
You can also do destructive analysis, interacting with the system without fear of losing your reproduction. You can take actions like:
Cause a core dump by killing a key process.
Take down all secondary nodes and see if a suspected race condition still occurs.
First choose to step-over in your debugger and later choose to step-into.
If you’re here to debug a crashed process, get the pid of that process from the logs. Container processes have two pids, one found in the host machine and another in the container. The pid obtained from the logs is the host pid. For most debugging use-cases, you’ll want the container pid.
#!/usr/bin/env bashhpid=1275# Get all pids of the target process in the namespaces it participates in# This command is run on the host machinegrep NSpid /proc/$hpid/status
#!/usr/bin/env bash# if you know the process nameprocess_name="slirp4netns"ps --format pid --no-headers -C $process_name | head -n 1# If you have `psgrep` inside of your target container, that could be more ergonomicpgrep $process_name
If you’re here to investigate a process crash, here’s how to get the container id that was running the crashed process.
Grab the host pid of the crashed process from the logs.
Enter a time that’s a few seconds before that process crash.
Select the (host) container.
Run the following script.
#!/usr/bin/env bashhpid=1275cat /proc/$hpid/cgroup` | grep -o 'libpod-[^.]*' /proc/$hpid/cgroup | sed 's/libpod-//'# Containers are placed into distinct cgroups, so you can get the container id from the process's cgroup information# The output will look similar to # 0::/machine.slice/libpod-<container-id>.scope# The important part is: "libpod-<container-id>.scope" to get the container id# Optional: Inspect the container to find the image name, container name# podman inspect <container-id>
The Extract file button lets you print the output of a process or command with one click.
If you want to extract the output of a process or command ran in the MVD, you can chain the two steps by writing a bash script and providing the path to the file to extract and run them together. Running them separately will not work.
If the file you want to extract already exists in a container, just specify the path to it.
Any set of debugging steps that you perform in one of your multiverse debugging sessions can be converted into a script that automatically runs in every one of your tests when a certain kind of bug is found. The results, output, artifacts, etc. are automatically attached to your triage report in the bug details section.
Suppose you often want to know what’s happening in your network three seconds before a segmentation fault. Our triage report can autonomously gather this information for you and have it ready when you open the report. You can still use the Multiverse debugger for the truly hard cases where your scripted steps don’t work.