** Solved w/ Workaround** Still having "Create New Site ERROR" with Ubuntu 16.04

This problem was solved with a workaround by @James_Robertson near the end of thread. Thanks again.

Ok, I have read through the thread here:

And I have tried editing the file /etc/mysql/conf.d/settings.cnf to comment out the line:

socket = /var/lib/mysql/mysql.sock

This was the solution provided by @anebi in this part of the same thread:

Well, after performing this edit to comment out the line and restarting the mariadb server, I am still unable to even get to the login screen for ERPNext. It seems as if the installation never completed enough to get the website to run.

Additionally I looked for the file “my.cnf” to attempt to edit it as well, but i never was able to locate it. Besides, there is really no indication of how it was supposed to be edited anyway in the solution post.

So Here I am asking if there is really a solution to this issue when trying to setp up a PRODUCTION server using the INSTALL.PY script?

Here is what I get when I try it, and it fails every time:

TASK [Gathering Facts] *****************************************************************************************
ok: [localhost]
TASK [Check whether a site exists] *****************************************************************************
ok: [localhost]
TASK [Create new site] *****************************************************************************************
fatal: [localhost]: FAILED! => {“changed”: true, “cmd”: [“bench”, “new-site”, “site1.local”, “–admin-password”,
“mypassword”, “–mariadb-root-password”, “mypassword”], “delta”: “0:00:01.978899”, “end”: “2018-01-15 16:24:20.
546480”, “failed”: true, “rc”: 1, “start”: “2018-01-15 16:24:18.567581”, “stderr”: “ERROR 2002 (HY000): Can’t co
nnect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)”, “stderr_lines”: [“ERROR 2002 (HY0
00): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)”], “stdout”: “Database
not installed, this can due to lack of permission, or that the database name exists.\nCheck your mysql root pas
sword, or use --force to reinstall”, “stdout_lines”: [“Database not installed, this can due to lack of permissio
n, or that the database name exists.”, “Check your mysql root password, or use --force to reinstall”]}
to retry, use: --limit @/tmp/.bench/playbooks/production/install.retry
PLAY RECAP *****************************************************************************************************
localhost : ok=73 changed=45 unreachable=0 failed=1
Traceback (most recent call last):
File “install.py”, line 388, in
File “install.py”, line 114, in install_bench
run_playbook(‘production/install.yml’, sudo=True, extra_vars=extra_vars)
File “install.py”, line 326, in run_playbook
success = subprocess.check_call(args, cwd=os.path.join(cwd, ‘playbooks’))
File “/usr/lib/python2.7/subprocess.py”, line 541, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command ‘[‘ansible-playbook’, ‘-c’, ‘local’, ‘production/install.yml’, ‘-e’, ‘@/t
mp/extra_vars.json’, ‘–become’, ‘–become-user=erp_jmi’]’ returned non-zero exit status 2

When I look into the passwords they are correct, so the line indicating we should check the password seems odd.

At this point I (and imagine many others) are still stuck in this install nightmare. I am currently working with a new hosting location and the only OS available to me are Ubuntu 16.04 and Centos 7 both of which fail with the install.py script but for different reasons. In both cases I have also followed the new additions to the instructions under the “Easy Install” section located here:


So, I am stuck. I have tried the supposed solution for this and it still does not work. I am looking for a way to get the install script to complete properly -or- a valid set of instructions to complete the process once the install.py breaks as posted above.

Any ideas?



After looking into the error log for mysql located /var/lib/mysql/mysql-error.log

I found the following error (or rather warning) posted as the last line:

2018-01-15 16:24:20 139812664715008 [Warning] Access denied for user ‘erp_jmi’@‘localhost’ (using password: NO)

So the next logical question is this: Does this error message tell me that for some reason the install script tried to start the database without using a password?

Any ideas?


EDIT #2:

You can see by this dump of passwords.txt that they are clearly in place and should be working:

erp_jmi@ubuntu16-test:~$ ls
frappe-bench get-pip.py install.py passwords.txt
erp_jmi@ubuntu16-test:~$ cat passwords.txt
“mysql_root_password”: “mypassword”,
“admin_password”: “mypassword”

I am really at a loss here.


This one must be tougher than I thought. Nobody has any idea how to get past it.


Yes but does your erp_jmi user have access rights to the mysql dB ? This would not necessarily be the case … the permission s should be defined for this user and a particular db

