Error Addon Log

With each add-on, it shows me the following message in the protocol.

  • Core2024.10.4
  • Supervisor2024.10.4
  • Operating System13.2
  • Frontend20241002.4

I also have this problem. The error I get is

Failed to get XXX_addon_XXX logs, e.callApiRaw is not a function

  • Core 2024.10.4 (or 2024.11.0b2)
  • Supervisor 2024.10.4
  • Operating System13.2
  • Frontend 20241002.4

I misspoke. This appears to be fixed in the 2024.11.0b2 release. Give that a try!

Just updated to Supervisor 2024.11.2 and am seeing this for all add-ons - although this release may be just when I noticed it first.

Running Supervised install, on Bookworm.

  • Core 2024.10.4
  • Supervisor 2024.11.2
  • Operating System
  • Frontend 20241002.4

Failed to get core_mariadb logs, e.callApiRaw is not a function. (In 'e.callApiRaw("GET",hassio/${t.includes(“_”)?addons/${t}:t}/logs${0!==r?/boots/${r}:“”},void 0,i?{Range:i}:void 0)', 'e.callApiRaw' is undefined)

Update: Requesting logs for Add-ons fails · Issue #5382 · home-assistant/supervisor · GitHub

The 11.2 supervisor update broke all my addon logs.

I just tried to install the 11.2 update, and I get an error message that it doesn’t exist. So I wonder if it got pulled?

UPDATE: Never mind, apparently it did get updated. Very weird.

Yes - saw similar:

  • (1) Update available
  • Install Supervisor 2024.11.2
  • (1) Update available (still)
  • (lots of front end refreshing)
  • Settings → System → Updates → Supervisor 2024.11.2 still showing
  • Settings → System → Updates → G refresh icon top right
    • Checking for updates...
    • (a few seconds later…)
    • No updates available

Appears to take a while for HA to communicate with the Supervisor that an update has taken place? :man_shrugging:

Same issue here too. All add-on logs are affected.

Same issue.

Check here: Error: Add On Logs are no longer displayed - error message: e.callApiRaw is not a function - #5 by mwiedmaier

We need to update core to 2024.11.0

Many thanks.
With update core to 2024.11.0, now is ok

I just updated from core 10.4 to 11.1 and still have this problem.
Supervisor is also at the latest 11.3.
OS on 13.2.
Does this mean that the fix is only applied when updating from 10.4 to 11.0?

OK you can discard this post, after some time after updating the problem was automatically fixed, Logs are working again!

Did you change anything? I am still having this issue on all my addons and I just updated to the latest that just was released.

It popped out again recently, I am internally blaming Core 12.1 version, Downgrading to 12.0 and will update here

Update: Core 12.0 works fine.

It seems to me that the issue is with trying to access logs through a reverse proxy. If I use my internal URL I have no issues, if I use my reverse proxy address it hangs and maybe after 5 minutes the live logs show up. I can’t find anything in my nginx logs that points to it being an issue with my reverse proxy logs (I use SWAG).

1 Like

FYI there appears to be a fix coming out as someone has located where the funkiness is happening.

For those running something that uses nginx for proxy you can most likely add proxy_buffering off to your proxy config and resolve it in the meantime.

If you use swag you can made the edit directly in your Home Assistant proxy config that SWAG maintains.

go to the SWAG wag\config\nginx\proxy-confs folder and locate the Home Assistant proxy config.

In this section of the config

    location ~ ^/(api|local|media)/ {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.56;
        set $upstream_port 8123;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
	}

Add
proxy_buffering off;
as show below.

    location ~ ^/(api|local|media)/ {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.56;
        set $upstream_port 8123;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
        proxy_buffering off;
	}