Logs & diagnostics

Oink keeps logs and crash reports on your own computer. Nothing is sent anywhere: when you want to report a problem, you make a bundle, look inside it, and decide where it goes. See What we collect.

Where the logs areCopy Anchor Link

OPENCOMP_LOG_DIR=<folder> puts them somewhere else (render farm nodes, tests). Help › Open Log Folder opens it.

The log formatCopy Anchor Link

One JSON object per line, the same fields in every process, so one search finds a problem across all of them:

{"ts":"2026-09-28T10:41:02.113Z","level":"warn","proc":"engine","session":"a1b2c3d4e5f6",
 "version":"0.1.0","pid":1234,"event":"request_failed","msg":"node_delete failed: ...","req":"req_12"}

• session is the same in every process of one launch.
• req is the request id of an engine command, so a UI action and the engine error it caused line up.
• Each file is rotated at 10 MB; the 5 previous files are kept (ui.jsonl.1 … ui.jsonl.5).
• OPENCOMP_LOG_LEVEL = error, warn, info (default) or debug, like Nuke's FOUNDRY_LOG_LEVEL.

Local logs keep full file paths and node names: they are your files, and that is what makes them useful for debugging. Names and paths are removed only when you make a bundle.

When something crashesCopy Anchor Link

• The engine restarts by itself and restores your comp (a banner says so). Its crash log, its Python stacks and Blender's crash report are kept in the log folder.
• The application itself: at the next start a small note appears at the bottom right: "Oink closed unexpectedly". It never blocks you. View Report shows when it happened, the crash files and the last errors of that session. Copy Diagnostic Bundle… makes a bundle.
• Native crash dumps are written by Electron's crash reporter with uploading turned off.

Copy Diagnostic BundleCopy Anchor Link

Help › Copy Diagnostic Bundle… collects, in one zip:

• system.json: operating system, CPU, RAM, GPU and driver, versions (application, engine, Blender if installed, Python, Electron, OpenImageIO, OpenColorIO)
• policy.json: the studio policy in effect (below)
• prefs.json: a short list of preference values; for anything else only whether it is set
• sessions.json: crash-free sessions over the last 30 days
• logs/: the last 2,000 lines of each log, recent engine crash logs, the AI worker output, the last start-up report
• crashes/: crash reports of the last 7 days
• manifest.json: every file and why it is there

The dialog lists the files of the zip; click one to read exactly what is in it. Save Bundle… writes the zip where you choose and copies its path.

What is removedCopy Anchor Link

The hashes use a random key made for each bundle, so a hash cannot be matched against a list of show names. Before the zip is written, every file is checked once more; a file that still holds a secret, an email or a known name is left out (the dialog says so).

Native crash dumps are not included unless you tick Include native crash dumps: they hold raw process memory, which cannot be redacted.

On a render farm nodeCopy Anchor Link

./render.sh --diag-bundle [--out node42.zip] [--include-dumps]

writes the same bundle without the application (--out names the zip). Nothing is sent. Two bundles built at the same time no longer clash over a shared temporary file.

Report a BugCopy Anchor Link

Help › Report a Bug… takes a title and a description, saves a bundle, and opens a pre-filled GitHub issue page in your browser with your text and a short system summary (version, OS, GPU, RAM; no names or paths). Nothing is uploaded: attach the bundle to the issue yourself if you want to. Save Report Only… just saves the bundle, for studios that send reports through their own channels.

The optional screenshot is off by default. When you tick it, the Viewer, the node graph and thumbnails are blacked out, because they can show client images. Untick Black out… only if you are allowed to share what is on screen.

Studio policyCopy Anchor Link

An administrator can set one policy file for every workstation, the same way as the AI policy:

• $OPENCOMP_POLICY, else
• /etc/opencomp/policy.json (Linux), /Library/Application Support/opencomp/policy.json (macOS), %ProgramData%\opencomp\policy.json (Windows)

{
  "locked": true,
  "offline": true,
  "crash_reports": "local",
  "usage_counts": "off",
  "bug_report": "file",
  "updates": "off",
  "log_level": "info",
  "crash_handling": true
}

Order: a locked admin file, then environment variables, then the user's ~/.config/opencomp/policy.json, then an unlocked admin file, then the defaults. Switches that only take things away always work, even under a locked file:

• OPENCOMP_OFFLINE=1: offline.
• DO_NOT_TRACK=1: usage counts off, crash reports local.
• OPENCOMP_CRASH_HANDLING=0: no crash dumps or Python stacks.

What offline turns offCopy Anchor Link

When the policy says offline, every feature that could reach the internet refuses with a message that says so and where the switch is set (for example "Model download is off: … runs offline here (set by OPENCOMP_OFFLINE=1)"). Nothing is attempted, not even a DNS lookup.

1. AI model downloads, and reading the Hugging Face token.
2. Sample downloads (Help > Examples).
3. The online documentation, when no local copy is installed.
4. Links to web pages (licences, the "Open Issue Page" button of Report a Bug).
5. Cloud AI assistant providers.
6. Installing the AI packages or the ComfyUI extras (they install from the local package cache only).
7. The Nukepedia index tool.
8. Update checks, crash upload and usage counts (none exist yet; they will ask the same guard).

Hosts inside the studio keep working: this machine, private and link-local addresses, single-word host names and *.local, *.lan, *.internal names. So the LAN render farm, a local ComfyUI or LLM server and the GPU lease still work.

The backend and the AI worker also refuse outbound connections at the socket level, and the app window refuses web requests, so a library that forgets to ask is stopped too.