[March 2019] ERPNext installation bug

Check if mysql is up…

sudo systemctl status mysql

and also test if you can start it manually

sudo systemctl restart mysql

mysql is up and running. still facing the same issue. Could it be a bug on ERPNext installation of mysql? see mysql status below

● mariadb.service - MariaDB 10.2.22 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: active (running) since Thu 2019-03-21 08:40:44 EDT; 1min 40s ago
Docs: man:mysqld(8)
systemd - MariaDB Knowledge Base
Main PID: 17847 (mysqld)
Status: “Taking your SQL requests now…”
CGroup: /system.slice/mariadb.service
└─17847 /usr/sbin/mysqld

Mar 21 08:40:43 erpnext systemd[1]: Starting MariaDB 10.2.22 database server…
Mar 21 08:40:43 erpnext mysqld[17847]: 2019-03-21 8:40:43 139902830549184 [Note] /usr/sbin/mysqld (
Mar 21 08:40:43 erpnext mysqld[17847]: 2019-03-21 8:40:43 139902830549184 [Warning] Could not incre
Mar 21 08:40:43 erpnext mysqld[17847]: 2019-03-21 8:40:43 139902830549184 [Warning] Changed limits:
Mar 21 08:40:44 erpnext systemd[1]: Started MariaDB 10.2.22 database server.
lines 1-17/17 (END)

@nakejelu you are using easy install method right? Can you post here the command line that you used to start the script?

1 Like

I thought we were already up to MariaDB version 10.3.8 or greater?

BKM

Yes i am using easy installation

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

This was automatically downloaded from the script. i did the installation on a fresh server

the script is not able to change over as user frappe. Did you manually create user frappe?
what are you logged in as?

I am logged in as an administrator. i didnt manually create the user frappe. it was created from the script

it’s not advisable to run the script as root. At the minimum log in as ubuntu user (I assume that would be default in your server) and run the script again.
Also, if it is a VPS, do sudo apt update before you do anything else.

i purged mysql and did the installation again it was successful but if i try to access the application it comes up and goes off after some seconds with error message “Internal server error”. i tried to check the list of ports running:

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1129/sshd
tcp 0 0 127.0.0.1:11000 0.0.0.0:* LISTEN 2080/redis-server 1
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2781/master
tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 2069/python
tcp 0 0 127.0.0.1:12000 0.0.0.0:* LISTEN 2091/redis-server 1
tcp 0 0 127.0.0.1:13000 0.0.0.0:* LISTEN 2085/redis-server 1
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 1257/redis-server 1
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1810/nginx -g daemo
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1053/dnsmasq
tcp6 0 0 :::22 :::* LISTEN 1129/sshd
tcp6 0 0 :::25 :::* LISTEN 2781/master
tcp6 0 0 :::9000 :::* LISTEN 2070/node
tcp6 0 0 :::53 :::* LISTEN 1053/dnsmasq

However i noticed something strange. I can’t find mysql running and i tried to check the status and got this error:

mariadb.service - MariaDB 10.2.22 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: failed (Result: timeout) since Thu 2019-03-21 09:13:48 EDT; 26min ago
Docs: man:mysqld(8)
systemd - MariaDB Knowledge Base
Process: 1630 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (
Process: 1165 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin
Process: 1156 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exit
Process: 1124 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exite
Main PID: 1630 (code=exited, status=0/SUCCESS)

Mar 21 09:12:15 erpnext systemd[1]: Starting MariaDB 10.2.22 database server…
Mar 21 09:12:18 erpnext mysqld[1630]: 2019-03-21 9:12:18 140109290084544 [Note] /usr/sbin/mysqld (m
Mar 21 09:12:18 erpnext mysqld[1630]: 2019-03-21 9:12:18 140109290084544 [Warning] Could not increa
Mar 21 09:12:18 erpnext mysqld[1630]: 2019-03-21 9:12:18 140109290084544 [Warning] Changed limits:
Mar 21 09:13:47 erpnext systemd[1]: mariadb.service: Start operation timed out. Terminating.
Mar 21 09:13:48 erpnext systemd[1]: Failed to start MariaDB 10.2.22 database server.
Mar 21 09:13:48 erpnext systemd[1]: mariadb.service: Unit entered failed state.
Mar 21 09:13:48 erpnext systemd[1]: mariadb.service: Failed with result ‘timeout’.
lines 1-21/21 (END)

Is this on a VPS server?

If so, can you tell us if you are using a KVM type VPS server?

I have seen a similar MariaDB crash when trying to run ERPNext on an OpenVZ type VPS server. In my experience, ERPNext will only run reliably on a KVM type VPS server.

I have only encountered the “Start operation timed out” error with MariaDB when I tried using the wrong type VPS.

BKM

Perhaps check the various logs for clues?

frappe@ubuntu:~/frappe-bench$ ls -al /var/lib/mysql/mysql-error.log 
-rw-rw---- 1 mysql mysql 197012 Feb  4 00:49 /var/lib/mysql/mysql-error.log

10.3.x is also causing problems during installation, because MariaDB made some changes to parameters. I’ve got a pull request submitted to develop branch. But until that gets pushed to master, it’s probably safest to stay on MariaDB 10.2.x or earlier.

Perhaps port 3306 is closed?

frappe@ubuntu:~/frappe-bench$ sudo find /etc -name ‘my.cnf’
/etc/mysql/my.cnf
frappe@ubuntu:~/frappe-bench$ grep 3306 /etc/mysql/my.cnf
port = 3306
port = 3306

You should expect to see these:

frappe@ubuntu:~/frappe-bench$ sudo ufw status | grep 3306
[sudo] password for frappe:
3306/tcp ALLOW Anywhere
3306/tcp (v6) ALLOW Anywhere (v6)

frappe@ubuntu1804lts:~/frappe-bench$ sudo netstat -tlnp | grep 3306
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 16597/mysqld

I’m using a KVM type of VPS

Looks like mysql crashed>

2019-03-21 9:50:34 139929813116672 [Note] InnoDB: Buffer pool(s) load completed at 190321 9:50:34
2019-03-21 9:50:55 139929778939648 [ERROR] mysqld: Table ‘./1bd3e0294da19198/__global_search’ is marked as crashed and should be rep$
2019-03-21 9:50:55 139929778939648 [ERROR] mysqld: Table ‘__global_search’ is marked as crashed and should be repaired

This suggests what to try in the case of a production instance Database crash __global_search’ needs repair

If you don’t need to backup and restore your current data, just run ‘bench reinstall’ - that will delete the contents of your database and then rerun the setup_wizard.

looks like a maria db problem. i wiped the serve clean and started a fresh installation. I got this error below;

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: OperationalError: (1054, “Unknown column ‘’ in ‘field list’")
failed: [localhost] (item=localhost) => {“changed”: false, “item”: “localhost”, “msg”: "(1054, "Unknown column '
’ in ‘field list’")”}
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: OperationalError: (1054, “Unknown column ‘’ in ‘field list’")
failed: [localhost] (item=127.0.0.1) => {“changed”: false, “item”: “127.0.0.1”, “msg”: "(1054, "Unknown column '
’ in ‘field list’")”}
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: OperationalError: (1054, “Unknown column ‘’ in ‘field list’")
failed: [localhost] (item=::1) => {“changed”: false, “item”: “::1”, “msg”: "(1054, "Unknown column '
’ in ‘field list’")”}

RUNNING HANDLER [mariadb : restart mysql] **********************************************************
to retry, use: --limit @/tmp/.bench/playbooks/site.retry

PLAY RECAP *****************************************************************************************
localhost : ok=22 changed=5 unreachable=0 failed=1

Traceback (most recent call last):
File “install.py”, line 425, in
install_bench(args)
File “install.py”, line 122, in install_bench
run_playbook(‘site.yml’, sudo=True, extra_vars=extra_vars)
File “install.py”, line 338, 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’, ‘site.yml’, ‘-e’, ‘@/tmp/extra_vars.json’, ‘–become’, ‘–become-user=frappe’]’ returned non-zero exit status 2

Given @nakejelu has this other thread on this same topic

To avoid confusion and duplication I will close this one.