Ticket #125 (closed defect: fixed)

Opened 13 months ago

Last modified 7 months ago

c2s doesn't listen on 5222

Reported by: mikiecx Owned by: smoku
Priority: major Component: General
Version: 2.1.22 Keywords:
Cc: pogma@… Tracforge_linkmap:
Blocking: Blocked By:

Description

i installed jabberd-2.1.12. compiled with: ./configure --enable-mysql --enable-ssl --enable-idn --enable-debug

after starting jabberd -D everything looks fine but it doesn't listen on any port except 5347 (router)

Attachments

jab.log (12.2 kB) - added by mikiecx 13 months ago.
jabberd log

Change History

Changed 13 months ago by mikiecx

jabberd log

  Changed 12 months ago by digger

  • version changed from 2.1.11 to 2.1.14

Exactly the same problem here, after rebooting my server.

FreeBSD 6.2-RELEASE-p5 / amd64

I'm missing lines like

"coming online" and "[%s, port=%d] listening for connections"

in the c2s debug log.

jabberd was running fine on the system for some month -- too bad, I can't tell which version it's been. Maybe I'll try a downgrade...

Regards, Steffen

  Changed 12 months ago by digger

2.1.10 does not work, 2.0s11 does.

I could do some more testing between these versions, if helpful...

Regards, Steffen

  Changed 12 months ago by smoku

This looks like the component cannot connect to router, thus does not start listening for incoming connections.

I had a report, that jabberd2 implementation of MD5 hash does not work under 64bit architecture. Could you confirm (or maybe fix) that?

  Changed 12 months ago by mikiecx

  • version changed from 2.1.14 to 2.1.12

i don't think it's a matter of 64bit architecture. my jabberd2 runs (or rather doesn't run ;) ) on slackware 11 on AMD 32bit platform (Duron). so far i tried db and mysql. neither works (but id doesn't lool like it's about auth/storage system). i agree it could be component can't connect to router, tho.

  Changed 8 months ago by smoku

As pointed in #100 it is a probably compiler bug. Try compiling with -02 or less.

follow-up: ↓ 7   Changed 7 months ago by smoku

  • status changed from new to closed
  • resolution set to worksforme

No more reports with recent (2.1.22) version.

Please reopen if the problem persist.

in reply to: ↑ 6   Changed 7 months ago by pogma

  • cc pogma@… added
  • status changed from closed to new
  • version changed from 2.1.12 to 2.1.21
  • resolution deleted

Replying to smoku:

No more reports with recent (2.1.22) version. Please reopen if the problem persist.

(no 2.1.22 in version pop-up)

We see this issue with jabberd-2.1.22 on Red Hat Enterprise Linux 3 and earlier, AIX5.1, 5.2 and 5.3, HP-UX11.00, 11.11, 11.23 and tru64 unix 5.0. We do not see the problem on sparc-solaris 2.6, 2.7, 2.8, 2.9, 2.10, x86-solaris 2.10, nor with 32 or 64 bit Red Hat Enterprise Linux 4 and 5.

The systems that work work with both cyrus sasl and gnu sasl libraries, the systems that do not work do not work with either. jabberd was configured with the same options on every system.

For the non-functioning systems, the router process is listening correctly, and connections are accepted, but both the server and clients end up waiting forever: c2s 

sx (sx.c:53) allocated new sx for 5
sx (client.c:122) doing client init for sx 5
sx (client.c:138) stream request: ns (null) to (null) from (null) version 1.0
sx (client.c:168) prepared stream header: <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
sx (client.c:175) tag 5 event 1 data 0x0
Sat Feb  2 01:11:10 2008 c2s.c:664 want write

router 

Sat Feb  2 01:11:00 2008 [notice] [0.0.0.0, port=5347] listening for incoming connections
Sat Feb  2 01:11:05 2008 main.c:444 running time checks
Sat Feb  2 01:11:05 2008 main.c:449 next time check at 1201936325
Sat Feb  2 01:11:10 2008 router.c:907 accept action on fd 5
Sat Feb  2 01:11:10 2008 [notice] [127.0.0.1, port=34149] connect
sx (sx.c:53) allocated new sx for 5
sx (server.c:236) doing server init for sx 5
sx (server.c:251) waiting for stream header
sx (server.c:254) tag 5 event 0 data 0x0
Sat Feb  2 01:11:10 2008 router.c:516 want read

And there they sit forever waiting for each other.

This log is on RHEL3, compiler is gcc-3.2.3 and flags -g -O0, with those flags it seems unlikely to be an optimization issue.

  Changed 7 months ago by smoku

  • status changed from new to accepted
  • version changed from 2.1.21 to 2.1.22

I'm puzzled though...

Until I can reproduce the problem, there's nothing more than guesswork... :-(

  Changed 7 months ago by smoku

  • status changed from accepted to infoneeded

One more question - which MIO backend is this?

  Changed 7 months ago by smoku

  • status changed from infoneeded to assigned

Do you have --enable-mio-debug ?

follow-up: ↓ 12   Changed 7 months ago by smoku

  • status changed from assigned to infoneeded

in reply to: ↑ 11   Changed 7 months ago by pogma

  • status changed from infoneeded to assigned

Replying to smoku:

Reverting the changes to mio_select.h in r222 appears to fix the problem (at least on RHEL3 - we have not tried the other platforms yet, you'll probably want to #ifdef for windows though).

I'll update the ticket with more information when I have it.

#187 and this bug are the same.

Thank you!

  Changed 7 months ago by smoku

#187 closed as duplicate

  Changed 7 months ago by smoku

  • status changed from assigned to started

Knowing, that it affects MIO select, now I can duplicate it. I will see into r222.

  Changed 7 months ago by smoku

  • status changed from started to closed
  • resolution set to fixed

In [548]: Fixed loop on select. Closes #125

Note: See TracTickets for help on using tickets.