Context
While building Docker/Podman support into ovos-tui-client, confirmed directly: ovos_utils.log/ovos_utils.log_parser (the ovos-logs CLI) has no Docker/Podman awareness at all - purely file-based, same blind spot this project itself had until recently. On an install following ovos-docker's own documented example config ("logs": {"path": "stdout"}), there are no log files on the host at all - only container stdout - so ovos-logs currently has nothing to work with there.
What we found works, tested against a real ovos-docker install (26 containers)
Rather than tailing each container separately (26 containers = 26 separate things to track, most of them one-off skill containers), we map container names to the SAME small set of categories file-based installs already use - skills, audio, voice, bus, phal, plus a catch-all other - and have every container in a category append to the SAME shared log file (e.g. every ovos_skill_* container's docker logs -f output lands in one shared skills.log). Concurrent appends from multiple docker logs -f subprocesses to one file are safe without locking (POSIX guarantees atomic writes under PIPE_BUF with O_APPEND, true for any normal single log line).
Confirmed against a real, running install:
ovos_skill_* (any suffix) and ovos_core -> skills (the latter because its own log content is exactly what already lands in skills.log on a normal install - confirmed by comparing real log line prefixes)ovos_audio -> audioovos_listener -> voiceovos_messagebus -> busovos_phal/ovos_phal_admin -> phal- anything with "gui" in the name ->
gui
- anything else (
ovos_cli, ovos_plugin_ggwave, confirmed via the same install) -> other
Working, tested reference implementation: https://github.com/andlo/ovos-tui-client/blob/main/ovos_tui_client/services.py (categorize_container_name(), start_container_log_bridges(), stop_container_log_bridges()) - happy to adapt/PR this into ovos_utils.log directly if that's useful, or just leave this here as a pointer if ovos-logs would rather take a different approach.
Possibly also relevant
Separately (not really an ovos-logs fix, more a heads-up): on the systemd/venv install we tested against, ovos-messagebus runs as a native Rust binary and logs via stdout/the journal, not a file at all - so there's genuinely no bus.log on some installs even outside the Docker case. Not sure if that's already known/intentional.
Context
While building Docker/Podman support into
ovos-tui-client, confirmed directly:ovos_utils.log/ovos_utils.log_parser(theovos-logsCLI) has no Docker/Podman awareness at all - purely file-based, same blind spot this project itself had until recently. On an install followingovos-docker's own documented example config ("logs": {"path": "stdout"}), there are no log files on the host at all - only container stdout - soovos-logscurrently has nothing to work with there.What we found works, tested against a real ovos-docker install (26 containers)
Rather than tailing each container separately (26 containers = 26 separate things to track, most of them one-off skill containers), we map container names to the SAME small set of categories file-based installs already use -
skills,audio,voice,bus,phal, plus a catch-allother- and have every container in a category append to the SAME shared log file (e.g. everyovos_skill_*container'sdocker logs -foutput lands in one sharedskills.log). Concurrent appends from multipledocker logs -fsubprocesses to one file are safe without locking (POSIX guarantees atomic writes underPIPE_BUFwithO_APPEND, true for any normal single log line).Confirmed against a real, running install:
ovos_skill_*(any suffix) andovos_core->skills(the latter because its own log content is exactly what already lands inskills.logon a normal install - confirmed by comparing real log line prefixes)ovos_audio->audioovos_listener->voiceovos_messagebus->busovos_phal/ovos_phal_admin->phalguiovos_cli,ovos_plugin_ggwave, confirmed via the same install) ->otherWorking, tested reference implementation: https://github.com/andlo/ovos-tui-client/blob/main/ovos_tui_client/services.py (
categorize_container_name(),start_container_log_bridges(),stop_container_log_bridges()) - happy to adapt/PR this intoovos_utils.logdirectly if that's useful, or just leave this here as a pointer ifovos-logswould rather take a different approach.Possibly also relevant
Separately (not really an
ovos-logsfix, more a heads-up): on the systemd/venv install we tested against,ovos-messagebusruns as a native Rust binary and logs via stdout/the journal, not a file at all - so there's genuinely nobus.logon some installs even outside the Docker case. Not sure if that's already known/intentional.