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
This issue was turned into a discussion, but the discussion was immediately locked and didn't allow any comment, update, further discussion, etc. So I apologize for turning this back into an issue, but that was the only way to add this annotation:
I attempted to make the original issue clear in that it wasn't referring to my specific config error that caused the massive increase in log size, but rather the fact that any config error in general could (presumably) have a similar effect, which is writing a new log file line once every millisecond. In my case the line was a (640-character) warning, which would have caused the log to increase at a rate over 2 GiB per hour, and over 51 GiB per day (if my calculations are correct).
What makes this problematic and not simply an issue of operator error is that the log file increase didn't occur until hours after the config file was changed, meaning a SP could make a config change, assume the miner was running fine since no immediate errors or warnings were reported, then encounter a problem potentially hours later in which, if log files are being written to the OS drive, warning messages could cause significant log file expansion. This growth could be fast enough to fill up a drive before logrotate or some other automatic mitigation kicks in.
That being said, please of course feel free to turn this back into a discussion if more appropriate there.
Originally posted by shotcollin November 5, 2021
Checklist
This is not a security-related bug/issue. If it is, please follow please follow the security policy.
This is not a question or a support request. If you have any lotus related questions, please ask in the lotus forum.
This is not a new feature request. If it is, please file a feature request instead.
This is not an enhancement request. If it is, please file a improvement suggestion instead.
I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
I am running the 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.
I did not make any code changes to lotus.
Lotus component
lotus daemon - chain sync
lotus miner - mining and block production
lotus miner/worker - sealing
lotus miner - proving(WindowPoSt)
lotus miner/market - storage deal
lotus miner/market - retrieval deal
lotus miner/market - data transfer
lotus client
lotus JSON-RPC API
lotus message management (mpool)
Other
Lotus Version
Daemon: 1.13.0+mainnet+git.7a55e8e89+api1.2.0
Local: lotus-miner version 1.13.0+mainnet+git.7a55e8e89
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.
2021-11-05T04:21:01.631Z WARN sectors storage-sealing/terminate_batch.go:104 TerminateBatcher processBatch error {"error": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.)", "errorVerbose": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.):\n github.com/filecoin-project/lotus/extern/storage-sealing.(*TerminateBatcher).processBatch\n /home/user/lotus/extern/storage-sealing/terminate_batch.go:117"}
2021-11-05T04:21:01.632Z WARN sectors storage-sealing/terminate_batch.go:86 TerminateBatcher getconfig error {"error": "Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined."}
2021-11-05T04:21:01.636Z WARN sectors storage-sealing/terminate_batch.go:104 TerminateBatcher processBatch error {"error": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.)", "errorVerbose": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.):\n github.com/filecoin-project/lotus/extern/storage-sealing.(*TerminateBatcher).processBatch\n /home/user/lotus/extern/storage-sealing/terminate_batch.go:117"}
2021-11-05T04:21:01.637Z WARN sectors storage-sealing/terminate_batch.go:86 TerminateBatcher getconfig error {"error": "Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined."}
2021-11-05T04:21:01.639Z WARN sectors storage-sealing/terminate_batch.go:104 TerminateBatcher processBatch error {"error": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.)", "errorVerbose": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.):\n github.com/filecoin-project/lotus/extern/storage-sealing.(*TerminateBatcher).processBatch\n /home/user/lotus/extern/storage-sealing/terminate_batch.go:117"}
2021-11-05T04:21:01.640Z WARN sectors storage-sealing/terminate_batch.go:86 TerminateBatcher getconfig error {"error": "Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined."}
2021-11-05T04:21:01.641Z WARN sectors storage-sealing/terminate_batch.go:104 TerminateBatcher processBatch error {"error": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.)", "errorVerbose": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.):\n github.com/filecoin-project/lotus/extern/storage-sealing.(*TerminateBatcher).processBatch\n /home/user/lotus/extern/storage-sealing/terminate_batch.go:117"}
2021-11-05T04:21:01.642Z WARN sectors storage-sealing/terminate_batch.go:86 TerminateBatcher getconfig error {"error": "Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined."}
2021-11-05T04:21:01.643Z WARN sectors storage-sealing/terminate_batch.go:104 TerminateBatcher processBatch error {"error": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.)", "errorVerbose": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.):\n github.com/filecoin-project/lotus/extern/storage-sealing.(*TerminateBatcher).processBatch\n /home/user/lotus/extern/storage-sealing/terminate_batch.go:117"}
2021-11-05T04:21:01.644Z WARN sectors storage-sealing/terminate_batch.go:86 TerminateBatcher getconfig error {"error": "Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined."}
2021-11-05T04:21:01.645Z WARN sectors storage-sealing/terminate_batch.go:104 TerminateBatcher processBatch error {"error": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.)", "errorVerbose": "getting sealing config: %!W(toml.parseError=Near line 411 (last key parsed 'Storage.ResourceFiltering'): Key 'Storage.ResourceFiltering' has already been defined.):\n github.com/filecoin-project/lotus/extern/storage-sealing.(*TerminateBatcher).processBatch\n /home/user/lotus/extern/storage-sealing/terminate_batch.go:117"}
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 that logrotate 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 the miner.log-20211105 would have continued to be written to by the miner until a restart.
-rw-rw-r-- 1 user user 0 Nov 5 05:45 miner.log
-rw-rw-r-- 1 user user 1015K Oct 31 11:38 miner.log-20211031.gz
-rw-rw-r-- 1 user user 849K Nov 3 06:01 miner.log-20211103.gz
-rw-rw-r-- 1 user user 1.9G Nov 5 05:58 miner.log-20211105
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.
Thanks for the detailed issue-report. I will try to reproduce it on a newer version as I know some kvlog / error-loops events have been fixed in the upcoming v1.15.1 release, see this PR: #8338.
Many apologies @shotcollin , the discussion was locked in error but is now open again for comment.
No worries @TippyFlitsUK , I thought that was probably what happened, but then couldn't find a way to send a dm so figured this was the next best thing...
Discussed in #8399
This issue was turned into a discussion, but the discussion was immediately locked and didn't allow any comment, update, further discussion, etc. So I apologize for turning this back into an issue, but that was the only way to add this annotation:
I attempted to make the original issue clear in that it wasn't referring to my specific config error that caused the massive increase in log size, but rather the fact that any config error in general could (presumably) have a similar effect, which is writing a new log file line once every millisecond. In my case the line was a (640-character) warning, which would have caused the log to increase at a rate over 2 GiB per hour, and over 51 GiB per day (if my calculations are correct).
What makes this problematic and not simply an issue of operator error is that the log file increase didn't occur until hours after the config file was changed, meaning a SP could make a config change, assume the miner was running fine since no immediate errors or warnings were reported, then encounter a problem potentially hours later in which, if log files are being written to the OS drive, warning messages could cause significant log file expansion. This growth could be fast enough to fill up a drive before
logrotate
or some other automatic mitigation kicks in.That being said, please of course feel free to turn this back into a discussion if more appropriate there.
Originally posted by shotcollin November 5, 2021
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
The text was updated successfully, but these errors were encountered: