Investigate a service

Run a throwaway nginx container on a dev host, then let your agent inspect it and request a restart. You approve the restart in emisar and check the result.

1. Start a test container#

Start nginx in a container and check that it answers:

docker run -d --name emisar-demo -p 8080:80 nginx:alpine
curl -sI http://localhost:8080 | head -1

You should see HTTP/1.1 200 OK. The runner also needs access to the Docker daemon. Add its user to the docker group and restart the runner, as the docker pack's setup describes:

sudo usermod -aG docker emisar
sudo systemctl restart emisar

Open the host in Runners and confirm that docker.ps, docker.logs, and docker.restart are available. The docker pack has 28 actions: 16 low risk, 3 medium, 8 high, and 1 critical.

2. Check the approval rule#

In Policies, inspect the policy that applies to this runner. With the shipped defaults, docker.ps (low risk) and docker.logs (medium) run on their own, and docker.restart (high) waits for approval.

Check that no action override or standing grant (a reusable approval) lets the restart run on its own. See policies and approvals.

3. Ask the agent to investigate#

Use the runner name shown in the console. For example:

Use emisar to check the emisar-demo container on runner dev-box.
List the containers, then read its recent logs. Summarize what you find.
Do not restart it yet.

The agent finds docker.ps and docker.logs and runs them without asking you. This is what came back in our test; the nginx log includes the curl request from step 1:

docker.ps · exit 0
CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                                     NAMES
12d88303806d   nginx:alpine   "/docker-entrypoint.…"   58 seconds ago   Up 58 seconds   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp   emisar-demo

docker.logs · exit 0
/docker-entrypoint.sh: Configuration complete; ready for start up
192.168.215.1 - - [29/Oct/2026:04:00:28 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.7.1" "-"

In Runs, check the target, actions, arguments, and output of each call. If a call is denied or fails, fix the problem it shows before you continue.

4. Request a restart#

Restart the emisar-demo container on dev-box through emisar.
Reason: try the approval flow on a test container.
Wait for the result. Do not send another restart while this one is pending.

emisar answers the agent with pending_approval and a link to the approval. Open Approvals. The restart waits there, and the container is still running. If it ran right away, check the policy and grants before you try again.

5. Review the approval#

The approval shows the risk (high), your runner, and the exact command: docker restart -t 10 emisar-demo. Below it are the agent's reason and why the request stopped: "The account policy requires approval for high-risk actions by default." Leave "Allow the agent to reuse this approval" off, then approve this one run. If anything looks wrong, deny it.

By default you can approve your own request. If your team requires another approver or several votes, follow that rule. After you approve, let the agent wait for the result of the original request instead of sending a new one.

6. Verify and clean up#

Open the run and wait for its result. Exit code 0 means docker restart finished, and its output is just the container name, emisar-demo. Ask the agent to list the containers again. In our test, the STATUS column then read Up 16 seconds while CREATED still said about a minute ago. Then check nginx yourself:

curl -sI http://localhost:8080 | head -1

You should see HTTP/1.1 200 OK again.

Open Audit. Newest first, it lists the second docker.ps, then "Run succeeded" for docker.restart, "Approval granted", "Approval decision recorded", and "Run awaiting approval", followed by the earlier reads. When you are done, remove the container and the runner's Docker access:

docker rm -f emisar-demo
sudo gpasswd -d emisar docker
sudo systemctl restart emisar