I've been messing with ejabberd these last few months for a big project I'm playing a role in. The more I use it, the more I realize just how poorly it is documented, and I get how easily things are overlooked. Essentially, to know how to use ejabberd, you had better get a pretty solid grip on Mnesia. Since I didn't really account for learning a whole new language/paradigm/architecture, I'm pretty much relying on the mailing list. I'm very appreciative of those who help a new guy out and it makes me realize how little I have been able to give back to the community. I guess at the end, I'm hoping that with starting to blog again, I can also start to give back to the community, albeit a small piece at a time. Here goes my part.
I have been working on clustering support for our deployments of ejabberd. Particularly, I have been trying to get the servers in our DMZ void of any and all password validation for users and the servers behind our big firewalls to be the datastores. Today I learned that while we had four nodes working, one of the rear two nodes was only able to start up if the other "master" was started. This is a poor solution for failover and creating a .999 deployment, so it had to be researched. In the end, we discovered that ejabberd is built as a list of features built on Mnesia, and if a database is stored as RAM only, then the features will wait until the remote node is available. The discovery which directed me to the solution was a simple mailing list post: http://lists.jabber.ru/pipermail/ejabberd/2009-December/005535.html.
So, lesson of the day, if your ejabberd server is starting, but none of the ports are listening, and you're not getting crash/error reports, the features are probably waiting for one of your remote nodes storing the database to come up. The fix is to configure your databases to mirror one another, particularly in the "RAM and disc copies" selections of each table.