Well, since the mysql database is installed during the install.py script, and the script was meant to be run from a user account and NOT root, then i cannot imaging the user logged onto the console would matter.

Plus, this same install.py script works on Debian 8 and Ubuntu 14.04 while similarly logged in and using the exact same user name and install command syntax.

I am not saying the problem is not user related, but I would not know how to alter it during the install script running. That synrtax is as follows:

sudo python install.py --production --user erp_jmi



I succeeded first time editing the socket location in my.cnf and settings.cnf. But my Frappe version installed 9.something which should be 10.something. So, I tried again & again after that and I too am having this same issue as well.

Then I tried manual installation and creating new site there gives me error too.

@anebi Brother, do you have an idea what’s going wrong!?

If you mariadb has installed run these commands from the console:

sudo mysql -u root
# That will gain entry into the database

From the database command prompt, run:
select User,host,plugin from mysql.user;

What is the plugin for root?

hey guys i just solved it right now but it needs to be done on the frappe/bench repo , so can you mention them to come here to contact with us to apply the solution :slight_smile:

Edit : i already open pull request for the fix and i wish if they accept it soon

1 Like

what was it that you put in a PR? The easy install script works fine with an out of box ubuntu 16.04 install. The whole issue you had was around the location of the mariadb socket file. The ansible scripts were looking for it in a very specific place.

The is NOT the experience the rest of us are having. It was only working on Ubuntu 14.04. If we try to install on 16.04 the errors begin and the install process exits without completion.


The install script is very opinionated. If you have done configuration work or other package installs before you run it, there can be issues. For example a lot of folks want to move the out of box location of the mariadb/mysql lock file from the place the scripts are looking for it. If the script can’t find the lock file, it can’t open a socket and so can’t connect to the database, even if you can all on your won by hand. There have been a few tweaks to the install script over the last couple months due to some PRs that I put in. Lemme run through some tests and report back.

If you have a Google Cloud Platform account, you can easily spin up Unbutu and Centos servers of multiple versions to run testing. That is where I am testing at this point until I get either CentOS 7 or Ubuntu 16.04 to work. Then I will load my real host.


1 Like

Yes, me too. Along with good old VMVirtualBox as well.

Ok I found the issue on Ubuntu 16.04 (at least for now, could be present on all the others). MariaDB 10.2, which is installed by the install.py script has conflicting configuration files. The base /etc/mysql/my.cnf file has the socket file in the right place, but it is over ridden by a subsequently read /etc/mysql/conf.d/settings.cnf file that places it the socket in /var/lib/mysql instead of the expected /var/run/mysql. Bummer. I personally prefer the socket to live in /var/run and not /var/lib. This is the current workaround:

Before you run install.py, copy and paste the two commands into a putty window to create our own cnf file BEFORE you run the install.py script.

sudo mkdir -p /etc/mysql/conf.d
sudo bash -c "cat <<EOF > /etc/mysql/conf.d/z-erpnext.cnf
# Begin /etc/mysql/conf.d/z-erpnext.cnf
# MariaDB Configuration for ERPNEXT

pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock

# End /etc/mysql/conf.d/z-erpnext.cnf

Hmm… While your script idea does in fact allow the install.py script to complete, the resulting server is not viable. When you try to access the servers login screen this is what you get

Ok, the above statement WAS correct. I have since deleted the server and spun up another one. I cut and pasted in your edits and then ran the install.py

The resulting server was then REBOOTED before attempting to access the login screen and it appears to have worked.

I deleted the failure listing from this post and am now testing if the resulting server works as expected.

Regardless, the first attempt to use your solution was a failure, and then after trying it again twice more I got it to work on the GCP service with their stock Ubuntu 16.04 images. After testing the resulting ERPNext system, I will try this same fix on my production server.

BTW… I also got a message from GCP that they were experiencing load problems in the eastern USA with their east coast servers. This may have been the real cause of the failure. So, I test it anyway to be sure. Thanks again.

Thank you @James_Robertson for the time you invested in the patch.


You are welcome @bkm. I have since tested the steps on Ubuntu 14.04, 16.04, CentOS 7 (still has the /home/root issue, but it works). I will run a scripted build on Debian 7 and 8 just to make sure. One of these days the bench admins will pick up my PR to get Debian 9 support.

1 Like


Your extra script is not needed on Ubuntu 14.04 and Debian 8. Those OS versions work with no extra tinkering.

CentOS 7 still problems, but at least I have the Ubuntu16.04 to work with now. Thanks again.