If you get weird crashes, that might be why
On start-up my Exit (Linux 3.16.0-4-amd64) Tor 0.2.7.6 creates this log message: [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 100010bf: Op$bf: OpenSSL 1.0.1k 8 Jan 2015; running with 1000114f: OpenSSL 1.0.1t 3 May 2016). Unfortunately it really crashes ones a day. This seems to be an ongoing problem for years now? Could anyone please give some help - or is there none? Thanks Paul
On 26.06.2016 16:22, pa011 wrote:
On start-up my Exit (Linux 3.16.0-4-amd64) Tor 0.2.7.6 creates this log message:
[warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 100010bf: Op$bf: OpenSSL 1.0.1k 8 Jan 2015; running with 1000114f: ^^^^^^^ OpenSSL 1.0.1t 3 May 2016).
Unfortunately it really crashes ones a day. This seems to be an ongoing problem for years now?
Could anyone please give some help - or is there none?
No, this is NOT a reason for those crashes. Background: At May/June 2016, Debian jessie transitioned from heavily-patched openssl 1.0.1k (with a lot of security patches backported from later [stable] versions) to (much more lightly-patched) openssl 1.0.1t (which already included all those security fixes). Both versions are (supposed to be) completely binary compatible, and running a binary compiled against 1.0.1k with openssl 1.0.1t should be completely safe. If your tor crashes daily (and especially if that also happened before June 2016, when debian transitioned to 1.0.1t), the reason must be something else (hardware problem, insufficient resources [memory? disk? process/task/thread limit?], some obscure tor bug). That said, above message looks weird. It comes from this code: log_warn(LD_CRYPTO, "OpenSSL version from headers does not match the " "version we're running with. If you get weird crashes, that " "might be why. (Compiled with %lx: %s; running with %lx: %s).", (unsigned long)OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT, SSLeay(), SSLeay_version(SSLEAY_VERSION)); What is that "Op$bf: " in above message and where it comes from?
On 26 June 2016 at 18:39, Yuriy M. Kaminskiy <yumkam@gmail.com> wrote:
On 26.06.2016 16:22, pa011 wrote:
On start-up my Exit (Linux 3.16.0-4-amd64) Tor 0.2.7.6 creates this log message:
[warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 100010bf: Op$bf: OpenSSL 1.0.1k 8 Jan 2015; running with 1000114f:
^^^^^^^
OpenSSL 1.0.1t 3 May 2016).
Unfortunately it really crashes ones a day. This seems to be an ongoing problem for years now?
Could anyone please give some help - or is there none?
No, this is NOT a reason for those crashes.
Background: At May/June 2016, Debian jessie transitioned from heavily-patched openssl 1.0.1k (with a lot of security patches backported from later [stable] versions) to (much more lightly-patched) openssl 1.0.1t (which already included all those security fixes).
Both versions are (supposed to be) completely binary compatible, and running a binary compiled against 1.0.1k with openssl 1.0.1t should be completely safe.
If your tor crashes daily (and especially if that also happened before June 2016, when debian transitioned to 1.0.1t), the reason must be something else (hardware problem, insufficient resources [memory? disk? process/task/thread limit?], some obscure tor bug).
I used to have some daily crashes on my first relay, this was due to running out of file descriptors, but the logs made it clear (http://fasmz.org/~pterjan/blog/?date=20150602)
That said, above message looks weird. It comes from this code:
log_warn(LD_CRYPTO, "OpenSSL version from headers does not match the " "version we're running with. If you get weird crashes, that " "might be why. (Compiled with %lx: %s; running with %lx: %s).", (unsigned long)OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT, SSLeay(), SSLeay_version(SSLEAY_VERSION));
What is that "Op$bf: " in above message and where it comes from?
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi Yuriy and Pascal, I don’t know where that "Op$bf: " is from, it is stated that way in the Tor log file. What looks very different from other relay debug files are the number of entries like these: Jun 25 20:05:50 kernel: [61536.640020] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143200123:1143203019 (repaired) Jun 25 20:05:54 kernel: [61540.044045] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143205915:1143208811 (repaired) Jun 25 20:05:59 kernel: [61544.900036] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143211707:1143214603 (repaired) Jun 25 20:06:31 kernel: [61577.120054] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143252251:1143255147 (repaired) Jun 25 20:06:37 kernel: [61583.684050] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143258043:1143260939 (repaired) Jun 25 20:06:41 kernel: [61587.156021] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143262387:1143266731 (repaired) Jun 25 20:06:41 kernel: [61587.588021] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143263835:1143266731 (repaired) Jun 25 20:06:45 kernel: [61591.492022] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143269627:1143272523 (repaired) Jun 25 20:07:22 kernel: [61628.072061] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143310171:1143313067 (repaired) Jun 25 20:07:53 kernel: [61659.280023] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143343475:1143347819 (repaired) Jun 25 20:07:53 kernel: [61659.708017] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143344923:1143347819 (repaired) Jun 25 20:08:21 kernel: [61687.148034] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143379675:1143382571 (repaired) Jun 25 20:08:32 kernel: [61698.296025] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143391259:1143394155 (repaired) Jun 25 20:08:39 kernel: [61705.388024] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143398499:1143399947 (repaired) Jun 25 20:09:03 kernel: [61729.729801] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143426011:1143428907 (repaired) Jun 25 20:09:15 kernel: [61741.832029] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143437595:1143440491 (repaired) Jun 25 20:10:58 kernel: [61844.000083] Peer 47.19.79.xxx:47000/55752 unexpectedly shrunk window 1143491894:1143494790 (repaired) Jun 25 20:11:02 kernel: [61848.120017] Peer 47.19.79.xxx:4700/55752 unexpectedly shrunk window 1143497686:1143500582 (repaired) and the number of lines like: kernel: [113700.366999] nf_conntrack: table full, dropping packet which comes nearly every second -sometime more. Memory is used about 50 percent -disk space more than enough. Am 26.06.2016 um 19:39 schrieb Yuriy M. Kaminskiy:
On 26.06.2016 16:22, pa011 wrote:
On start-up my Exit (Linux 3.16.0-4-amd64) Tor 0.2.7.6 creates this log message:
[warn] OpenSSL version from headers does not match the version we're running with.If you get weird crashes, that might be why. (Compiled with 100010bf: Op$bf: OpenSSL 1.0.1k 8 Jan 2015; running with 1000114f: ^^^^^^^ OpenSSL 1.0.1t 3 May 2016).
Unfortunately it really crashes ones a day. This seems to be an ongoing problem for years now?
Could anyone please give some help - or is there none?
No, this is NOT a reason for those crashes.
Background: At May/June 2016, Debian jessie transitioned from heavily-patched openssl 1.0.1k (with a lot of security patches backported from later [stable] versions) to (much more lightly-patched) openssl 1.0.1t (which already included all those security fixes).
Both versions are (supposed to be) completely binary compatible, and running a binary compiled against 1.0.1k with openssl 1.0.1t should be completely safe.
If your tor crashes daily (and especially if that also happened before June 2016, when debian transitioned to 1.0.1t), the reason must be something else (hardware problem, insufficient resources [memory? disk? process/task/thread limit?], some obscure tor bug).
That said, above message looks weird. It comes from this code:
log_warn(LD_CRYPTO, "OpenSSL version from headers does not match the " "version we're running with. If you get weird crashes, that " "might be why. (Compiled with %lx: %s; running with %lx: %s).", (unsigned long)OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT, SSLeay(), SSLeay_version(SSLEAY_VERSION));
What is that "Op$bf: " in above message and where it comes from?
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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.
participants (4)
-
grarpamp -
pa011 -
Pascal Terjan -
Yuriy M. Kaminskiy