Skip to content

InstallGuide Troubleshooting

Tomasz Sterna edited this page Oct 18, 2012 · 3 revisions

Go up: ParentWiki

A.12. Troubleshooting Tips for Jabberd 2

This section is designed to provide some troubleshooting tips for Jabberd 2. It is not intended as an exhaustive diagnostics or troubleshooting tree. Additional tips are extremely welcome, especially because I know that there are several regular Jadmin and Jabberd list posters who are more adept at troubleshooting than I am. Please post any additional tips you may have, and I will incorporate them into this page.

General

  • Enable debugging
  • Go over configuration files with a fine tooth comb

Problems Building Jabberd 2

  • Make sure all dependencies are installed
  • Specify all options and paths
  • Check config.log

Jabberd 2 Crashes After Start

  • Make sure all Jabberd 2 binaries have stopped
  • Be careful when running as root
  • Make sure jabber user has path to binaries
  • Make sure that jabber user has access to necessary paths
  • Enable debugging
  • Go over configuration files with a fine tooth comb

Clients Cannot Connect to Server

  • Check DNS resolution
  • Make sure user name matches server
  • Enable debugging
  • Go over configuration files with a finetooth comb
  • Use client debug XML output
  • Try a different client

General

Enable Debugging

If your Jabberd 2 server does not start, or it has problems connecting to clients, rebuild Jabberd 2 with the --enable-debug switch, and then start it with the -D option. The amount of debug output may be a bit daunting to a new administrator; however, there are a few things to look for.

A Jabberd 2 server crash is usually preceded by the crashing of one of the Jabberd 2 components (router, resolver, c2s, s2s or sm). Near the end of the debug output, you should be able to figure out which component crashed. Then, you can work backwards in the debug output — looking for output for the failed component — to see what its last actions were before crashing. This may provide some clues as to why the component crashed. Note that crashes of sm and c2s are often related to database and database-connectivity issues.

You can pipe the debug output if you find it hard to read from a terminal. For example, you might pipe debug output to a file so that you can search it:

        /usr/local/bin/jabberd -D > /tmp/jabber_debug.log

An alternative is to pipe the debug output through grep so that you only see certain messages. This works especially well for monitoring a single component. This command would run Jabberd 2 in debug mode, while showing only debug messages from the sm component:

        /usr/local/bin/jabberd -D | grep ^SM

If your server has problems connecting to clients, start Jabberd 2 in debug mode and wait for all components to fully initialize before attempting to connect from a client. Then, view the Jabberd 2 debug output as you attempt to connect from a client.

If you see no additional debug output as your client attempts to connect, you most likely have a DNS, user name or network/firewall problem. If you do see additional debug output as the client connects, look especially for output related to authorization problems.

If you still are unable to troubleshoot your server, you may wish to post a question — along with debug output — to the jadmin or jabberd lists

Go over configuration files with a fine tooth comb

Many Jabberd 2 issues are caused by a configuration mistake or typo. Go over your configuration files very carefully. You may wish to diff each configuration file against the template to see what changes you have made. For example, you might diff your c2s.xml file to verify changes you have made:

        cd /usr/local/etc/jabberd
        diff c2s.xml c2s.xml.dist

If your setup is new, you may wish to consider deleting any modified configuration files and starting over by copying the *.dist files in /usr/local/etc/jabberd.

Problems Building Jabberd 2

Make sure all dependencies are installed

See Section 2.4 for a description of dependencies for Jabberd 2. If you are using MySQL with Jabberd 2, make sure that each of the Server; Client Programs; Libraries and Header files; and Dynamic Client Libraries packages are installed.

Specify all options and paths

The configure script for Jabberd 2 does not necessarily halt if it is unable to find a specific package, nor does it report invalid configure options. The best way to ensure that all packages are found is to specify all packages to use, along with their include and library paths when running configure. For example, you might use a configure statement like this to build Jabberd 2 and use MySQL for authentication and storage — after verifying that the extra include and library paths covered all the dependencies:

        ./configure --enable-mysql --enable-ssl --enable-idn \
        --with-extra-include-path=/usr/include/mysql:/usr/include \
        --with-extra-library-path=/usr/lib/mysql:/usr/lib

The key is to identify all the correct include and library paths. ldconfig is a useful tool for finding library files. For example, this command would report the locations of MySQL library files (as super-user):

        ldconfig -p | grep mysql

The good thing about using ldconfig is that it reports libraries currently being used. This is especially useful if you have performed multiple installations of a package. Once the libraries for a dependency are found, the include files can usually be found in a parallel include directory. For example, if the libidn libraries were found in /usr/local/lib, the headers would most likely be found in /usr/local/include. If ldconfig fails to find a set of libraries, you may need to run it without the -p switch (see the man page).

Identifying include and library paths is especially important on Redhat and Fedora because these distributions install packages to non-standard locations. See the FAQ for Redhat and Fedora configuration issues.

Check config.log

The ./configure output is written to config.log. This is a huge file; however, you may be able to do some searching to identify problems. Searching for the whole word "no" is one way to find files that were not found when ./configure was run. Note that config.log reports all files not found as it searches multiple locations. Therefore, each unfound file is not necessarily critical.

Jabberd 2 Crashes after Start

Make sure all Jabberd 2 binaries have stopped

When Jabberd 2 crashes, one or more of the components (router, resolver, c2s, s2s and sm) may remain in a running state. Restarting Jabberd 2 while a component is running will only cause another crash. Before restarting, make sure that all Jabberd 2 components have stopped. Manually kill any running components before a restart. If you are debugging Jabberd 2, you may wish to use a simple shell script that will kill all Jabberd 2 processes:

        #!/bin/sh
        killall router
        killall resolver
        killall c2s
        killall s2s
        killall sm

Be careful when running as root

You should not run Jabberd 2 as root. Be aware that running Jabberd 2 as root may cause you additional problems. This is especially true if your installation uses Berkeley DB. If the Berkeley DB database is initialized by the root user, your jabber user will not have permissions to write to it.

Make sure that jabber user has path to binaries

Make sure that your jabber user is able to access a path to the Jabberd 2 binaries — if you su to your jabber user in a directory where the jabber user has no permissions, the jabber user will not be able to run Jabberd 2. You may wish to cd to the root directory before you su to your jabber user.

Make sure that jabber user has access to necessary paths

See Section 2.3 for information about creating directories and setting permissions for PID files and logging. By default, Jabberd 2 writes PID files to /usr/local/var/jabberd/pid, and logging is done to syslog. If you change logging to log to files, make sure that your jabber user has write permissions to the log directory.

Clients Cannot Connect to Server

Check DNS resolution

Check DNS resolution for your Jabberd 2 id. Your client must be able to resolve the id as set in sm.xml (near the top of the file) and in c2s.xml (under the local section):

        dig jabber.somedomain.com

If you are testing Jabberd 2 locally, you may wish to set the host in /etc/hosts (in $WINDOWS\system32\drivers\etc\hosts or $WINDOWS\lmhosts for Windows).

Make sure user name matches server

Make sure that your client is set to connect as a user that matches your Jabberd 2 id (as set in sm.xml and c2s.xml). For example, if your Jabberd 2 id is set to jabber.somedomain.com, your users must connect as something like some_user@jabber.somedomain.com.

Use client debug XML output

Use the debug output from your Jabber client, in addition to the debug output from Jabberd 2. Many Jabber clients provide very limited information for failed connections. To remedy this, enable the debug output in your Jabber client and attempt to connect to your Jabberd 2 server.

Try a different client

Try using a different Jabber client. You may wish to try this simply to rule out any potential Jabber client issues.

Clone this wiki locally