Movable Type Community Forum > Mt Crashed Server

deeleea

Sep 19 2008, 07:15 PM

Below is a transcript of feedback I got from my host this morning when I inquired as to why I no longer had access to my server. Blogs were down - ftp - timing out. etc.

Thank you for your message.

We have indeed had a problem with the server housing your site. The
problem was actually caused by your mt.cgi script. It seems to either
be extremely memory-intensive, or possibly has a memory leak in the
script (such as an infinite loop). The end result was that many
instances of the script were running concurrently and consuming an
increasing amount of system memory, which caused the server to fail.

Since the problem affected other clients as well, we have had no
choice but to deactivate your mt.cgi script.

Please check with the script vendor to see if there are any updates
available which correct the problem. Since the script caused such a
serious problem, regretfully we need to insist that the script is not
reactivated until the problem is fully resolved. When you have
addressed the issue with the script, please let us know what changes
have been made and we will then be able to review whether the script
can be reactivated.

I have done nothing to my Mt installation, posted my last entry on Friday, have been replying to comments as usual. I usually use the plugin notifyreplyee so I can send email back to my commenter so they get my reply to their comment, and I may have tried to use that this morning, I'm a bit hazy on the last thing I did... isn't it typical? You always get asked what the last thing you did was... and you never knew it was going to be the last thing...

Anyway, as I'm generally in the habit of just uploading the scripts and not tweaking them I'm at a loss as to what I can do... any ideas???

Thanks

Dee

OtherNiceMan

Sep 19 2008, 11:46 PM

Do you have access to any web server logs?

Has your host performed any upgrades recently?

does mt-check.cgi still work? If so can you post the output.

deeleea

Sep 20 2008, 03:15 AM

QUOTE (OtherNiceMan @ Sep 20 2008, 07:46 AM)

Do you have access to any web server logs?

Has your host performed any upgrades recently?

does mt-check.cgi still work? If so can you post the output.

The host won't allow me to run any of the cgi scripts in the live environment and so I can't check mt-cgi or anything. I'm using MT4.21, for what it's worth and the host is suggesting the problem was introduced on Sept2 when I uploaded it...

In terms of sever maintenance - this is what they had to say.

Regarding your question about whether any server changes have
occurred during the last week, there have been patches to SSH and
libfreetype6. The SSH change would definitely not have an impact on
this issue, and it is very unlikely that a patch to libfreetype6
would cause such an issue but the vendor of your script may be able
to advise you further on whether their script is having trouble with
the latest version of libfreetype6.

In terms of logs - this is what they had to say

Your log files are available in /home/asscene/logs. Please note that
the log files show traffic to your site but do not provide debugging
information. Debugging information is normally something that would
need to be built into the script itself. For example, some scripts
have a debug mode which produces more detailed information which can
assist with troubleshooting. A problem though is that, in this case,
it would not be appropriate to use the debug mode since running this
script in our live environment is not possible.

deeleea

Sep 20 2008, 03:16 AM

QUOTE (deeleea @ Sep 20 2008, 11:15 AM)

QUOTE (OtherNiceMan @ Sep 20 2008, 07:46 AM)

Do you have access to any web server logs?

Has your host performed any upgrades recently?

does mt-check.cgi still work? If so can you post the output.

The host won't allow me to run any of the cgi scripts in the live environment and so I can't check mt-cgi or anything. I'm using MT4.21, for what it's worth and the host is suggesting the problem was introduced on Sept2 when I uploaded it...

In terms of sever maintenance - this is what they had to say.

Regarding your question about whether any server changes have
occurred during the last week, there have been patches to SSH and
libfreetype6. The SSH change would definitely not have an impact on
this issue, and it is very unlikely that a patch to libfreetype6
would cause such an issue but the vendor of your script may be able
to advise you further on whether their script is having trouble with
the latest version of libfreetype6.

In terms of logs - this is what they had to say

Your log files are available in /home/asscene/logs. Please note that
the log files show traffic to your site but do not provide debugging
information. Debugging information is normally something that would
need to be built into the script itself. For example, some scripts
have a debug mode which produces more detailed information which can
assist with troubleshooting. A problem though is that, in this case,
it would not be appropriate to use the debug mode since running this
script in our live environment is not possible.

Oh and Other Nice Man, sorry, thanks for taking the time to check it out... am well stressed at this point... all polite niceties appear to have been lost in the mists of aggravation.

XXP

Sep 20 2008, 05:53 AM

QUOTE (deeleea @ Sep 19 2008, 11:15 PM)

Below is a transcript of feedback I got from my host this morning when I inquired as to why I no longer had access to my server. Blogs were down - ftp - timing out. etc.
...
I have done nothing to my Mt installation, ... as I'm generally in the habit of just uploading the scripts and not tweaking them I'm at a loss as to what I can do.

Hi Dee,

Good news, I hope.

