Skip to content

[Feature] Allow the background log path to be specified #692

Description

@cancan101

What

comfy launch --background writes ComfyUI's output to
<workspace>/user/comfyui_<port>.log, and there is currently no way to ask for a
different path. A --log-file option on launch, or an env var honoured by
background_log_path(), would let a supervising process keep that log wherever it
keeps its others.

Why

comfy-cli is increasingly something else starts — a project launcher, a dev
script, a systemd unit. Those supervisors usually have one convention for where
their managed services log (/tmp/<name>.log, /var/log/<name>/, a run
directory), and ComfyUI is the one participant whose log lands somewhere else, in
a location that also moves with the workspace.

In our case (a launcher that starts piper / ollama / a Chatterbox bridge / ComfyUI
side by side) every other helper announces (logs: /tmp/<name>.log) on startup
and points back there on failure. ComfyUI can't, so we symlink /tmp/comfyui.log
at comfy-cli's file instead. That works fine — this is a convenience request, not
a defect report.

Current state, for reference

  • launch exposes --background and --frontend-pr; no log option.
  • background_launch() computes log_path = background_log_path(port)
    unconditionally.
  • The background_log config key looks like it might be an input, but it's
    written by comfy-cli after launch and read back only by comfy logs to locate
    the file.

Suggested shape

Either is fine; the env var alone would cover the supervisor case:

def background_log_path(port, workspace: str | None = None) -> str:
    override = os.environ.get("COMFY_BACKGROUND_LOG")
    if override:
        return os.path.abspath(override)
    ...

One thing worth preserving

_open_log_for_write() opens with O_NOFOLLOW so a pre-placed symlink in
<workspace>/user can't be used to clobber its target — a good defence, and an
override path should keep it rather than special-casing "trusted" locations. Worth
saying explicitly in the docs for such an option: the override must be a real
file path, not a symlink
, or the launch fails with ELOOP.

That behaviour is also why the workaround has to point the other way (a symlink
at comfy-cli's file, never the workspace path symlinked outward) — which is
easy to get backwards, and might deserve a line in the comfy logs docs
regardless of whether this request is taken up.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions