Error: mysql config parsing failed

[grenadecx]

Yo!

Okay so I've been running VestaCP for over a year now and I'm happy with it. Usually I fix a lot of the problems I've got myself but I'm kinda stuck on this one.

I'm running Vesta with a remote mysql server. Apparently VestaCP runs some kinda of backup of my admin account every 5 minutes and it fails everytime with the error:

Code: Select all

Error: mysql config parsing failed

I guess it has something to do with me adding a remote mysql server. But here's the catch, running backups manually from the webinterface works fine.

/usr/local/vesta/conf/mysql.conf

Code: Select all

HOST='192.168.0.30' USER='root' PASSWORD='*********' CHARSETS='UTF8,LATIN1,WIN1250,WIN1251,WIN1252,WIN1256,WIN1258,KOI8' MAX_DB='500' U_SYS_USERS='admin' U_DB_BASES='9' SUSPENDED='no' TIME='09:57:00' DATE='2015-03-05'

v-list-database-hosts

Code: Select all

HOST              MAX_DB    U_DB_BASES  SUSPENDED  DATE
 ------                ------           ------                   ------                 ------
 192.168.0.30  500             9                        no                    2015-03-05

So by the looks of it, things seems to be parsing just fine. I'm not sure what's going on here. Any help would be appreciated. Because as long as this is broken I can't enable backups because it fills up my space with tmp directories from failed attempts every 5 min it runs on the admin account.

[grenadecx]

Hi,

Do you mean to say that the mysql error thrown by the local server is in regards to the remote mysql server?

If yes, then there is a problem to connect both servers through api.

I'm not quite sure what you mean. All I know is that when I enable local/remote backup, backups are not done correctly since I get a ton of tmp.<RANDOM> folders in my backup directory and errors in log file.

When checking the log /var/log/vesta/backup.log I find

Code: Select all

-- DB --
Error: mysql config parsing failed 

However, if I run the backup manually from the webinterface:

Code: Select all

-- DB --
2016-06-07 11:01:10 admin_gxbfc (mysql)
2016-06-07 11:01:11 admin_dodef (mysql)
2016-06-07 11:01:13 admin_owncloud (mysql)
2016-06-07 11:01:14 *** 3 databases ***

And then it completes successfully.

I added the mysql server through the command:

Code: Select all

v-add-database-host mysql 192.168.0.30 root *********

I just don't understand why it would fail. I assume the webinterface and the cronjob uses the same file for backup.

[grenadecx]

Okay. I fixed the parsing error. It was me being stupid. Apparently I had some old database referencing to the local mysql server that is no longer running and it caused the problem.

But I do still have problem with the backup script at the end. It looks like it completes:

backup runs with

Code: Select all

-- SUMMARY --
2016-06-07 17:00:30 Local: /backup/admin.2016-06-07.tar
2016-06-07 17:00:30 Size: 177 Mb
2016-06-07 17:00:30 Runtime: 1 minute
sh: 0: getcwd() failed: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
sh: 0: getcwd() failed: No such file or directory
exim: can't get the current working directory: No such file or directory

I see exim there, wonder if that have anything to do with sending out the mail, since I didn't get any.

[grenadecx]

Hi,

I think your you wrote the message above at the same time. After reading your message regarding mysql solving, I once again repeat that you do need to following what I am saying.

No, it has nothing to do with exim. Pl. stick with my instructions.

Thanks for helping out, I really appreciate it. I did as you suggested:

Code: Select all

root@ignition:/backup# cat /usr/local/vesta/conf/vesta.conf | grep BACKUP_SYSTEM
BACKUP_SYSTEM='local'

root@ignition:/backup# v-delete-backup-host sftp
Error: invalid backup type
root@ignition:/backup# v-delete-backup-host ftp
Error: invalid backup type

root@ignition:/backup# ls -ls /usr/local/vesta/conf/
total 8
4 -rw-rw---- 1 root root 228 mar 22 15:03 mysql.conf
4 -rw-rw---- 1 root root 527 jun  7 16:44 vesta.conf

root@ignition:/backup# cat /usr/local/vesta/conf/vesta.conf | grep BACKUP_SYSTEM
BACKUP_SYSTEM='local'

Then I finally did another backup:

Code: Select all

root@ignition:/backup# v-backup-user admin yes

-- SYSTEM --
2016-06-07 17:26:11 admin.conf
2016-06-07 17:26:11 stats.log
2016-06-07 17:26:11 history.log
2016-06-07 17:26:11 backup-excludes.conf
2016-06-07 17:26:11 pam

-- WEB --
2016-06-07 17:26:11 ignition.mclip.se
2016-06-07 17:26:11 mclip.se
2016-06-07 17:26:28 wiki.mclip.se
2016-06-07 17:26:31 *** 3 domains ***

-- DNS --
2016-06-07 17:26:31 ignition.mclip.se
2016-06-07 17:26:31 *** 1 domain ***

-- DNS --
2016-06-07 17:26:31 ignition.mclip.se
2016-06-07 17:26:31 *** 1 domain ***

-- MAIL --
2016-06-07 17:26:31 ignition.mclip.se
2016-06-07 17:26:31 *** 1 domain ***

-- DB --
2016-06-07 11:01:10 admin_gxbfc (mysql)
2016-06-07 11:01:11 admin_dodef (mysql)
2016-06-07 11:01:13 admin_owncloud (mysql)
2016-06-07 11:01:14 *** 3 databases ***

-- CRON --
2016-06-07 17:26:35 *** 7 jobs ***

