In all the suspension and DQ threads we keep coming across the problem, that the log files are only stored inside docker and when people ask for help, you can’t find any error messages anymore because they typically restart their node.
So as this standard behaviour is of absolutely no help in solving SNO issues, I’d suggest automatically redirecting the logs to the HDD that is used for STORJ.
As a precaution, the log could be replaced if it gets too big (like 2GB?), no logrotation or anything.
That way you ensure that people coming to the forum after suspension still have enough logs to actually figure out what the problem is.
I think this is a good idea for default configuration.
However, it should be noted that log files will get very large and are stored in the config directory of the node. Thus, the log files… if kept for a long time… will become unwieldy as well as consume some of the available drive space for storing data pieces.
So…
If this is a default setting, the instructions/recommendations should include a default logrotate template as well as some recommendation on moving old log files out of the config directory.
And please note… I am NOT indicating that logrotate be distributed or included in the storage node software. It should be recommended as a solution to keeping log files. Log file maintenance is the purview of a system admin… and should not be the responsibility of a software/utility vendor.
yeah I was just wondering out loud how the storagenode implementation deals with it natively as I know it writes logs to a file. Perhaps it just grows indefinitely.
I decided this question so…
Once a month (the last day), I take the current file (about a few hundred MB.) and replace it with a new and empty one.
I pass the full file through the KPD analyzer to understand where I am regarding the success in the race (especially if various optimizations were made to the node during the month) and then archive it with the archiver (500 MB. > 60 MB.) with a time and date stamp.
I like to control these things manually, actually.
I recently started archiving the logs using docker logs storagenode -f 2>/some/file running in screen. Every time I restart the node, I start archiving logs to a new file.
This still leaves me able to use docket logs storagenode --since 1234 for my statistics script.
that command i gave exports the existing log from docker into a file…
which solves the problem… granted if they did a rm storagenode command in docker then the log is gone… tho i will agree that it is a bit unpractical that the docker rm command zeros the logs… sometimes…
maybe the redirection of logs should be a standart advice for when following the guide on the storagenode install guidelines…
but some of us find all the functions of the docker logs command very useful and don’t want that broken…
This idea is not about how people could solve the problem if they used additional tools or commands because most people running into suspension problems dont do that… So your suggestion doesnt solve the initial problem this idea is describing.
And the idea is to redirect the logs by default, which doesn’t mean that you would be unable to change it back to using docker logs.