I performed the module updates and my php ZipArchive just stopped working !

20 posts / 0 new
Last post
#1 Sun, 02/28/2010 - 23:03
Anonymous

I performed the module updates and my php ZipArchive just stopped working !

Hi,

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

Any ideas what may have triggered this ?

Thanks

Sun, 02/28/2010 - 23:14
andreychek

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?

-Eric

Mon, 03/01/2010 - 10:07
Davvit

Well, there was a load of recommended update on my System Information page and I don't really know what they were !

I have not updated my php, I am running 5.2.9 .

My script was running fine until Friday maybe I made a change to the code without realizing.

The script is pretty simple, it uses cUrl to download a zipped xml file and then uses ZipAchive to unzip it.

I can not see any reason for it not to work. :(

Mon, 03/01/2010 - 10:33
Davvit

I have re-checked the code, and can see no errors.

How would I go about re-installing the ZipArchive class ?

I seem to remember that it wsn't part of my php set up and I installed it with your help about two months ago.

Mon, 03/01/2010 - 10:42
andreychek

Howdy,

You verified that the file you're downloading is correct, right? :-)

Can you download and unzip it manually without any problems?

As far as reinstalling ZipArchive -- that all depends on how you installed it in the first place :-)

I don't really have any experience with it, though at a glance looks like it may be included with current PHP versions.

However, it also appears to be available in the PECL repository, meaning you could install it with "pecl install zip". There's more info here:

http://pecl.php.net/package/zip

Mon, 03/01/2010 - 12:25
Davvit

I am quite happy for you to look at the code -

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 ?

Mon, 03/01/2010 - 12:59
andreychek

Well, I suspect the issue may be in the downloading or storing of the file, rather than in unzipping it.

If the code thinks there's a problem with the archive, there really may be.

For example, are you sure this particular Virtual Server isn't low on their quota?

Also, what do you see if you type this on the command line after the file is downloaded:

file /home/guru54gt5/public_html/sys/a_zip_clickbank.zip

Tue, 03/02/2010 - 01:29
Davvit

Well one thing I just noticed...

My PHP version is 5.2.10

As far as I knew it was 5.2.9 and I checked it about 4 weeks ago when I was thinking to upgrade to 5.3.0. ( I wrote a question about it in this forum)

I am still running tests with my scripts.

Would any of your upgrade packages/ bundles upgraded my php version ?

Thanks for helping.

Tue, 03/02/2010 - 08:56
andreychek

Hrm, what distro / version are you using?

The only case where Virtualmin provides PHP is in the bleeding edge repo for CentOS/RHEL:

http://www.virtualmin.com/documentation/id,virtualmin_bleeding_edge_pack...

Wed, 03/03/2010 - 10:59
Davvit

According to the System Information page, I am running on CentOS Linux 5.4 with Linux 2.6.18-164.2.1.el5 on i686

Is there a way to check in my logs to see exactly when the update to 5.2.10 was made ?

I have downloaded a backackup from last week and The log for running that day was fine. When ı run the script from that downloade folder, it fails.

So the script that ran fine a week ago, now doesn't run.

I am just going to do that manual file check from the command line that you suggested.

OK - just did that - here are results:

file /home/guru54gt5/public_html/sys/clickbank.zip /home/guru54gt5/public_html/sys/clickbank.zip: Zip archive data, at least v2.0 to extract

Looks like a normal zip file to me.

How can I check in my logs to see exactly when the update to 5.2.10 was made ?

Thanks.

Wed, 03/03/2010 - 11:16
Davvit

Hello again

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?

Thanks.

Wed, 03/03/2010 - 11:20
andreychek

Howdy,

What do you see if you type:

rpm -qa | grep php

To determine when a package was updated, you can look in the yum log located in /var/log/.

-Eric

Wed, 03/03/2010 - 12:13
Davvit

This is what I get:

rpm -qa | grep php
wbm-php-pear-1.5-1
php-pear-1.5.1-2.el5s2
php-imap-5.2.10-1.el5.centos
php-ldap-5.2.10-1.el5.centos
php-common-5.2.10-1.el5.centos
php-gd-5.2.10-1.el5.centos
php-5.2.10-1.el5.centos
php-mbstring-5.2.10-1.el5.centos
php-devel-5.2.10-1.el5.centos
php-cli-5.2.10-1.el5.centos
php-mysql-5.2.10-1.el5.centos
php-xmlrpc-5.2.10-1.el5.centos
php-snmp-5.2.10-1.el5.centos
php-mcrypt-5.2.9-2.el5.centos.3
php-pdo-5.2.10-1.el5.centos
php-xml-5.2.10-1.el5.centos
php-pgsql-5.2.10-1.el5.centos
php-odbc-5.2.10-1.el5.centos

I will have a look at var/log

OK - done that and I have found the update:

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
Wed, 03/03/2010 - 13:11
andreychek

Well, it looks like the issue there twofold --

  1. 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.

  2. 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.

    -Eric

Wed, 03/03/2010 - 13:40
Davvit

Thanks I will make those changes immediately !

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.

Thanks

Wed, 03/03/2010 - 13:54
andreychek

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.

-Eric

Wed, 03/03/2010 - 14:14
Davvit

Thanks, a couple of questions ...

Will those changed php packages be the ones listed as "updated" in that list I got from yum log ?

Where is this yum man page ? is that part of VirtualMin ? or a website ?

Oh and I just looked at my packages that should be upgarded in the System Information page and there are 64 of them !!!

I don't know which ones I should upgrade.

Some like fortran I doubt if I need but then there is:

KERNEL, The Linux kernel (the core of the Linux operating system) That sounds pretty important, but should it be upgraded ?

GD, A graphics library for quick creation of PNG or JPEG images. New Version

MYSQL, MySQL client programs and shared libraries. New Version

MySQL server, The MySQL server and related files . New Version

PEAR, PHP Extension and Application Repository framework

Yum plugin which chooses fastest repository from a mirrorlist

Wed, 03/03/2010 - 15:48
Davvit

OK _ I found the Yum Man page

using pUtty as my command line

and found the downgrade keyword.

I just listed the recent updates:

yum list recent
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: mirror.raystedman.net
* base: centos-distro.cavecreek.net
* extras: mirror.stanford.edu
* updates: linux.mirrors.es.net
Reducing CentOS-5 Testing to included packages only
Finished
Recently Added Packages
coreutils.i386                                 5.97-23.el5_4.2                      updates
freenx.i386                                    0.7.3-3.el5.centos                   extras
libXi.i386                                     1.0.1-4.el5_4                        updates
libXi-devel.i386                               1.0.1-4.el5_4                        updates
luci.i386                                      0.12.2-6.el5.centos.1                updates
mysql.i386                                     5.0.77-4.el5_4.2                     updates
mysql-bench.i386                               5.0.77-4.el5_4.2                     updates
mysql-devel.i386                               5.0.77-4.el5_4.2                     updates
mysql-server.i386                              5.0.77-4.el5_4.2                     updates
mysql-test.i386                                5.0.77-4.el5_4.2                     updates
nx.i386                                        3.4.0-3.el5.centos                   extras
openssh.i386                                   4.3p2-36.el5_4.4                     updates
openssh-askpass.i386                           4.3p2-36.el5_4.4                     updates
openssh-clients.i386                           4.3p2-36.el5_4.4                     updates
openssh-server.i386                            4.3p2-36.el5_4.4                     updates
ricci.i386                                     0.12.2-6.el5.centos.1                updates
sudo.i386                                      1.6.9p17-6.el5_4                     updates
systemtap.i386                                 0.9.7-5.el5_4.3                      updates
systemtap-client.i386                          0.9.7-5.el5_4.3                      updates
systemtap-initscript.i386                      0.9.7-5.el5_4.3                      updates
systemtap-runtime.i386                         0.9.7-5.el5_4.3                      updates
systemtap-sdt-devel.i386                       0.9.7-5.el5_4.3                      updates
systemtap-server.i386                          0.9.7-5.el5_4.3                      updates
systemtap-testsuite.i386                       0.9.7-5.el5_4.3                      updates
wbm-virtual-server.noarch                      2:3.77-1                             virtualmin-universal
wbm-virtualmin-awstats.noarch                  2:4.3-1                              virtualmin-universal
wbm-virtualmin-mailman.noarch                  2:5.9-1                              virtualmin-universal
wbt-virtual-server-theme.noarch                2:7.7-1                              virtualmin-universal
[root@heavyhoster ~]#

It doesn't seem to mention php 5.2.10.

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 ?

Thu, 03/04/2010 - 05:08
Davvit

I have managed to find a work-around to make 5.2.10 work.

I don't want to unnecessarily risk doing the down-grade.

Thanks for all your help :)

Thu, 03/04/2010 - 10:35
andreychek

I'm glad you got it working!

Just remember to be careful with non-standard repositories... weird things can sometimes happen unexpectedly :-)

-Eric