We've been through this exact same frustrating thing and found it to be that mt.cgi requires (emphasize; requires) that the Perl modules for ImageMagick be installed. This is not a documented requirement -- in fact the setup for MT pretty clearly implies that ImageMagick is not required -- but this is where the problem was coming from.

Ask your host to check to make sure that an up-to-date "ImageMagick.pm" is installed for your server. Once that is done, I'll bet a virtual cup of coffee that the problem goes away.

FYI for reference see this post (and others) and/or my blog entry about it. You can direct your hosting ISP guys to those if they want some detail.

Good Luck! It's quick to check and quick to fix; definitely worth checking off. I think this will do it for you.

.

OtherNiceMan

Sep 20 2008, 11:53 AM

MT doesn't require IM or the modules. I have an instance running on 1&1 with IM. IM is needed for CAPTACHA generation and producing thumbnails for uploaded images.

There can be problems if IM is misconfigured (deep recursion type problems)

Intrestingingly libfreetype is required by IM (http://216.239.59.104/search?q=cache:_C5VGDPI-kMJ:download.lassosoft.com/pub/Lasso85/Documentation/Building%2520ImageMagick.pdf+libfreetype+imagemagick&hl=en&ct=clnk&cd=10&gl=uk&client=firefox-a)

XXP

Sep 20 2008, 07:53 PM

QUOTE (OtherNiceMan @ Sep 20 2008, 03:53 PM)

MT doesn't require IM or the modules. I have an instance running on 1&1 with IM. IM is needed for CAPTACHA generation and producing thumbnails for uploaded images.

There can be problems if IM is misconfigured (deep recursion type problems)

Hi ONM,

Your help in this forum and elsewhere is deeply appreciated and respected. Thanks for all you do.

On this matter though, the point above is slightly off the mark. ImageMagick is required, though this fact is not documented. This requirement may be unintended by the SixApart crew, but because of the thumbnail processing the deep recursion errors will be thrown during certain processes within "mt.cgi". Not all processes, but some. "Publish All" is one of those, for example. The "System Info" report is another.

N.B.: The deep-recursion errors are thrown by the DBI.pm Perl module and not by the ImageMagick.pm module, but they are only thrown when ImageMagick.pm is either not present or, as you note, if the "mt.cgi" instance of Perl is not configured to find it.

If mt.cgi is calling a Perl that has access to a copy of ImageMagick.pm then the errors don't happen. If it does not have access then the jam-up and errors will occur.

N.B.:It does not matter if Captcha is turned on or not. Apparently has to do with [preparing to?] process images that would be stored in the database if they existed. The jam-up seems to occur, however, whether there are images in the database or not.

Bottom line: the problem occurs if ImageMagick is not present but goes away when ImageMagick.pm is installed.

Thanks again for all. This board would be lost without your kind and consistent help.

.

deeleea

Oct 10 2008, 06:39 PM

QUOTE (XXP @ Sep 21 2008, 03:53 AM)

QUOTE (OtherNiceMan @ Sep 20 2008, 03:53 PM)

MT doesn't require IM or the modules. I have an instance running on 1&1 with IM. IM is needed for CAPTACHA generation and producing thumbnails for uploaded images.

There can be problems if IM is misconfigured (deep recursion type problems)

Hi ONM,

Your help in this forum and elsewhere is deeply appreciated and respected. Thanks for all you do.

On this matter though, the point above is slightly off the mark. ImageMagick is required, though this fact is not documented. This requirement may be unintended by the SixApart crew, but because of the thumbnail processing the deep recursion errors will be thrown during certain processes within "mt.cgi". Not all processes, but some. "Publish All" is one of those, for example. The "System Info" report is another.

N.B.: The deep-recursion errors are thrown by the DBI.pm Perl module and not by the ImageMagick.pm module, but they are only thrown when ImageMagick.pm is either not present or, as you note, if the "mt.cgi" instance of Perl is not configured to find it.

If mt.cgi is calling a Perl that has access to a copy of ImageMagick.pm then the errors don't happen. If it does not have access then the jam-up and errors will occur.

N.B.:It does not matter if Captcha is turned on or not. Apparently has to do with [preparing to?] process images that would be stored in the database if they existed. The jam-up seems to occur, however, whether there are images in the database or not.

Bottom line: the problem occurs if ImageMagick is not present but goes away when ImageMagick.pm is installed.

Thanks again for all. This board would be lost without your kind and consistent help.

.

Thanks for the input, team. Unfortunately, due to the rather unhelpful nature of my host, the problem is not deemed to be Image:Magick or any such issue, they're fairly entrenched... and after a bit of testing all appeared to be ok.

Then it wasn't again.

Basically I'm switching hosts to one that's a bit bigger and a bit more MT friendly. Totally painful but worth it in the long run, I believe.

Again, thanks for your help, all the same.

Deeleea