Martin Lesser wrote: > Looks like. We disabled JUD on our productive Jabber-Server. Should > everyone running a productive server disable JUD?
I'm tempted to say "yes", however the actual problem has only been observed by a few people, so I guess it might be a bit too paranoid. The symptoms are pretty easy to spot: jabberd stops responding, consumes all the CPU, and there is a binary in the logfile where there should be plain text. If someone sees these symptoms then remove the JUD. >>The other observation about this problem is that shortly before the >>server spirals into its endless loop, the log file shows that it tried >>to access the global.xdb file (where JUD entries get stored); however >>the first 8 bytes of the filename have been overwritten. > > ... with a pointer (you said that on 09/09) Hmm, right, i did say that. But pointers on intel are 4 bytes (I deal with too many machine types...). There are clearly 8 bytes being overwritten in the filename... I won't make any claim as to what those bytes are, except to say they are _not_ the filename. Eg. It should read "/var/spool/jaber/jud/global.xdb" however instead I see in my log file: "decaching 0.$...*.ol/jabber/jud/global.xdb" where "." represents nonprinting characters. Those 8 bytes in hex have the values: 30 1C 24 09 98 B6 2A 08. If they were pointers that would be 0x09241c30 and 0x082ab698 repectively. Neither of those are valid addresses in any of my jabberd processes, so I suspect they are not pointers... sorry for the earlier claim as being such. > We made another observation: After jabberd and jud crashed global.xdb > was rewritten totally: All entries except the one of the user who > crashed it did not exist any longer :-( Wow, that is a departure from mine... our xdb file remained intact, at least, I didn't _notice_ that anything was lost from it. This would imply to me that there might be race condition between multiple threads trying to write to the data file. Something I hadn't really considered until now. > Until now I only can say that the main trigger for this was a > misconfigured client which had no appropriate locales so it sent > xml-garbage. Hmm, then we should be able to spot the garbled XML being transmitted with a packet sniffer. I regularly run tcpdump and log _everything_, and I don't remember seeing anything that I'd consider invalid in the packets leading up to the crash. Would like to be proven wrong though. > The question also is whether it is not a waste of time to locate the > problems or if it would be better to write a new (perhaps SQL-based) > JUD as temas suggested? Yep, maybe. Not sure I'd go the SQL route, unless dealing with a really large (distributed) jabber server farm. For single host systems, I think it would be easier to just keep everything in RAM, writing to disk only when there are changes made. It would only take a few megabytes to hold even a moderately sized user directory. That should be pretty easy to implement as well. _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
