Bashio is killed by "Use stdout for logging output" #169

[lmagyar]

cc @sairon

After #169 it is impossible to use bashio for anything programmatically!!!

If I call a bashio function to get any response on stdout AND debug is turned on, the response will be mixed with the DEBUG lines.

$ rm -f -r /tmp/.bashio/
$ bashio::network.interfaces 2>/dev/null
2025/11/05 00:50:09 DEBUG: Requested API resource: http://supervisor/network/info
2025/11/05 00:50:09 DEBUG: Request method: GET
2025/11/05 00:50:09 DEBUG: Request data: {}
2025/11/05 00:50:09 DEBUG: API HTTP Response code: 200
2025/11/05 00:50:09 DEBUG: API Response: {"result":"ok","data":{"interfaces":[{"interface":"end0","type":"ethernet","enabled":true,"connected":true,"primary":true,"mac":"DC:A6:32:F3:22:9E","ipv4":{"method":"static","address":["192.168.1.7/24"],"nameservers":["192.168.1.1"],"gateway":"192.168.1.1","ready":true},"ipv6":{"method":"auto","addr_gen_mode":"default","ip6_privacy":"default","address":["fe80::52b0:ee0b:12d7:2f2c/64"],"nameservers":[],"gateway":null,"ready":false},"wifi":null,"vlan":null,"mdns":"announce","llmnr":"announce"},{"interface":"wlan0","type":"wireless","enabled":false,"connected":false,"primary":false,"mac":"DC:A6:32:F3:22:9F","ipv4":{"method":"disabled","address":[],"nameservers":[],"gateway":null,"ready":false},"ipv6":{"method":"disabled","addr_gen_mode":"default","ip6_privacy":"default","address":[],"nameservers":[],"gateway":null,"ready":false},"wifi":null,"vlan":null,"mdns":null,"llmnr":null}],"docker":{"interface":"hassio","address":"172.30.32.0/23","gateway":"172.30.32.1","dns":"172.30.32.3"},"host_internet":true,"supervisor_internet":true}}

end0
wlan0

How can we use bashio after #169???

[coderabbitai]

A summary of the changes CodeRabbit can apply:

• Restore bashio logging to stderr by changing line 15 in lib/log.sh from exec {LOG_FD}>&1 to exec {LOG_FD}>&2, so debug/info logs are sent to fd 2 (stderr) and program output remains on stdout.

• Fix logging to stderr by changing lib/log.sh to duplicate stderr into LOG_FD (replace exec {LOG_FD}>&1 with exec {LOG_FD}>&2) and add docs/LOGGING_FIX.md explaining the issue, root cause, solution, and backward-compatibility implications.

• ✅ Create PR with these edits
• 📋 Get copyable edits

[felipecrs]

Yeah. I guess this slipped through. Making bashio output logs to stdout doesn't make sense as its stdout is used programmatically by scripts.

Some other solution needs to be found, perhaps at a level higher than the container itself. Not all addons use bashio.

In my opinion the best that can be done for now is to revert #169.

[lmagyar]

#172 and #173 made it to work, in theory.

Though I can't make any of my scripts in /urs/bin/ to work, if the shebang references bashio (#!/command/with-contenv bashio or #!/usr/bin/env bashio, etc), the log is in the captured output, if it references bash, none of the bashio functions work.

I run out of ideas.

How we are supposed to use bashio from now on???

[lmagyar]

cc @agners @PaulSD from #172

Can someone please explain what shebang should we use in scripts in /usr/bin to make it work? Currently these scripts either see the log in the captured stdout of a bashio function, or can't see bashio functions at all. I've tried all the shebangs I could come up, nothing works.

To be clear:

• S6 service scripts, healthcheck script, NetworkManager scripts starts with #!/command/with-contenv bashio
• They call /usr/bin scripts, and these scripts also call bashio functions and use their stdout
• What shebang should we use in these /usr/bin scripts to separate bashio's stdout from the debug/trace logs???

[PaulSD]

To answer your question directly - There are a few ways to use bashio in a script:

• #!/command/with-contenv bashio should be used in s6 service scripts. It probably won't hurt to use it for non-s6 scripts, but it is only really meant to be used for s6 service scripts.
• #!/usr/bin/bashio should work for non-s6 scripts.
• #!/usr/bin/env bashio is effectively the same as #!/usr/bin/bashio, except that it uses $PATH to find bashio instead of hard-coding the bashio path. If someone wanted to override bashio (eg. using /usr/local/bin/bashio) without modifying /usr/bin/bashio (or the shebangs in scripts that use bashio) then #!/usr/bin/env bashio would support that while #!/usr/bin/bashio would not.
• #!/bin/bash followed by source /usr/lib/bashio/bashio.sh. (You can also just run source /usr/lib/bashio/bashio.sh from an interactive bash shell, then use bashio functions directly in the shell.)

In all of those cases, bashio should behave the same. The specific shebang has no effect on function calls / output capture / logging behavior.

---

To clarify function call / output capture / logging behavior:

• If a bashio script is run as part of the docker startup process (run directly using the docker RUN command, or run by s6 at startup, etc) then everything should work as expected. Within the bashio script, function output and log output should not be mixed, but when the bashio script sends output to docker, both function output and log output will be sent to stdio to ensure that everything appears correct in docker container logs.
• If a bashio script is run at other times (eg. if you manually run a bashio script) then function output and log output still should not be mixed within the bashio script, but they will be mixed in the stdout of the bashio script. For example, a script containing ifs=$(bashio::network.interfaces) should work properly, but a script containing only #!/usr/bin/env bashio followed by bashio::network.interfaces (with the output of that script captured by some other process) will have function and log output mixed in the stdout of that command. As a work-around, you can call a bashio script using LOG_FD=2 <script> to explicitly send log output to stderr instead of mixing it into stdout. Note that Allow child bashio processes to access the parent LOG_FD variable #174 (not merged yet) helps with this (eliminating the need to explicitly set LOG_FD in some cases).

---

To explain the behavior you showed in #177 (comment):

The problem here is that logs do NOT go to stderr (fd 2), so redirecting 2>/dev/null doesn't do anything.

$ source /lib/bashio/bashio.sh
$ bashio::log.level trace
$ bashio::network.interfaces
[10:20:08] TRACE: bashio::network.interfaces
<more log messages>
eno0
$ echo $LOG_FD  # Note that this may not always be 10, but it is in this example
10
$ bashio::network.interfaces 10>/dev/null
eno0
$

However, in most cases, rather than suppressing the logs, you should simply capture only stdout:

$ ifs=$(bashio::network.interfaces)
[10:20:08] TRACE: bashio::network.interfaces
<more log messages>
$ echo "$ifs"
eno0
$

[lmagyar]

Thank you for the detailed explanation. The first half was known for me. Though I was on a wrong track yesterday with the shebang.

Meantime I also located the root cause that I capture the output of my bashio scripts (under /urs/bin), and realized that LOG_FD "propagation" has some problem, and then I read your reference to #174, that I didn't noticed yesterday. That gave the solution!!! Thank you!!!

I've added export LOG_FD to the beginning of all of my scripts (s6 or not), and now eg. works.