Ashoat

Okay, how about the ones from yesterday? Are they okay?

Open a support thread.

When you create them? Are you creating new ones, or using the ones from yesterday?

I don't think that's it. My understanding is that PECL extensions don't add php.ini directives, so the only thing they could be doing by separating their php.ini is running their extension= directives in a separate file. I thought the problem might be that I built ImageMagick without Perl, but after I fixed the issue preventing the installation with Perl and subsequently installed ImageMagick with Perl support, the issue remains. At this point I've tried the PECL-installed ImageMagick, the latest stable version, the latest beta version, and an old version. All versions are producing these coredumps. Any ideas as to what I should try?

Is there perhaps a .htaccess in the directory? Can you access the image from outside?

Sorry guys, still not up There was an issue in one of the transfer scripts. I'm working on it, and I'll give you an update ASAP.

I'd rather not debug the coredumps if it's avoidable. Can you reproduce the error? Does it occur without the jpeg being in the same directory?

Give the system a day to restart.

I'm not seeing any coredumps, but I am seeing an error_log. Is that what you meant?

Once again guys, I can't do that because it would overload our uplink and we'd end up being charged a lot (more than $1000) for the overrage. Read the thread please.

Got it! I had to manually compile from source, though. The PECL installer wasn't working.

Are you sure it shouldn't have a capital "I"? I'm getting a successful install message, and I don't think that PECL modules show up in phpinfo()... EDIT Changed the spelling, and it didn't help. Any ideas as to how else I can try installing it?

Okay, done.

Note to self, and other sysadmins: To get libgdiplus working, make sure glib-2.0 is installed, that it has a lib64 .pc in pkgconfig, and that there is a symlink from the .so to the real library in /lib64. <add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient" description=".Net Framework Data Provider for MySQL" type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.2.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d"/> <add name="PostgreSQL Data Provider" invariant="Npgsql" support="FF" description=".Net Framework Data Provider for PostgreSQL" type="Npgsql.NpgsqlFactory, Npgsql, Version=2.0.9.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7"/>

Is it working now?

Looks like Apache didn't restart overnight. I restarted it and your site is fine now.

Subdomains direct to a separate directory than public_html. Where are you directing your subdomain?

Sorry, we still have a serious backlog of accounts to create. You're on the queue, and we'll get to you ASAP.

Is Imagick working now?

Okay, are they working now?

Yeah, those platforms will be fine.

I'm having trouble getting these to work, so I'm recompiling Apache/PHP. I'll let you know once it's done.

I want to make sure all the libraries are in place before I go ahead and start working on the DDoS problem again, but my guess is around Monday. I've fixed the problem with the login updater script. Everyone - login to update your last login date.

cPanel should be up again, but the login updater script is down. I have a ticket open with cPanel for this - as soon as I get the issue resolved, you all should make sure to login to cPanel to update your activity in the database.