/var/log/apache2/error.log には、以下のように記録されていました。
[Thu Jul 21 05:00:35 2011] [notice] caught SIGTERM, shutting down
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php5/20090626/msql.so’ – /usr/lib/php5/20090626/msql.so: cannot open shared object file: No such file or directory in Unknown on line 0
[Thu Jul 21 05:00:36 2011] [notice] Apache/2.2.14 (Ubuntu) PHP/5.3.2-1ubuntu4.9 with Suhosin-Patch mod_perl/2.0.4 Perl/v5.10.1 configured — resuming normal operations

サーバーのプラグインディレクトリにアクセスして、アップデートしたプラグインを確認します。
日時から、以下の３つのプラグインをアップデートしたことがわかります。
auto-thickbox 2011-07-21 04:52
secure-wordpress 2011-07-21 04:52
google-sitemap-generator 2011-07-21 04:52

一番怪しそうな　secure-wordpress をディレクトリごと削除します。
$ sudo rm -rf secure-wordpress

そして、再度、サイトにアクセスしたら無事にアクセスできましたので、原因はSecure WordPress にあるようです。

後日、Wordpressのプラグインサイトから、最新版のSecure WordPressプラグインをインストールしてみたら、正常にインストールできました。アップデート時だけの問題なのか、たまたま発生した問題なのか分かりませんが、まあ良しとしましょう。

なぜか？
原因として思い当たるのはプラグインのコンフリクト？たぶん、違うでしょう。
可能性として一番高いのは、DMSguestbookの設定関係のデータベースが異常を起こしたことが原因ではないかと思われます。
設定関係のデータベースが読み込めないためにタグにすら現れないのではないか、だとすれば、設定関係のデータベースを削除してから新規インストールすればよいのではないかと考えました。
調べてみると各種プラグインの設定関係のデータはMySQLデータベースのwp_optionsというテーブル内に保存されており、そのなかのoption_nameというカラムを調べればどの行データがどのプラグインの設定データを保持しているのかわかるようです。
ちなみにDMSGuestbookの場合は、そのカラムがDMSGuestbook_optionsというデータになっている。
したがって、wp_options テーブル内のoption_nameカラムがDMSGuestbook_optionsとなっている行データを削除してしまえば修復できると思われます。

以下は異常を起こしているデータ(option_value)
確かに変・・です。

<supergb>0</supergb>\r\n<page_id>0</page_id>\r\n<width1>0</width1>\r\n<width2>0</width2>\r\n<step>0</step>\r\n<messagetext_length>0</messagetext_length>\r\n<position1>0</position1>\r\n<position2>0</position2>\r\n<separatorcolor>0</separatorcolor>\r\n<bordercolor1>0</bordercolor1>\r\n<bordercolor2>0</bordercolor2>\r\n<navigationcolor>0</navigationcolor>\r\n<fontcolor1>0</fontcolor1>\r\n<forwardchar>0</forwardchar>\r\n<backwardchar>0</backwardchar>\r\n<navigationsize>0</navigationsize>\r\n<require_email>0</require_email>\r\n<require_url>0</require_url>\r\n<require_antispam>0</require_antispam>\r\n<antispam_key>0</antispam_key>\r\n<recaptcha_publickey>0</recaptcha_publickey>\r\n<recaptcha_privatekey>0</recaptcha_privatekey>\r\n<akismet>0</akismet>\r\n<akismet_action>0</akismet_action>\r\n<show_url>0</show_url>\r\n<show_email>0</show_email>\r\n<show_ip>0</show_ip>\r\n<ip_mask>0</ip_mask>\r\n<captcha_color>0</captcha_color>\r\n<dateformat>0</dateformat>\r\n<setlocale>0</setlocale>\r\n<offset>0</offset>\r\n<formpos>0</formpos>\r\n<formposlink>0</formposlink>\r\n<send_mail>0</send_mail>\r\n<mail_adress>0</mail_adress>\r\n<mail_method>0</mail_method>\r\n<smtp_host>0</smtp_host>\r\n<smtp_port>0</smtp_port>\r\n<smtp_username>0</smtp_username>\r\n<smtp_password>0</smtp_password>\r\n<smtp_auth>0</smtp_auth>\r\n<smtp_ssl>0</smtp_ssl>\r\n<sortitem>0</sortitem>\r\n<dbid>0</dbid>\r\n<language>0</language>\r\n<email_image_path>0</email_image_path>\r\n<website_image_path>0</website_image_path>\r\n<admin_review>0</admin_review>\r\n<url_overruled>0</url_overruled>\r\n<gravatar>0</gravatar>\r\n<gravatar_rating>0</gravatar_rating>\r\n<gravatar_size>0</gravatar_size>\r\n<mandatory_char>0</mandatory_char>\r\n<form_template>0</form_template>\r\n<post_template>0</post_template>\r\n<nofollow>0</nofollow>\r\n<additional_option>0</additional_option>\r\n<additional_option_title>0</additional_option_title>\r\n<show_additional_option>0</show_additional_option>\r\n<role1>0</role1>\r\n<role2>0</role2>\r\n<role3>0</role3>\r\n<css>||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@||@</css>\r\n<css_customize>0</css_customize>\r\n

以下は対応策ですが、phpMyAdminを使って、データベースを直接編集します。
phpMyAdminを使って、wp_optionsテーブルから右のように検索すると対象のデータを抽出できます。

このoption_valueの内容が異常を起こしていると思われる。右の画面でこの行データにチェックを入れて、×ボタンをクリックして行データごと削除してしまえばよいはず。
その後に、プラグインをインストールすればプラグインの方で設定データベースを構築してくれると思います。
または、適正なデータをバックアップしていればoption_valueのデータを適切なものに入れ替えればよい。
自分の場合は、バックアップしてあったので入れ替えで、無事復活できました。

<?php st_related_posts(); ?>

プラグインが対応してくれたらまた復活します。