Verifying the Installation & Troubleshooting

Authentication Failures

Symptoms include:

• You are unable to login to Roundcube,

• Desktop client cannot connect to / authenticate against IMAP,

• You are unable to login to the web administration panel,

• Mail cannot be sent and is not being received.

and possibly others.

1. Does the following command work?

   # kolab lm

   This should give you a list of mailboxes.

2. Is the kolab-saslauthd service running?

   # service kolab-saslauthd status

   Note

   Some deployments with only a single parent domain name space may have elected to run the Cyrus SASL authentication daemon (the saslauthd service).

3. Is it functional?

   # testsaslauthd -u cyrus-admin -p <password>

   You can obtain the value from <password> from /etc/kolab/kolab.conf, in the [cyrus-imap] section, setting admin_password.

4. Is LDAP running?

   # service dirsrv status

IMAP Connections Reset or Timeout

Symptoms include:

• A user, program or process seems to hang, and ultimately be disconnected,

• kolab list-mailbox-metadata user/john.doe@example.org may hang, and ultimately disconnect or be disconnected.

Possible causes:

• Too many Cyrus IMAP processes hold locks on the mailbox index database.

Troubleshooting steps:

1. Determine the users’ folder that may be held too many locks on:

   # kolab list-mailbox-metadata user/john.doe*@example.org
   Folder user/john.doe@example.org

   The folder that too many locks are being held on will result in an apparent freeze, with no timely response.

2. Tail /var/log/maillog and grep for the relevant username:

   # tail -n 0 -f /var/log/maillog | grep john.doe@example.org

3. In a new terminal, issue the kolab list-mailbox-metadata command again, and example the output of the tail command issued to determine the process ID:

   (datetime) (hostname) imap[22164]: login: (from) [(ip)] john.doe@example.org PLAIN+TLS User logged in SESSIONID=<(fqdn)-(pid)-(timestamp)-1>

4. Use strace to determine the state of this process:

   # strace -s 200 -p 22164
   Process 22164 attached - interrupt to quit
   fcntl(13, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = ? ERESTARTSYS (To be restarted)

   This command too will not yield any additional output.

5. The PIDs of the processes holding an open file pointer to the mailbox tree can be found using the following command:

   # lsof -t +d $(/usr/lib/cyrus-imapd/mbpath user/john.doe@example.org)

6. At your discretion, opt to kill the processes that may be waiting for one another to release the lock:

   # lsof -t +d $(/usr/lib/cyrus-imapd/mbpath user/john.doe@example.org) \
       | xargs -n 1 kill -9
   kill 24904: No such process
   (...)

   The “No such process” output comes from attempts to kill processes that have meanwhile already been ended.

Troubleshooting for HTTP-based services

A good first start to troubleshoot an issue with a HTTP-based service is to check your webserver’s error log. For Apache this usually resides in /var/log/apache2/ or /var/log/httpd/.

Often, you will be able to find some useful information about your problem which enables you to fix it yourself. Doing an internet search for the error message is also a good idea. If you do not find anything about your problem, you might ask on the Kolab users mailing list about it. Please include the version number of the package that is causing the issue.

If you are sure that you have found something that needs fixing from Kolab’s developers, you can as file an issue in the public tracker after checking that it has not been reported already.

Enable General Error Logging

Before you start to debug your problem, please make sure that you actually have error logging enabled.

You would edit the file /etc/roundcubemail/config.inc.php and verify that the debug level is set correctly.

$config['debug_level'] = 1;

Note

The tail -f command can be helpful in identifying the right message during incoming requests. It displays changes to the log file on the screen as the log messages come in.

Kolab Webclient

After enabling general error logging, you should already find some messages in your webserver’s error log.

Additionally, the following configuration options are available for specific debugging.

// Log sent messages to /var/log/roundcubemail/sendmail
$config['smtp_log'] = true;

// Log session authentication errors to /var/log/roundcubemail/session
$config['log_session'] = true;

// Log SQL queries to /var/log/roundcubemail/sql
$config['sql_debug'] = true;

// Log IMAP conversation to /var/log/roundcubemail/imap
$config['imap_debug'] = true;

// Log LDAP conversation to /var/log/roundcubemail/ldap
$config['ldap_debug'] = true;

// Log SMTP conversation to /var/log/roundcubemail/smtp
$config['smtp_debug'] = true;

It is also possible to debug the Kolab Webclient for individual users only by creating a /var/log/roundcubemail/<username>/ folder and setting the following configuration parameter.

$config['per_user_logging'] = true;

Please make sure that this location is writeable by your webserver.

ActiveSync

For debugging ActiveSync issues, you would add the following to /etc/roundcubemail/config.inc.php:

$config['activesync_debug'] = true;

Useful messages should then appear in the /var/log/kolab-syncroton/console file. If there is no such file, please make sure that your webserver actually has the rights to create this file.

It is also possible to debug ActiveSync sessions of individual users only by creating a /var/log/syncroton/<username>/ folder and enabling per_user_logging mentioned above.

Please make sure that this location is writeable by your webserver.

iRony

After enabling general error logging, you should already find some messages in your webserver’s error log.

Additionally, you can enable the debug console that shows the internal function calls triggered by HTTP requests.

$config['kolabdav_console'] = true;

This will write debug log messages to /var/log/iRony/console.

It is also possible to debug DAV sessions of individual users only by creating a /var/log/iRony/<username>/ folder and enabling per_user_logging mentioned above.

Please make sure that this location is writeable by your webserver.

Sometimes it can be useful to track the full HTTP payload of DAV requests. In order to do this, add the following setting.

// (bitmask of these values: 2 = HTTP Requests, 4 = HTTP Responses)
$config['kolabdav_http_log'] = 6;