Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #763777
| From | Cyril Brulebois <kibi@debian.org> |
|---|---|
| Newsgroups | linux.debian.bugs.dist |
| Subject | Bug#836236: prosody: doesn't try IPv4 when IPv6 fails |
| Date | 2016-09-01 00:30 +0200 |
| Message-ID | <scmb7-8fs-7@gated-at.bofh.it> (permalink) |
| References | <sclf4-7DL-7@gated-at.bofh.it> <sclI6-7NG-39@gated-at.bofh.it> <sclRL-86A-7@gated-at.bofh.it> |
| Organization | Debian |
[Multipart message — attachments visible in raw view] - view raw
Cyril Brulebois <kibi@debian.org> (2016-09-01): > Hi Matthew, > > Matthew Wild <mwild1@gmail.com> (2016-08-31): > > Thanks for the report. Can you please bump your log level up to > > 'debug' (there should be comments in your config file explaining how > > to do this), and include those logs? The 'info' level logs tend to > > give a high-level approximate view of issues, but only the debug logs > > can be relied upon when debugging the low-level individual connection > > attempts. > > This is very strange. While crans.org was still without IPv6, a simple > restart locally made prosody look at both IPv6 (fail) and IPv4 > (success). I wonder whether something might have been stuck in a bad > state within prosody after the initial DNS resolution failures which > happened for various domains… > > Needless to say, I can't really replicate the issue right now, except > perhaps by rebooting again (which I can't really since I've got ongoing > maintenance elsewhere already). I would also need to remove things like > contact presence information from those logs before posting them… Just in case it helps you figure out what could have happened, messages right after reboot for this host: | Aug 31 02:09:46 s2soutf30410 info Beginning new connection attempt to crans.org ([2a01:240:fe3d:4:200:42ff:fe42:4204]:5269) | Aug 31 02:09:46 mod_s2s warn s2s connect() to crans.org (2a01:240:fe3d:4:200:42ff:fe42:4204:5269) failed: Network is unreachable | Aug 31 02:09:46 s2soutf30410 info Out of connection options, can't connect to crans.org | Aug 31 02:09:46 s2soutf30410 info Sending error replies for 1 queued stanzas because of failed outgoing connection to crans.org | Aug 31 02:09:46 mod_s2s warn Connection to crans.org failed already, destroying session... Also, a bunch of other hostnames had such issues: | Aug 31 02:11:27 s2sout1007a70 info Connection failed (name resolution failed). Attempt #2: This time to alt2.xmpp-server.l.google.com.:5269 | Aug 31 02:11:27 s2sout1007a70 info Connection failed (name resolution failed). Attempt #3: This time to alt4.xmpp-server.l.google.com.:5269 | Aug 31 02:11:27 s2sout1007a70 info Connection failed (name resolution failed). Attempt #4: This time to alt3.xmpp-server.l.google.com.:5269 | Aug 31 02:11:27 s2sout1007a70 info Connection failed (name resolution failed). Attempt #5: This time to alt1.xmpp-server.l.google.com.:5269 | Aug 31 02:11:27 s2sout1007a70 info Out of connection options, can't connect to [anotherserver] | Aug 31 02:11:27 s2sout1007a70 info Sending error replies for 1 queued stanzas because of failed outgoing connection to [anotherserver] so I'm wondering whether there could have been incomplete DNS resolution(s) at start-up time, which would not have been attempted again later, leading me to see some contacts offline with “DNS failures” as error message in Gajim. After the prosody restart I triggered manually: | Aug 31 23:37:49 s2sout231c500 info Beginning new connection attempt to crans.org ([2a01:240:fe3d:4:200:42ff:fe42:4204]:5269) | Aug 31 23:37:49 s2sout231c500 info Beginning new connection attempt to crans.org ([138.231.136.66]:5269) | Aug 31 23:37:49 s2sout231c500 info outgoing s2s connection mraw.org->crans.org complete Incidentally, looking at the IPv4 address for crans.org in the log since the machine reboot, the first occurrence is when I restarted prosody manually. So it looks to me like it could be an initial DNS issue (partial and/or no resolution depending on the domain) which happened at start-up time, and failed/incomplete resolutions weren't attempted again later on. Would this seem even remotely plausible? KiBi.
Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Cyril Brulebois <kibi@debian.org> - 2016-08-31 23:30 +0200
Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Matthew Wild <mwild1@gmail.com> - 2016-09-01 00:00 +0200
Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Cyril Brulebois <kibi@debian.org> - 2016-09-01 00:10 +0200
Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Cyril Brulebois <kibi@debian.org> - 2016-09-01 00:30 +0200
Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Matthew Wild <mwild1@gmail.com> - 2016-09-01 10:40 +0200
Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Cyril Brulebois <kibi@debian.org> - 2016-09-01 17:20 +0200
csiph-web