Config file mistake causes miner log file to grow to 2GB in 90 min #8399
Unanswered
shotcollin
asked this question in
Storage Provider
Replies: 3 comments
-
Attached is the full (compressed) log file. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Hi @shotcollin Thank you for taking the time to provide detailed information and logs. As this issue was the result of the config error that you kindly documented, I am moving the this ticket to discussions for better visibilty. Many thanks! |
Beta Was this translation helpful? Give feedback.
0 replies
-
Also referenced in #8405 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Checklist
Latest release
, or the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.Lotus component
Lotus Version
Describe the Bug
While changing the miner's
config.toml
file, I duplicated a line in order to update the variable's value and retain the original value for reference, but I neglected to comment out the original line, i.e. the file looked like this:The miner started as usual and ran normally for over four hours. It then began to generate errors related to the duplicate line at a rate of almost one per microsecond, which seems excessive.
I had the log file open in a viewer, but it was no longer updating because it had crashed due to the file size, which obviates the log file's purpose. Had I not noticed this fairly quickly, it would have eventually crashed the miner because when allocating space I didn't anticipate multi-gigabyte log files.
This "bug" is admittedly caused in part by operator error, but I'm submitting as a bug since there's probably a more ideal way to deal with such errors.
Also, as a side note, I'm using
logrotate
to prevent system problems caused by rapidly expanding log files, but it doesn't/can't force applications to release their log files when they're rotated. If they're not released, it can't compress the log files until the subsequent rotation. This means thatlogrotate
will create a new log file for the miner when the current one exceeds some preset limit, but until the miner is restarted it continues to write to the old log file. So in this case, the log files looked like this, and theminer.log-20211105
would have continued to be written to by the miner until a restart.Previously this was a minor annoyance but I realize now it might have more serious consequences if there are other situations that cause the log files to grow rapidly. I don't know if there's anyway to program the miner so that when
logrotate
or a similar application makes a new log file the miner would immediately begin writing to that file, but if so it would be much appreciated.Logging Information
Repo Steps
Beta Was this translation helpful? Give feedback.
All reactions