Log file creation issue in SWARM 3.6.7

[UserDC-LeGrand]

Not sure why but some t-rex and perhaps other miners, create individual logs at times, and consolidated one (under the same name) in other. In both cases, etchash was beeing used when this happened.

Also, would be possible to mimick HiveOS logfile creation behavior, ie, create a new logfile each time a miner is restarted, pehaps include a timestamp, or sequence number is fine too. The time-stamp naming convention you use SWARM could work too. Can you perhaps create individual miner subfolders to keep things tidy?

[MaynardMiner]

No. I can't implement the way HiveOS does it.

HiveOS uses gnu-screen and not the miner to create the log. This is not an option with windows. I have to have a method that will work in both versions.

I am unable to redirect the output of a lot of miners to a file in Windows, as it triggers their anti-debugging. In HiveOS, they are not attempting to redirect the output of the miner itself, but gnu-screen. In Windows this is not an option as there is no terminal multiplexing.

[MaynardMiner]

I am not sure how to fix this, and sadly this is going to be an eventual problem for people running SWARM for days at a time with no maintenance.

I may have to roll back the miner logging change, and come up with another solution (if there is one).

[MaynardMiner]

I am going to test and see if in Windows if I can start the miner in powershell window, and record the output of the window instead of the miner directly. If this works, then maybe I can do something similar to HiveOS. I also have to see how resource heavy that is, because it's a shell within a shell.

I will do some testing, and come back to this.

[UserDC-LeGrand]

Best to keep things simple for both OS, Some way to have single file per miner, and keep appending to it is fine too. Should the file get too large. it should be part of a regular rig admin task to plan for this, ie purge the file once in a while, zip it, etc.

Other option, overwrite the miner log file every week or month or so, or add an argument in SWARM to control this such as -LogFileDuration = [value in x days]. Every x days, the specific miner logfile gets nuked, and overwrittne by new ouput ...

[MaynardMiner]

So initial testing shell-in-shell worked: It appears to have been able to record the miner output.

My goal is to release next version with a test on the windows side to see if it causes issues/bugs when I attempt to record the windows output. If I get no reported issues, I could then hypothetically have full control over logging and not be limited to miners.

I suppose the question is, is if that is the case- What is the ideal scenario to log miner output...I mean how should the "system" work as far as how it records miners, and how/when should it handle rollover.

[UserDC-LeGrand]

YMMV, but for me personally, I investigate miner crashes almost the same day they happen. If the miner happened to restart several times, this means Ill have that many logfiles to "tail" looking for clues of what happened. The tail end will usually tell the story of what went wrong. This becomes a little more tedious in a sngle logfile that is 1 week big, in that you need to know what to look for and "grep" for keywords ... In the SWARM use case, you mentioned it would tedious to mimic HiveOS in that way, ie , one folder per miner, one new logfile each time a miner is started, so perhaps a compromise of one log filer per day per miner, up to 7 days, the overwrite,/rollover the older logfile...

[MaynardMiner]

It would be tedious only because I didn't have a solution to Windows. Now that I have a proposed way of logging- I just need to make certain changes to Windows side, and then I can self-control how miners are logged. This means I could make a folder per miner at that point in logs folder.

[MaynardMiner]

At the moment I am quietly trying to make changes to the Windows version first though. It changes entirely how miners are launched, so it's kind of a larger re-write to implement...But I agree that I think miner logging sucks and SWARM should have a method better than theirs.