Service logs (OliveTin process troubleshooting)

Service logs are the lines OliveTin prints while it runs—startup messages, configuration load, errors, and action output. They are separate from browser console logs, which come from the WebUI in your browser.

When something fails on the server (OliveTin will not start, actions error, API or auth problems), sharing recent service log output helps others see what the process reported. You do not need to be a Linux expert to copy logs from Docker, Podman, or journalctl.

Before posting publicly, scan the log text for passwords, API tokens, cookies, or internal hostnames. Remove or replace those strings if needed. If you enable extra debug logging, output can be more sensitive than usual.

Where logs come from

How you read logs depends on how OliveTin is installed:

  • Container (Docker / Podman): logs are what the container runtime captured from OliveTin’s standard output.

  • systemd service: logs are stored by the system journal for the OliveTin unit.

  • Manual / binary (for example ./OliveTin in a terminal): messages print to that terminal—copy them from there, or redirect output to a file when testing.

Manual or binary run

If you start OliveTin directly in a terminal window, scroll back and copy the text from startup through the error, or run it again and capture output:

./OliveTin 2>&1 | tee olivetin-run.log

That writes everything to olivetin-run.log while still showing it on screen. Stop OliveTin before sharing, then attach or paste the relevant part of the file.

Docker and Podman

Use the same container name you chose when you created the container (examples below use olivetin; yours may differ).

Show recent log lines (last ~200 lines)
docker logs --tail 200 olivetin

With Podman, use the same pattern:

podman logs --tail 200 olivetin

If OliveTin crashes on startup or you need the full story from a restart, show logs after reproducing the problem—either capture enough lines, or use a time window.

Limit output to the last few minutes (adjust the time as needed)
docker logs --since 10m olivetin

To watch logs live while you trigger an issue in another window:

docker logs -f olivetin

Press Ctrl+C to stop following; that does not stop OliveTin.

Docker Compose

From the directory that contains your compose.yaml (or docker-compose.yml):

docker compose logs --tail 200 olivetin

Use the service name from the compose file, not necessarily the container name. Add -f to follow logs live, same idea as above.

systemd (native Linux package)

Show whether the service is running and recent status:

systemctl status OliveTin

Read the journal for the OliveTin unit (scroll with arrow keys, quit with q):

journalctl -eu OliveTin

For a time-bounded slice (for example after a restart or failed action):

journalctl -eu OliveTin --since "30 minutes ago"

What to capture

  1. Reproduce the problem if you can (restart OliveTin, click the action, etc.), then collect logs immediately after.

  2. Include lines from startup through the error—not only the last one line.

  3. If the log is huge, prefer --since / --tail so the excerpt stays readable.

  4. Note your install type (Docker, Podman, Compose, systemd) and OliveTin version if you know it (from the WebUI footer, server diagnostics, or startup text).

For deeper server-side detail, you can temporarily enable LogDebugOptions—then capture logs again with those settings in mind.

Share the logs

Paste the text into a Discord or GitHub support message (or attach a .txt file if it is long). Together with how you run OliveTin (direct port, reverse proxy, container flags) and what you did before the error, service logs make backend issues much easier to diagnose than a screenshot of the WebUI alone.

For WebUI-only behaviour (blank page, buttons not loading), also capture browser console logs when relevant.