This morning after making some file changes and performing a server restart I found the Scalix 10 email server would not load. As I have never had to resolve major problems with Scalix determining the cause and solution to this error turned out to be a worthwhile experience.
Manually starting and stopping Scalix
According to the Scalix startup script (/etc/init.d/scalix) the service was successfully starting, but on closer inspection none of the actual processes were beginning. Unfortunately whilst the /etc/init.d/scalix script is a tidy way of controlling Scalix it does not provide any console logging to explain any issues that maybe encountered. For more useful output the two console commands that start/stop Scalix are:
- omrc - start Scalix
- omshut - stop Scalix
Thanks to omrc I was able to see that according to Scalix one of the core services, the Remote Client Interface (RCI), was in a 'shutdown process' and could not be loaded. A look on the Scalix Community Forums quickly came up with the answer here which was to run the command:
omreset -o off rci
The omreset command manually sets the status of the various Scalix services and the above comand forces the RCI service to the off state.
With this problem fixed Scalix successfully started happily enough but I then found that whilst I could log into the Administration interface, POP and SMTP services I could not however use IMAP or Webmail as my username/password was rejected. Solving this problem was a little trickier than the first but fortunately a look in the SAC administration IMAP logs showed that there were some file permissions errors occurring as a consequence of the file changes I had undertaken before the server reboot.
Checking file permissions
Fortunately Scalix has a very useful tool for checking and correcting file ownership and privilege issues called omcheck. To correct file privilege issues run the following command:
omcheck -s -d > /tmp/check_file ; sh /tmp/check_file
The above runs the omcheck command on the Scalix application and data files. Results are output to /tmp/check_file as a series of comments and chmod commands to correct any permission errors. Once omcheck has completed the output (tmp/check_file) is executed by the shell (sh), automatically correcting any issues found. I was relieved to see that after running this command IMAP and Webmail were once again working fine.
Overall solving these Scalix issues was a very good learning experience. It took quite a long time simply because of my limited experience of dealing with Scalix issues and the overly complex manner by which Scalix is configured and operates compared to other email servers. All of the answers were found on the Scalix Community Forums but finding them took a lot of searching, reading and experimenting. There is a lot of content on the forums mainly I think because Scalix is overly complex and can easily lead to problems. Hopefully with Scalix 11 and future versions these configuration and maintenance tasks become simpler, more concise and a lot more intuitive.