Couldn’t find anything on this topic, but ran into an issue with the Txt.log file that’s created automatically by VCV rack.
I left my patch open for a while (a week at least) in the background, running but muted in the mixer. Not intentional, just forgot to close it and didn’t use the computer for other things during those days at all.
When I came back to my computer realized that my hard drive with the windows installation was 100% full.
Took a look and the Log.txt file was taking up 750 GB of space! Completely filled up my smaller drive that the OS is located on.
I get it was a mistake to leave it running, but surely there should be a cap on the log file size, as a failsafe for this kind of situation?
It sounds like some plugin is logging too much stuff. Any idea where all that log noise is coming from? If it were my plugin, I’d want to know so I could fix it! I know you can’t reasonably open a 750 GB file, but can you use a command line utility like tail to display the last 100 lines of the file or so, and post that here?
[EDIT] Or better yet, run that same patch again for a few minutes to create a new log file (but much smaller), then upload that to this thread?
Can you provide a snipped of the log file that shows some of the messages logged? That will help me determine, which plugin is potentially spamming the log file. Thanks.
If the VCV Rack developers decide to support a limited log size, I have a suggestion. In my paid C#/.NET work we use Log4Net as our logging provider. We configure it to work this way: log up to 10 MB, then close the file, rename log.txt to log1.txt, rename any log1.txt to log2.txt, up to a maximum of the most recent 8 files (or however many you want to keep).
We do the same bucket brigade thing every time we start up our program as we do when the file hits its size target. So you always have the most recent 8 logs, none of which are much larger than 10 MB (going a few extra bytes over, to flush the current log line, is fine). This means you can never have more than 80 MB of log, and you always have the most recently logged stuff in case something goes wrong.
This could also help VCV Rack support and plugin developers. There have been a couple of times where I have a crash, then I get a brain fart and run VCV Rack again and lose the log with the stack trace I needed. With this change, you can go look at log1.txt and you still have the precious stack trace.
One thing I have done over the years with log files is to decrease the frequency at which the log file writes the longer the program runs. Many years ago I was developing interactive IBM mainframe job submission and management from a PC via LTERM and dynamic JCL virtual card deck creation. IBM had a convenient job status request but no one told me that our company charged the division member who submitted the request $0.25 per time. Do that a few thousand times and it gets peoples attention!
I just looked at the code. As soon as the logger hits 10MB, it just stops logging. So you end up missing the reason for a crash, etc., in that case. I suppose the argument is that logging more than 10MB is inherently a bug already?
I would think so. If the log gets that big something (a plugin) is logging way too much, which means that no matter how much you compress it, eventually it will still fill your disk. So it’s either the simple “just stop logging” or some more elaborate, perhaps/perhaps not useful scheme of chunking the logs and only keeping the first and last and logpruning and … yeah, can get messy. Or the alternative is that each plugin gets its own log with a hard cap on the size, because it’s some plugin making a mess, not Rack. Not simple either and then you kinda loose the global timeline. I think what’s been implemented is probably the best and most practical compromise, all things considered.
The VCV Rack application is capable of creating massive log files on it’s own if left long enough. It writes the following to the file every 15 seconds:
[30.007 info src/patch.cpp:254 saveAutosave] Saving autosave C:/Users/adam-/Documents/Rack2/autosave/patch.json
[30.009 info src/settings.cpp:498 save] Saving settings C:/Users/adam-/Documents/Rack2/settings.json
Yeah, each one of those “Saving” messages is 212 bytes (both lines plus carriage returns). If I’m doing the math right, that works out to 47170 messages before we hit 10MB. Multiply by 15 seconds (1/4 of a minute) and we get 11792.5 minutes, or 8.2 days. So this is something to be aware of, especially for those of us who like to leave patches running all the time.
Looks like he fixed the wrong problem. The autosave messages are pointless (other than seeing it in debug mode tells you if rack is running and not hung). If an issue occurs on autosave, then yeah, log that.
)