When looking at the full logs in the UI the most recent info is at the bottom of the page.
The refresh for the full logs is near the top, so when wanting to keep an eye on what is happening you keep scrolling up to refresh and back down again to see what is new which is annoying.
Yes please! Or better yet, just have the logs auto scroll without an update button.
4 Likes
Wherever the most recent log entry is shown (top or bottom), the refresh button should be nearby
3 Likes
I’d quite like a popout log window.
Also, being able to get a download of the whole log file.
1 Like
Maybe I am looking at the wrong “Logs” but in my view the most recent logs are at the top yet the clear/refresh buttons are at the bottom. I have to scroll all the way down to see them.
I concur with @uSlackr :
Actually its being worked on:
But don’t expect it for a bit. Have had some setbacks. Was all set up to merge APIs which supported tailing the logs and then realized the systemd-journal-gatewayd service removes all the color-coding 
So /host/logs will have the required API support for this soon but have to go back to the drawing board for the other log endpoints. And then once that happens the frontend will need to update to use it. soonTM 
In the meantime though, would really like this WTH as well.
Are we going to get Actual logs or the fancy UI BS logs that don’t show info or debug?
What you’re showing isn’t really the logs. I mean it comes from the logs but that’s a separate piece. Core keeps track of logged warnings and errors, aggregates ones it deems similar and shows that information at the top. That’s what you’re showing there.
What the author is asking for is when you click “Show full logs” (which shows the actual logs for core unprocessed) underneath that for there to be a refresh button at the very bottom. Also if you change the logger in the top right to anything else it simply shows the full logs for that logger. And again, the refresh button is annoyingly at the top rather then the bottom.
1 Like
Are you referring to the blurb at the top of core logs? If so then no, nothing to do with that, that’s all core.
Currently supervisor has /logs APIs for core, supervisor, the plugins, each addon, and host. All except host basically do a docker logs <name> and show the result. /host/logs shows dmesg for the system.
After the PR /host/logs will return logs directly from the system journal for a pre-specified list of syslog identifiers. Along with new APIs to get the journal logs for a particular identifier or particular boot. I wanted to change the others to basically do a journalctl -t <name> as well since then they could show all logs for the thing across restarts of the container. But that broke color-coding so I had to revert it.
These APIs are used for every logger listed in the top right in a system with Supervisor. Except maybe core, I’m not sure about that one. Core can be used in a container or core install so obviously it can’t ask Supervisor in those situations (or docker since it doesn’t have permission). So I’m not sure if it calls the /core/logs API when supervisor exists and does something else otherwise or always does the same thing. Stuff to research once the APIs exist.
Of course whether any of this shows info or debug level logs is a separate question entirely. If you set log level to warning then logs of a lower level still won’t show up. But if you set it to debug then yea you see everything.
I’m referring to the nicely formatted logs that you have to expand and copy from. Not the actual log lines inside the log file. They are pretty-ified errors. Personally, I’m looking for the logs that are directly output by the logging library in python, or logs that go directly to stdout.
1 Like
Yea we’re on the same page. The APIs I’m referring to return the real logs.
FYI in a system with supervisor its a requirement to use journal logging. So stdout of all the containers goes into the system journal. You can poke around in this by following this guide. Or by using journalctl from the host shell.
You can also get to the docker logs by doing ha core logs, ha supervisor logs, ha addons logs <slug>, etc. But the downside is that only shows logs for the current container. Which usually means you only see the logs since the last time you restarted that thing.
Yeah, I already do that using LogExpert over SSH. But I can’t do that when I’m at work
Ah. Well good news then, the PR I linked is in. Once it gets to supervisor stable I’ll do a rewrite of that guide as it’ll be much easier. Not as easy as I want it to be but you’ll still be able to do things like this from the SSH addon:
-
ha host logs -t hassio_supervisor- Last 100 lines of supervisor logs -
ha host logs -t homeassistant -l 500- Last 500 lines of HA logs -
ha host logs -t addon_core_mosquitto -f- Show 100 lines of mqtt addon logs and then any new ones until you stop following
Color will be missing. And you’ll have to use the actual docker container name instead of the normal slug name which is annoying. But its the real logs across container restarts, you can choose how many lines you want and you can tail.
Anyway I guess this is just off-topic at this point so I’ll stop. But yea, some improvements coming.
1 Like
This does not seem to work anymore.
Error: unknown shorthand flag: ‘t’ in -t