QUESTION: is /tmp/shares.log and /tmp/request.log entirely necessary? Under what circumstances would one require those files? I assume they would become quite massive in a short amount of time.
Send SIGHUP to the process, to re-open the logs (such as after rotation or deletion).
Why even create them at all though to begin with I guess is my question? If you are already making exact copies of them in your mysql database that you can clean by "timestamp" much easier?
If I simply remove those two lines from the server.json file, is everything going to explode?
Can anybody answer the above question?
Is it necessary to create the two log files when we are already backing up everything to MySQL?
Can I easily remove the two log file lines (or send them to a blackhole type script or a file that never saves or something?)
I plan on removing old "shares" from my MySQL table on the fly as a new block is found.
Yes and no, The log files for for those who don't do terminal based debugging so I believe(don't quote the following) they are hard coded into pushpool to output them in case of a crash.
I think that log files usually trim the older lines of logs. Most developers(especially anyone that can program a pool servicing) has probubly been around for a while long before the days of when 512mb was unheard of and text data could file a whole hard drive within minutes. So I personally believe that they do stop getting bigger at some point
Can you easlity remove the two log file lines... Idk, i don't think anybody has tried, you should be the first. Let us know what your results are and we'll assist you wit what we can.
You should really install Mining Farm and check out the database structure to see how it all works I do something similar. Basically current rounds go to the `shares` table then upon a found block they get converted to the `shares_history` where they wait for the block to be confirmed, changing tables ensures better performance when doing reward counting. After its done rewarding and counting shares it moves all shares for that round into the `shares_dead` which is like a back up for operators in the case that the code went horribly wrong(hopefully never) and everyone got offset rewards. the operator can realy on a "backup" sorta of speak other then that `shares_dead` is just a back up