Atomicorp

Just did a Google search on this and this thread was #1 .. so yeah, it looks like it's gone. I'm in the midst of a 10.1.1 deployment, moving from 9.5. Long time no login .. took a bit of a break from IT, but I'm back. Bought EVERYTHING new for this rolllout - switches, servers, made the jump to iSCI...

I got around it by using yum install php-mcrypt.x86_64 Thanks for this. I just deployed three new VPS's this morning, of course they came stock with 5.1.6 which not even PMA likes, and ran into this problem right away. It can also be mitigated by installing php-mycrypt 5.1.6 before enabling the ato...

To get php-pear to install I had to disable my CentOS-Base.repo. Then it stopped complaining about php 4.3.9 and grabbed it from ART.

At least you get updates. I renewed my SUS and I can't download any products from the website.

I'm hoping based on my licence key that I can still run the command line based updater on Friday.

I have faith in Plesk releases. That's why on Friday, the 2nd, I'm going to upgrade from 8.4 to 8.6.



I've been upgrading this one install since 7.0.3 without failure, but I always stay behind the curve.

I'll look into that, thanks. I'm dropping a few clients for 2009, so it will be time to tweak again to the few larger ones that are left. As well, nothing in my log since the table upgrade, so it's a definite requirement from MySQL 4 to 5 ---- upgrade your tables! Running 28 days and 75M queries sin...

This MySQL server has been running for 7 days, 4 hours, 48 minutes and 8 seconds. It started up on Dec 02, 2008 at 05:00 AM. At this point it's a solid confirmation that the table upgrade was required and was the source of my crash issues. It should be added to any documentation regarding V4 to V5 ...

Alright, well here's the full background for my MySQL environment at the moment. I upgraded from 4 to 5 on June 13. On June 14 MySQL started crashing every night when my cron jobs ran. (see below) As a result, many of my tables needed repair, mostly ones with session information. One table was beyon...

I see that. I wonder if I was crashing for another reason. When I changed to MySQL 5, I didn't do a Repair on all the tables to upgrade them. I think when I was running my daily optimize table/backup DB script, that's what was actually crashing MySQL. After doing a mysqlcheck -A -e --auto-repair, a ...

Alright, but if I installed php originally from the RPM on the DVD, and then upgraded using ART.. would I even have a src file for it?

Unfortunately I never learned how to do that. If it's a quick command you can supply, I'd appreciate it, otherwise I'll have to do some research later.

Oddly enough it did not crash this morning. I caught it with it's pants down. Frustrating.

Looks like my hunch was correct. It is 100% to do with the mismatched library. I posted last on here on June 13 with the error of the mismatch, and June 14 was the first crash.

So I need to go back to figuring out how to rid myself of MySQL and PHP and installing them from scratch so they match.

Obviously there's a cron of some sort. I just found this today, and it's been happening since June 14. I'm thinking it coincides with the upgrade to PHP 5.2.6 that I did from here. I still get the good ol' "Your PHP MySQL library version 4.1.22 differs from your MySQL server version 5.0.62.&quo...

Nothing wrong with it being a Dell. I love it.

Naw, it's rare. I don't like to mess with the production box. As I mentioned before, it ran for almost 500 days without being messed with. Of course, I did yum updates and what not, but when it comes to changing major versions of MySQL and PHP.. tends to break sites and clients get all up in arms. O...