FAQ

Our goal with this page is to have a central place where people can easily find tips and solutions to technical problems related to Mconf-Web. If you did not find here what you were searching, contact us at our mailing list ([email protected]) and we will try to answer your question and also improve this page.

Emails are not being sent

Mconf-Web 2.0

To start, try to understand how emails are sent in Mconf-Web.

The site table has several columns that store the information about your SMTP account. You can configure them in the management page. These configurations will be used to send all emails from within Mconf-Web.

When an email needs to be sent, the application will store information internally (using redis) and an external process (Resque) will read the job and deliver the email. This process is monitored by another process called Monit, that is also responsible for starting and stopping it. To know how to use Monit, see this page.

So, unless you have Monit and Resque running on your servers, no emails will be delivered. You can check if they are running with:

$ ps aux | grep -e resque -e monit
root      4341  0.0  0.0 108556  1348 ?        Sl   Jun01   3:52 /usr/bin/monit -c /etc/monit/monitrc
mconf     5957  0.0  6.7 944300 138276 ?       Sl   Jun16   1:38 resque-1.25.2: Waiting for *
mconf     6004  0.0  6.7 944112 138164 ?       Sl   Jun16   1:40 resque-1.25.2: Waiting for *
mconf     6053  0.0  6.7 944276 138260 ?       Sl   Jun16   1:43 resque-1.25.2: Waiting for *
mconf     9328  0.1  6.8 1473604 140672 ?      Sl   06:20   0:26 resque-scheduler-3.0.0[production]: Schedules Loaded

If they are not running, make sure everything is installed correctly and try to restart Monit and Resque, always following the guide to install Monit.

If they are running, the next step is to check Resque monitoring interface. Open Mconf-Web in your browser and sign in as an administrator. Then access the URL /manage/resque. This page will show you how many Resque workers are running and a list of queues with the jobs being processed and possibly a list of failed jobs. If there are failed jobs, open the "failed" queue and check the errors that are happening. This is usually the easiest way to find common errors such as wrong SMTP credentials.

If you still can't figure out why emails are not being sent, check the logs generated by Resque and Monit, they might point you in the right direction. You can see where to find these logs in this page.

Moreover, remember that whenever you change the SMTP information in your Mconf-Web, you have to restart all Resque processes, otherwise they will still be using the old configurations!

Mconf-Web 0.8.x

To start, try to understand how emails are sent in Mconf-Web.

The site table has several columns that store the information about your SMTP account. You can configure them in the management page. This email will be used to send all emails from within Mconf-Web. Currently only you can use an SMTP account, including Gmail accounts.

When an email needs to be sent, a "job" is stored in the database and an external process (a gem called delayed_job) will read the job and deliver the email. This process is monitored by another gem called god, that is also responsible for starting and stopping it. So you don't ever need to deal with delayed_job directly, only with god.

To know how to use god, see this page. Once you have it installed, you can try to stop it, restart and check the log in case of errors:

$ sudo /etc/init.d/god terminate
$ sudo /etc/init.d/god start

This is the default log file for god. It is created when god is executed by the script /etc/init.d/god:

$ tail -100 /var/log/god.log

Also, sometimes god might start but delayed_job won't. You can see the delayed_job log files at:

~/mconf-web/current/log/god_delayed_job.0.log
~/mconf-web/current/log/god_delayed_job.1.log

The directories where these files are located are defined in delayed_job's config file. You can see this file on our GitHub page and in your machine it should be at:

/etc/god/conf.d/delayed_job.god

Check if the file it is correct.

The way this script starts delayed_job is with a command like this:

$ cd /home/mconf/mconf-web/current; /usr/bin/env RAILS_ENV=production bundle exec script/delayed_job --pid-dir=/home/mconf/mconf-web/current/tmp/pids -i 0 start

You can try to run this command to see what happens, it should otuput the error (if any) in the console. This is executed with the user mconf.

If it doesn't work, there is an even simpler version of it:

$ cd /home/mconf/mconf-web/current
$ /usr/bin/env RAILS_ENV=production bundle exec script/delayed_job start

Also, make sure that your application's .rvmrc file is trusted (more details here), otherwise delayed_job might not start:

$ rvm rvmrc trust ~/mconf-web/current/.rvmrc

If you're in a development environment, you don't need god. Just run delayed_job with:

$ bundle exec script/delayed_job -n 2 start

If you're familiar with Rails and the Rails console, you can use a few more advanced commands to deal with emails. Open your Rails console (RAILS_ENV=production bundle exec rails s) and:

# find how many jobs are in the queue
Delayed::Job.find(:all).count
# retry a single job
Delayed::Job.find(:all)[0].payload_object.perform
# for all jobs
Delayed::Job.find(:all).each { |j|
  begin
    j.payload_object.perform
  rescue Exception => e
    puts e.inspect
  end
}
# remove a job
Delayed::Job.find(:all)[0].destroy

Wrong username and/or password for MySQL

The following box shows an example of an error that occurs when your Mysql2 user and/or password are wrong and you're trying to setup Mconf-Web. The following error has happened trying to setup a production environment using the wrong database password for the user "root".

Couldn't drop mconf_production : #<Mysql2::Error: Access denied for user 'root'@'localhost' (using password: YES)>
* Running the task: db:create
Access denied for user 'root'@'localhost' (using password: YES).
Please provide the root password for your mysql installation

The database username and password are configured in the file config/database.yml. See more about this file at this page.

If you haven't set up a password for MySQL yet, you can do it with:

mysqladmin -u root password "NEW-PASSWORD"

Or, in case you want to change the password:

mysqladmin -u root -p password "NEW-PASSWORD"

OpenSSL::SSL::SSLError

If you see an error similar to the one below in your application's log file, you are probably accessing the application using HTTP but SSL is enabled in your site (or the opposite).

OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol)

To fix it, go to your application's directory and open the rails console:

cd /var/www/mconf-web/current
RAILS_ENV=production bundle exec rails c

And then run:

Site.current.update_attributes(:ssl => false)

If you're seeing this error in a background job (e.g. when trying to send an email), the flag you should set to false is smtp_use_tls:

Site.current.update_attributes(:smtp_use_tls => false)

Then remember to restart your application and all background jobs to make sure the change is applied.