You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I want to run OctoPrint off of a read-only/overlay file system to prevent SD card corruption due to unclean shutdowns.
For that, I have configured all services to only emit logs to journald via stderr or syslog, which keeps 10 MB worth of logs in memory. However, OctoPrint does not seem to have a forward-compatible way of turning off log file creation, even if its stdout logs are already processed by journald.
While it is technically not a critical issue for OctoPrint to create redundant log files in the overlayfs, this feels very unclean, uses up a potentially large amount of RAM (with data that journald already keeps a copy of), and makes "clean" integration with log aggregators impossible.
Describe the solution you'd like
Some kind of setting that disables any and all log file output.
Describe alternatives you've considered
The logging.yaml file can be used to override individual log handlers. I believe this can be used to accomplish what I want (haven't tried it yet), if I write enough duplicate YAML entries, but the instant another file logger gets added to the code I would end up with a log file again, so this is not forwards-compatible:
I have also tried to change the log file path to /noaccess in config.yaml, a directory that doesn't exist and OctoPrint doesn't have permission to create. However, it "helpfully" detects this and falls back to .octoprint/logs.
I have also tried to make the file permissions of .octoprint/logs read-only, which makes OctoPrint fail to start up completely.
Additional context
No response
The text was updated successfully, but these errors were encountered:
I've now tried to set every log file to /dev/null in logging.yaml, but per-plugin files still get created in the logs folder.
A workaround that does work, and has no forwards-compatibility problems either, is to mount a tmpfs with size=1 (size=0 seemingly results in no size limit), and use that as the log file destination. That way I only have to pay the miniscule RAM cost of the inodes, not of the full file contents. However this workaround is pretty gross, it kinda requires praying that octoprint will just keep on running when log writes fail with ENOSPC, so having a "proper" way to accomplish this would still be very useful.
+1 for an option that allows disabling all logging. This would be good for people that want to make embedded appliances where everything is run from a ro filesystem with rw overlay in RAM.
I'm just working around it by adding this line to crontab to purge logs every 10 minutes /10 * * * rm -f /home/pi/.octoprint/logs/
this folder is in the RAM overlay anyway, so erasing it often does not wear out the SD card. I just need to free RAM because I'm using devices that have little RAM to begin with.
To give more context: when I change permissions or delete the folder while octoprint is running nothing breaks. But if I change permissions of the folder and restart octoprint I see:
Apr 12 17:01:56 octopi octoprint[1689]: 2024-04-12 17:01:56,401 - octoprint.startup - CRITICAL - Could not initialize settings manager: Folder at /home/alby/.octoprint/logs doesn't appear to be writable, please fix its permissions
Apr 12 17:01:56 octopi octoprint[1689]: 2024-04-12 17:01:56,408 - octoprint.startup - CRITICAL - There was a fatal error starting up OctoPrint.
Apr 12 17:01:56 octopi octoprint[1689]: Could not initialize settings manager: Folder at /home/alby/.octoprint/logs doesn't appear to be writable, please fix its permissions
so it's just a check that happens during startup phase, and if failed the program quits.
Is your feature request related to a problem? Please describe.
I want to run OctoPrint off of a read-only/overlay file system to prevent SD card corruption due to unclean shutdowns.
For that, I have configured all services to only emit logs to journald via stderr or syslog, which keeps 10 MB worth of logs in memory. However, OctoPrint does not seem to have a forward-compatible way of turning off log file creation, even if its stdout logs are already processed by journald.
While it is technically not a critical issue for OctoPrint to create redundant log files in the overlayfs, this feels very unclean, uses up a potentially large amount of RAM (with data that journald already keeps a copy of), and makes "clean" integration with log aggregators impossible.
Describe the solution you'd like
Some kind of setting that disables any and all log file output.
Describe alternatives you've considered
The
logging.yaml
file can be used to override individual log handlers. I believe this can be used to accomplish what I want (haven't tried it yet), if I write enough duplicate YAML entries, but the instant another file logger gets added to the code I would end up with a log file again, so this is not forwards-compatible:OctoPrint/src/octoprint/__init__.py
Lines 302 to 359 in 65a5533
I have also tried to change the log file path to
/noaccess
inconfig.yaml
, a directory that doesn't exist and OctoPrint doesn't have permission to create. However, it "helpfully" detects this and falls back to.octoprint/logs
.I have also tried to make the file permissions of
.octoprint/logs
read-only, which makes OctoPrint fail to start up completely.Additional context
No response
The text was updated successfully, but these errors were encountered: