I ran the updates to modules that were on my System Information page
and today I see that the three cron jobs that download and unzip some
xml files failed with an Error 19.
Can one of the updates have changed the way ZipArchive library works ?
This is the line in the script that erros:
if (!$file_zip) {
write_log("Could not find $file_zip\r\n Error # $err\r\n");
exit;
}
else {
write_log("Found: $file_zip\r\n");
}
if (($err = $zip->open($file_zip)) !== true) { // THIS LINE ERRORS
write_log(“Could not open $file_zip\r\n Error # $err\r\n”);
exit;
}
else {
write_log(“File opened: $file_zip\r\n”);
}
As you can see I check that the file exists first then I try and unzip it.
The Output in my log is:
-Saved as file: /home/guru54gt5/public_html/sys/a_xml_file.zip
-File size: 278528 bytes
Found: /home/guru54gt5/public_html/sys/a_xml_file.zip
Could not open /home/guru54gt5/public_html/sys/a_xml_file.zip
Error # 19
Was PHP one of the updates that were done? If so, what PHP version had you been using, and what version are you using now?
There are changes to the way PHP works between some versions, sure, though the difference here is typically minimal when using your distro’s standard PHP version.
However, one of the things I’d suggest doing is making double, maybe triple sure that there’s nothing wrong with the file being downloaded
The error you’re getting above suggests it may not be a valid zip archive – is it at all possible that the file is simply corrupted?
I do not particularly want to re-install the class
buıt I can not see any problem.
I am downloading the clickbank zipped xml file with cUrl and trying to unzip it.
The file downloads, but doesn’t unzip.
If I FTP the zip file to my desktop I can unzip it without problem.
This is my code:
if (!class_exists('ZipArchive')) {
write_log("Class ZipArchive not found\r\n");
exit;
}
else {
write_log("Class ZipArchive OK\r\n");
$zip = new ZipArchive;
}
$res = $zip->open($file_zip);
if ($res === TRUE) {
write_log(“File $file_zip OPENED\r\n”);
}
else {
write_log(“Could not open $file_zip\r\n Error # $res\r\n”);
exit;
}
And this is my log output:
CURL completed successfully.
Downloaded file: http://www.clickbank.com/feeds/marketplace_feed_v1.xml.zip
-Saved as file: /home/guru54gt5/public_html/sys/a_zip_clickbank.zip
-File size: 2764800 bytes
Found: /home/guru54gt5/public_html/sys/a_zip_clickbank.zip
Class ZipArchive OK
Could not open /home/guru54gt5/public_html/sys/a_zip_clickbank.zip
Error # 19
Can you see any problem with it ?
Thanks.
BTW - on this forum, is there any way to see my previously posted
threads ?
Today I downloaded a backup of the script from a week ago
and ran that … it failed with the same error ( and yet the log for that day
showed that it succeeded at that time).
Now I have noticed something interesting.
If I break the script into two parts and do the download first. then exit.
Then afterwards, if I run the ZipArchive part of the script on the downloaded file, then it will work.
I still suspect that it maybe something php 5.2.10 is doing a little different.
How can I check in my logs to see exactly when the update to 5.2.10 was made on my server?
This is the log on Feb 27 - the last day that the
scripts ran properly !!!
What has activated that php update ?
Feb 27 02:17:51 Updated: mysql-5.0.77-4.el5_4.1.i386
Feb 27 02:17:53 Updated: mysql-devel-5.0.77-4.el5_4.1.i386
Feb 27 02:17:55 Updated: mysql-server-5.0.77-4.el5_4.1.i386
Feb 27 02:18:23 Updated: ruby-libs-1.8.5-5.el5_4.8.i386
Feb 27 02:18:24 Updated: ruby-devel-1.8.5-5.el5_4.8.i386
Feb 27 02:18:25 Updated: ruby-1.8.5-5.el5_4.8.i386
Feb 27 02:18:26 Updated: ruby-irb-1.8.5-5.el5_4.8.i386
Feb 27 02:18:26 Updated: ruby-rdoc-1.8.5-5.el5_4.8.i386
Feb 27 02:18:43 Updated: 2:wbm-security-updates-4.0-1.noarch
Feb 27 02:20:41 Updated: 2:wbm-virtual-server-3.77-1.noarch
Feb 27 02:20:57 Updated: 2:wbm-virtualmin-mailman-5.9-1.noarch
Feb 27 02:21:10 Updated: 2:wbm-virtualmin-svn-4.7-1.noarch
Feb 27 02:21:30 Updated: 2:wbt-virtual-server-theme-7.7-1.noarch
Feb 27 04:17:55 Updated: 30:bind-libs-9.3.6-4.P1.el5_4.2.i386
Feb 27 04:18:04 Updated: 30:bind-9.3.6-4.P1.el5_4.2.i386
Feb 27 04:18:19 Updated: 30:caching-nameserver-9.3.6-4.P1.el5_4.2.i386
Feb 27 04:18:21 Updated: 30:bind-chroot-9.3.6-4.P1.el5_4.2.i386
Feb 27 04:18:21 Updated: 30:bind-utils-9.3.6-4.P1.el5_4.2.i386
Feb 27 04:18:28 Updated: 30:bind-chroot-9.3.6-4.P1.el5_4.2.i386
Feb 27 04:19:24 Updated: openssl-0.9.8e-12.el5_4.1.i686
Feb 27 04:19:32 Updated: openssl-devel-0.9.8e-12.el5_4.1.i386
Feb 27 04:21:11 Updated: php-common-5.2.10-1.el5.centos.i386
Feb 27 04:21:12 Updated: php-pdo-5.2.10-1.el5.centos.i386
Feb 27 04:21:13 Updated: php-cli-5.2.10-1.el5.centos.i386
Feb 27 04:21:14 Updated: php-5.2.10-1.el5.centos.i386
Feb 27 04:21:15 Updated: php-pgsql-5.2.10-1.el5.centos.i386
Feb 27 04:21:16 Updated: php-imap-5.2.10-1.el5.centos.i386
Feb 27 04:21:16 Updated: php-mysql-5.2.10-1.el5.centos.i386
Feb 27 04:21:17 Updated: php-mbstring-5.2.10-1.el5.centos.i386
Feb 27 04:21:18 Updated: php-gd-5.2.10-1.el5.centos.i386
Feb 27 04:21:18 Updated: php-xml-5.2.10-1.el5.centos.i386
Feb 27 04:21:19 Updated: php-xmlrpc-5.2.10-1.el5.centos.i386
Feb 27 04:21:28 Updated: php-devel-5.2.10-1.el5.centos.i386
Feb 27 04:21:29 Updated: php-odbc-5.2.10-1.el5.centos.i386
Feb 27 04:21:29 Updated: php-ldap-5.2.10-1.el5.centos.i386
Feb 27 04:21:30 Updated: php-snmp-5.2.10-1.el5.centos.i386
Feb 27 04:22:54 Updated: 2:wbm-virtualmin-awstats-4.3-1.noarch
You’re setup to use CentOS’s “Testing” repository (which isn’t a default). It’s possible that you’re running into some sort of compatabilty or related problem with the PHP version they have in there.
You appear to be using automated updates (also not a default That is, it looks like your server is configured to perform updates as soon as it sees they’re available. You can tweak those settings by going into Virtualmin -> System Information, click the “Virtualmin packages” link in the “System” section near the top. Then, if you scroll all the way to the bottom, you’ll see “Action when update needed”. If you don’t want it to automatically update, you may want to change it to just notify you when updates are available.
I have been doing a bit of digging and found this comment:
Quote:
I updated recently to php-5.2.10 and some scripts are not working anymore. The scripts added some elements to the include_path. While including some files from the include_path php echos the error that it cannot resolve the host name. I think that this error is caused by the change, that stream wrappers could be used in the include path and the PATH_SEPERATOR and the stream wrappers collidate.
Downgrading to php-5.2.9-r2 solves the problem again.
Now - can you please tell me how do I can “downgrade” to 5.2.9 ?
I have a feeling that it will cure these problems.
Well, I haven’t tried this before… but it looks like it may be what you’re after
Take a peek in the manpage for yum (man yum) – and search for the keyword “downgrade”. You can apparently use that to go to the previous package version.
What you’ll likely need to do is determine which PHP related packages were changed recently, and list them all in a command to downgrade to the previous version… something like:
yum downgrade php-common php-pdo php-cli php … and so on
You have to pass in each PHP package you want downgrade in order for it to work properly.
As far as I can see, the idea of YUM is to check for dependancies when things are upgraded ( or in this case down-graded). I found a forum post that seems to confirm this:
When i try to run yum downgrade php,
This is what it did:
Setting up Downgrade Process
Resolving Dependencies
–> Running transaction check
—> Package php.i586 0:5.2.9-2.fc11 set to be updated
–> Processing Dependency: php-common = 5.2.9-2.fc11 for package: php-5.2.9-2.fc11.i586
–> Processing Dependency: php-cli = 5.2.9-2.fc11 for package: php-5.2.9-2.fc11.i586
—> Package php.i586 0:5.2.11-2.fc11 set to be erased
–> Finished Dependency Resolution
php-5.2.9-2.fc11.i586 from fedora has depsolving problems
–> Missing Dependency: php-cli = 5.2.9-2.fc11 is needed by package php-5.2.9-2.fc11.i586 (fedora)
php-5.2.9-2.fc11.i586 from fedora has depsolving problems
–> Missing Dependency: php-common = 5.2.9-2.fc11 is needed by package php-5.2.9-2.fc11.i586 (fedora)
Error: Missing Dependency: php-common = 5.2.9-2.fc11 is needed by package php-5.2.9-2.fc11.i586 (fedora)
Error: Missing Dependency: php-cli = 5.2.9-2.fc11 is needed by package php-5.2.9-2.fc11.i586 (fedora)
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
That looks like what I want to do.
I am a bit concerned that I might completely mess up the server though !
The backups I have are probably of data only, not the operating system.
I suppose if it does mess up, I can remove php altogether and then reinstall php 5.2.9 ?
That is, it looks like your server is configured to perform updates as soon as it sees they’re available. You can tweak those settings by going into Virtualmin -> System Information, click the “Virtualmin packages” link in the “System” section near the top. Then, if you scroll all the way to the bottom, you’ll see “Action when update needed”. If you don’t want it to automatically update, you may want to change it to just notify you when updates are available.