I have a real-time application that runs on Ubuntu CORE and at times i need to see the printout of messages live as they happen. I typically use the SNAP LOGS command with -f to keep it going but its always super super slow and delayed. It reads from the log file too slow to be useful real time.
Does anyone know a way to read the log file realtime as it’s written in python by the snap?
It would not be worth the effort to design an entire ubuntu-frame GUI connection to display print info we write out in python. Hopefully there is a simple way.
Well, you can use journalctl directly to read any logs… If you need to do it from a snap, there is the log-observe interface that will provide access to the journalctl binary and the log.
It does not appear to be realtime. It feels like if you use SNAP LOGS -f or journalctl to view when a snap uses python to print(“message info here”), it does not write it instantly as it happens. It seems to wait 2-3 minutes before you can access the info.
Is this something built into snapd that it delays the writing of the log info for some reason? Is there a Ubuntu CORE snap recommended way to view REALTIME info printed in a python snap as it happens?
No, there should be nothing in the way, it might be python specific though, how do you write out the information from your app ? Just stdout or any specific logging module?
It’s just plain Python and uses a print(“text text text”). I have tons of print statements, one that runs every few seconds to check API status and such.
I just have always noticed when using snap logs -f or journalctl commands, they display what prints but in batches and only every few minutes. It’s never realtime like how the snap application is actually processing. Almost like it waits 2-3 minutes and buffers, then snapd writes the logs and starts over.
Since you’re using the raw basic print(), the printing is buffered when run as a daemon. I’d imagine dedicated logging libraries would flush the buffer more rapidly (especially if e.g., a string was designated an error or warning rather than just info).
-u should make it behave more comparably to when run interactively.
Ultimately this comes back to the C underlyings and is a problem that popups almost everywhere, even on different operating systems. If the output needs to be seen instantly then it needs to be force flushed, however most languages avoid doing this too often as it creates overheads.
You might also prefer to set it as an environment variable incase you do things like create other Python instances and don’t want to have to manage passing a flag around everywhere.
