On 6/26/16, pa011 pa011@web.de wrote:
[report]
You have reported about four multiple things. Though they may be related, try breaking them down into a more individual approach.
(Compiled with 100010bf: Op$bf: OpenSSL 1.0.1k 8 Jan 2015; running with 1000114f: OpenSSL 1.0.1t 3 May 2016).
While mismatches could possibly crash tor, letter bumps in the same version train are supposed to be compatible.
I don’t know where that "Op$bf: " is from, it is stated that way in the Tor log file.
While could be bad hardware (try using memtest86 and disk testing tool), it may be some library function mismatch.
That "Jan 2015" and "years now" can be a very long time, and we don't know what you started with or the box history or your admin level. The longer you live on some upgrade chains, the more mashups may happen.
Even though this may skip the original problem, make sure your entire base OS and kernel is fully up to date, or even wiped and reinstalled with the latest release, including the openssl and tor packages.
kernel: Peer unexpectedly shrunk window (repaired) kernel: nf_conntrack: table full, dropping packet
The first is more of a notice to you. The second means you're exceeding kernel resource...
Memory is used about 50 percent
... this is likely user memory, not kernel memory...
so if they recur, google the kernel messages to find info and solutions on them.
Unfortunately it really crashes ones a day. This seems to be an ongoing problem for years now?
If you wanted to investigate that, search for how to turn on core dumps, and debug level syslog. Debug level tor log is also possible. Just beware that on a tor box all these logs are very privacy sensitive.
Look at what else is happening running once a day at that time. See what cron is doing.