Noticed the same problem with the newest Ubuntu-Debian package, 4.1.2(7) installed in Linux Mint 17. LM 17 is based upon Ubuntu 14.04 LTS.
At first I thought it may be related to the relocation of the web directory to var/www/html, but Brady said that he was unable to replicate the situation in this post.
Firefox itself freezes and gives unresponsive script warnings in LM 17, despite multiple reinstalls. This never happened in LM 16. My device is a very old Dell Dimension 3000, with 512 MB of RAM, which was converted to Linux Mint when support for Windows XP stopped this past April.
Now I’m wondering if it is a hardware problem stemming from inadequate resources to support greater demands of the new operating system. Almost positive that Brady’s device is nowhere as ancient as mine.
Import database with phpMyAdmin or from command line as explained in Stephen’s 4-24-14 post from page 2 of this thread.
The backup utility basically copies the openemr directory, database and ACL; then wraps everything into a zipped file. Since the ACL is not likely to change a lot on a daily basis, having the first and second should be enough.
The restore script does all the work for the user, but can’t use the script without the emr_backup.tar.
Better to have an awkward workaround than to crash without a backup of any kind.
Thank you so much fsgl. Number 2 (sql dump) no problem. However, when I try to copy the openemr directory, I get: “The file operation was completed with errors” followed by a fairly long list of files with “Permission denied”. I had opened /var/www as root, so why should permission be denied?
BTW, what does ACL stand for (apart from Anterior Cruciate Ligament) and what does it do?
In addition to copying the web directory as root, pasting must also be done as root, (must get permission for everything, even sneezing), because that’s part of securing OpenEMR.
You must be an Orthopod. ACL in this context is Access Control List. PhpGACL is the module which deals with which group has permission to perform different tasks.
If you don’t have any difficulties with the browser freezing, then it probably has nothing to do with the backup problem.
Another thing to consider is a system image. It’s extra insurance or redundancy. Some suggestions. It’s faster to image than it’s to clone.
Found the apache error log in var/www/log/apache2. See attachment; of note, the fatal error. The least obtuse explanation of the “call to undefined function gzopen()” fatal error is found here. All this stuff is like reading Mayan glyphs.
Mysqli was part of the package, therefore it’s not the source of the problem. Hopefully the solution will involve just tacking 64 to gzopen.
Because the backup utility hangs with the mysql dump, I looked for the mysql error log as well. Mysql.err was empty. Perhaps I’m looking in the wrong place.
Went to line 550 in /var/www/openemr/interface/main/backup.php, just on a whim, add 64 after gzopen (this part of the script zips the file) and got the following while retrying the backup:
Dumping OpenEMR database… Dumping OpenEMR web directory tree… An error occurred while dumping OpenEMR web directory tree
Why would adding 64 allow the mysql dump to proceed? (I suppose this is why PhD.'s are awarded for Computer Science.) Found the mysql error log in var/log/mysql. It was empty.
Took another look at error log in apache2, no fatal error this time around.
Used the directions here, but no resulting php-scripts.log file. Removing the uncomment from /var/log/php5/apache2/php.ini line 585 did not create php_errors.log either. This leads me to think that the Apache and the PHP error logs both serve the same function.
Rather cold comfort. Without additional error info, it’s an impossible road to resolution. O.K., I’m really stumped. Will have to wait patiently for help.
“In addition to copying the web directory as root, pasting must also be done as root, (must get permission for everything, even sneezing), because that’s part of securing OpenEMR.”
Ah, yes, I should have realised. Now all is clear.
With regard to your other messages, I’m afraid most of it goes quite a way over my head. I do have several error logsin /var/log/mysql, but I don’t think any of them have anything to do with this issue. As evidence of this, I just tried to make another backup using the OpenEMR backup facility and it stalled as usual but no new error log has appeared.
Well, at least now I can manually back up my data and feel confident that it is safe if my computer dies. Many thanks for that.
[Wed Jul 09 09:33:03.902173 2014] [:error] [pid 1235] [client 127.0.0.1:47007] PHP Fatal error: Call to undefined function gzopen() in /var/www/openemr/interface/main/backup.php on line 550, referer: http://localhost/openemr/interface/main/backup.php
Been looking into this. For efficiency sake, I have bundled this issue together with 1)testing new development ubuntu package that works with zend 2)figuring out why Zend stuff does not work(note the zend breakage appears to be related to the very annoying change to /var/www/html…).
As of now, my testing with the development version in Mint 17 and ubuntu 14.04 have not duplicated the above database error (next step is to try the most recent 4.1.2 ubuntu package, but this should not be different). On your end recommend updating OS packages (‘sudo apt-get update’ then ‘sudo apt-get upgrade’ to see if that solves the issue).
For the Zend stuff, will create a thread when have more information.
I presume that you have LM 17 & the newest Ubuntu-Debian package (with patch 7) installed. If that is correct, try the backup utility & let us know what you get.
Brady went through a lot of hassle (“headaches”) to rework the package for Ubuntu 14.04 & LM 17. The pathogen was the relocation of the web directory from var/www to var/www/html, which occurred with all new Linux distributions. The cephalagia continues.
This was more like a question than an direct answer. I have the Demo version on Mint 17 but did not do a Backup[ restore exercise yet. Could try to find an answer in the weekend.
I wonder if openemr-4.1.2.tar.gz is unpacked and moved directly to /var/www/html and then unzip patch 7 in Ubuntu 14.04 or Linux Mint 17 before installing will take away all the headache and controveries. I use a very old machine with P4 intel with 775MB ram with LXDE desktop and I use this as a server with no problem so far! Backup using the built-in was also not a problem and restore was just paste and dumping back the backup sql!. I was even able tto port the backup to Fedora 20! With this confidence I am probably finally done with testing and on to production!