-- User Dir --
2016-06-07 17:26:35 adding .bash_history
2016-06-07 17:26:35 adding .bash_logout
2016-06-07 17:26:35 adding .bashrc
2016-06-07 17:26:35 adding .cache
2016-06-07 17:26:35 adding .profile
2016-06-07 17:26:35 adding .sudo_as_admin_successful
2016-06-07 17:26:35 adding tmp
2016-06-07 17:26:35 adding .viminfo
2016-06-07 17:26:35 *** 8 directories ***

-- SUMMARY --
2016-06-07 17:26:35 Local: /backup/admin.2016-06-07.tar
2016-06-07 17:26:36 Size: 177 Mb
2016-06-07 17:26:36 Runtime: 1 minute
sh: 0: getcwd() failed: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
sh: 0: getcwd() failed: No such file or directory
exim: can't get the current working directory: No such file or directory

It doesn't create tmp folders anymore and the tar file is there. But as I said it still gives error at the end and I do not get an email notification for the backup, which I assume I would get since I specify yes as the second parameter.

[grenadecx]

Hi,

Is this BACKUP_SYSTEM='local' in the vesta.conf changed. To me it looks like the dying resedu seems to be still in there. If there is ftp or sftp command in there, it would execute and go further.

Just make sure that this is exactly BACKUP_SYSTEM='local' in there.

We will work on the notifications later, but only if this error that we are working on is ironed out.

As shown above, the BACKUP_SYSTEM variable in vesta.conf is set to local only.

Code: Select all

root@ignition:/backup# cat /usr/local/vesta/conf/vesta.conf | grep BACKUP_SYSTEM
BACKUP_SYSTEM='local'

Code: Select all

root@ignition:/backup# cat /usr/local/vesta/conf/vesta.conf

WEB_SYSTEM='nginx'
WEB_PORT='80'
WEB_SSL_PORT='443'
WEB_SSL='openssl'
WEB_BACKEND='php5-fpm'
STATS_SYSTEM='webalizer,awstats'
FTP_SYSTEM='vsftpd'
DNS_SYSTEM='bind9'
MAIL_SYSTEM='exim4'
ANTIVIRUS_SYSTEM='clamav-daemon'
ANTISPAM_SYSTEM='spamassassin'
IMAP_SYSTEM='dovecot'
CRON_SYSTEM='cron'
FIREWALL_SYSTEM='iptables'
FIREWALL_EXTENSION='fail2ban'
DISK_QUOTA='yes'
BACKUP_SYSTEM='local'
LANGUAGE='en'
VERSION='0.9.8'
DB_SYSTEM='mysql'
DB_PMA_URL='http://ignition.mclip.se/phpmyadmin'
MAIL_URL='http://ignition.mclip.se/webmail'

[grenadecx]

Hi,

You make me laugh because we both seems to be writing at the same time.

I did not see the last line earlier. After giving a message, I saw it and change my message immediately. Well, you captured this and answered. But please rebuild, like I said.

Yeah I noticed :) I'm not quite sure how to check if it's valid from cron, but I did go to the admin account in the webinterface and updated/changed the email. I then did the rebuild, no errors.

But the backup gives the same error. Am I missing something?

[grenadecx]

Hi,

Now it should not give an error, I believe after rebuilding because it does a local backup. Somehow it tries to connect to the directory and does not have ennough permission or cannot find it.

This usually happens when one has connection problems with the remote server.

Now this is non-exitant as you do it locally.

Anathor possibility is to uncomment in vesta.conf any reference of the remote server for the time of trouble shooting and restart Vesta.

I believe that some command is still activating remote api and cannot connect.

I'm currently looking at the backup file and trying to do some debugging.

Code: Select all

echo "START"
# Send notification
if [ "$notify" != 'no' ]; then

    subj="$user → backup has been completed"
    
    echo "MIDDLE"
    
    email=$(get_user_value '$CONTACT')
    
    echo $email
    
    echo -e "$msg" |$send_mail -s "$subj" $email
fi

echo "END"

As you can see, I added some debugging messages around the notification bit to see if I get the mail and where exactly it fails. Results:

Code: Select all

START
MIDDLE
[email protected] <----- as you can see the email is here
sh: 0: getcwd() failed: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory                                                               
job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
sh: 0: getcwd() failed: No such file or directory
exim: can't get the current working directory: No such file or directory 
END

As we can see, it actually can get the email. So the problem seems to be this line:

Code: Select all

echo -e "$msg" | $send_mail -s "$subj" $email

I'm gonna do some more digging to see what I can find....

[grenadecx]

I'm still debugging but I now know which exact line that is causing the issue.

First, I was looking at what command. So vesta runs this command:

Code: Select all

echo -e "$msg" | $send_mail -s "$subj" $email

So what I did was to translate it just above to print out the actual command, except the $msg because it's huge.

Code: Select all

echo "echo \"msg\" | $send_mail -s \"$subj\" $email"

So as you can see, this will echo out the command for me, with this I got the exact command:

echo "msg" | /usr/local/vesta/web/inc/mail-wrapper.php -s "admin → backup has been completed" [email protected]

Now when I had the exact command, I was curious and just ran it directly from the terminal and it actually went through and sent the mail. So I copied the same line and put it above in the same v-backup-user file and run it, doesn't work, it gives me the same error.

So it seems the command does not work when I run it from the bash script. I'm not sure why that is, but yeah :/ Also I followed the mail-wrapper.php to look closer at which line it actually fails on inside, and it's the php built-in mail function inside that is run inside send_email function in /usr/local/vesta/web/inc/main.php, line 275.

I must be missing something, this is ridiculous. Why would it work from the terminal and not from the bash script that is run from the terminal?