Logging into logfile stops working after lots of content has to be written in a short time #1674
Comments
hmm, thats very odd! My change should not have an impact of the writing of a single line (only to keep the file open between the lines)
This indicates that it tries to open the file but fails. Again this seems to have another root cause (the diskio issue). |
|
@Slider0007 Can you test if the issue is the same? |
|
@caco3: I've just tested with your branch version. Now the behaviour is the same than in "the old days". Why more errors in serial log but system is kept running and responsive. Whenver the logfile is almost zero size or log level is less than DEBUG, no messages are missing. Serial log: Logfile: |
|
But we have the same issue: So that indicates that this issuse is not due to my change! |
|
@caco3: After some more testing I was able to get the optimized logfile handling working on my side as well. I changed mainly only stack sizes. The positive side effect of these modifications is that the prevoius handling (open / close for every write into the logfile) is also working without any issues anymore. I tested both variants (open file and reuse handle / open/close for every write) with logfile sizes of ca. 10MB. I have for 99,9% no issues with SD read/write errors with both variants. I wasn't able to see differences. Two versions are available: As Reference (your branch with activated TaskDebug): https://github.com/jomjol/AI-on-the-edge-device/actions/runs/3777788474 Whenever the really really rarly SD issues occured, with the new approach the system did not completly lock up anymore, but was extremly slow. This was not (or less) happening with "old style". Due to the fact that a failure free operation cannot be guranteed I would prefer a more failure-tolerant approach which tents my to stay with the old style even I would technically prefer the new verison. An additional second positive side effect of the changes is the fact, that we'd have ca. 27kB more min. free heap (7kB --> 34kB) @jomjol, @haverland: FYI |
|
The stack adaptions are now included in newest rolling. They can now be tested with rolling branch. This issue should be fixed. |
|
You can use the latest Automatic Build of the the |
The Problem
After lots of content has to be written to the logfile in a short time (e.g. DEBUG loglevel + publishing HA discovery topcis after start of the device + Webinterface access) the writing into the log file stops working and negativly impact the rest of the system. This is reproducable. Only a reboot fixes the problem. Starting with lower log level (reduced amount of data to be logged), no issues at all.
##############################################
Test with latest rolling Remove unnecessary null pointer checks
Lofgile size: ca. 300KB
Serial log:
Logfile:
###############################################
Same setup - test with rolling before commit "Logfile write optimization": Trigger a flow start by REST API or MQTT
logfile size: ca. 300KB
If the logfile is < ca. 100KB --> no missing messages
Serial log:
Logfile:
Version
Rolling
Logfile
Expected Behavior
No response
Screenshots
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: