この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
確認してみると、Apacheが起動すらしていない。前日の夜に行ったのはyum updateだけ。「まさかアップデートが原因か？」と気づくまでに、かなりの時間を無駄にしました。
この記事では、yum（dnf）でパッケージを更新した後にApacheが起動しなくなるという、Linux管理者にとって意外と身近な落とし穴について解説します。
20年以上Linuxサーバーを運用してきた経験から言うと、この失敗は「パッケージ更新の影響範囲を意識する習慣」を身につける上で、重要なターニングポイントになりました。
この記事のポイント
・yum updateはApache関連モジュールや依存ライブラリを予告なく更新することがある
・更新後にApacheが起動しない場合は、まずエラーログ（/var/log/httpd/error_log）を確認する
・本番環境でのパッケージ更新前には「何が変わるか」の事前確認が必須
・テスト環境での検証なしに本番へ適用する習慣を今日から見直すべき
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
yum update後にApacheが動かない場合によくある原因と落とし穴
Linuxのパッケージ管理システム（yumやdnf）は便利な反面、複数のパッケージが依存関係で結びついているため、一つを更新すると別のパッケージの動作に影響することがある。特にApacheとその関連モジュールの関係は要注意だ。yum updateでよくある「Apacheが起動しなくなる」パターンには、主に以下のようなケースがある。
PHPモジュールのバージョン不一致
mod_phpはApacheのモジュールとしてPHPのライブラリと密接に結びついている。PHPのバージョンが変わると、Apacheがモジュールを正しくロードできなくなることがある。これが最も多いパターンだ。
mod_ssl / OpenSSLライブラリのバージョン不一致
OpenSSLがアップデートされると、mod_sslがリンクしているライブラリのバージョンと合わなくなり、Apacheの起動時にSSLモジュールのロードに失敗するケースがある。特にHTTPS対応のサーバーで頻発する。
httpd.conf の設定構文の変更
Apacheのメジャーバージョンアップ（例: 2.2系から2.4系）が含まれる場合、設定ファイルのディレクティブ書式が変わり、既存の設定が構文エラーになることがある。
セミナーで3,100名以上を指導してきた中で、「yum updateの後からWebサーバーが動かなくなった」という質問は繰り返し受けてきた。
単純に見えるこの問題が、現場では原因の特定に時間がかかるケースが多い。エラーログを最初に確認しないまま設定ファイルを何度も見直してしまうのが、時間を無駄にする最大の原因だ。
SE時代の失敗——パッケージ更新の翌朝に電話が来た
私がこの失敗を経験したのは、SE時代（2001年～2006年）のちょうど中頃、CentOS 4系を使っていた頃のことだ。1. 「安全のためにアップデートする」という判断が裏目に出た
その日、定期的なセキュリティパッチ適用のためにサーバーにログインした。セキュリティパッチを個別に選んで適用するより楽だと思い、こんなコマンドを実行した。
# パッケージを全て更新した（当時） yum update -y
ところが翌朝、「Webサイトにアクセスできない」という電話が来た。
2. Apacheのエラーログに答えがあった
PCからSSH接続でサーバーに入り、最初にApacheのステータスを確認した。# サービスの状態確認（当時はserviceコマンドを使用） service httpd status httpd is stopped # 手動起動を試みる service httpd start Starting httpd: [FAILED]
次にやったのは、エラーログの確認だ。ここを最初に見ていれば、迷走せずに済んだ。
# Apacheのエラーログを確認 tail -50 /var/log/httpd/error_log
[error] Cannot load /etc/httpd/modules/libphp4.so into server: libphp4.so: cannot open shared object file: No such file or directory [error] Syntax error on line 183 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libphp4.so into server
yum updateによってPHPのバージョンが上がり（libphp4.so → libphp5.so へ更新）、Apacheの設定ファイルに記述されているモジュールパスと一致しなくなっていた。
エラーログを最初から見ていれば、数分で原因にたどり着けた。しかし当時の私は、まず設定ファイルやApacheのプロセスを確認するという遠回りをしてしまった。「サーバーが何を言っているか」を読む前に「自分が知っている確認項目」から当たりに行く——この順序の間違いが、診断を長引かせた。
3. 原因が分かってから解決よりも「なぜ確認しなかったか」が反省点だった
モジュールのパスを修正してApacheを再起動すれば、問題自体は解決できた。しかし、それより深刻だったのは「自分がどんな変更をサーバーに加えたか把握していなかった」という事実だ。
「yum update -y」は何を更新したのか。どのパッケージのバージョンが何から何に変わったのか。
作業前に確認していれば、PHPのメジャーアップデートが含まれていることに気づけたはずだった。
現在のyumやdnfには、更新履歴を確認する
yum historyコマンドがある。当時はこうした機能がなかったが、今なら事後でも「何が変わったか」を追跡できる。# 更新履歴の一覧を表示する（番号は各トランザクションのID） yum history list # または dnf history list # 直近のトランザクション詳細（Nはトランザクションの番号） yum history info N # または dnf history info N
yum history info Nを使えば、「どのパッケージがどのバージョンからどのバージョンに変わったか」を後から確認できる。障害発生後の原因特定にも役立つ。20年以上サーバーを運用してきた経験から言うと、「コマンドを実行する前に何が変わるかを確認する」という習慣を持っているかどうかが、ベテランと駆け出しのエンジニアの最大の違いのひとつだ。
本番環境でのパッケージ更新に必要な3つの確認
この失敗以来、私はパッケージ更新の前後に以下の3つを必ず確認するようにしている。確認1：更新前に「何が変わるか」を把握する
yumまたはdnfには、実際には更新せずに変更内容だけを確認するオプションがある。# 更新対象のパッケージ一覧だけを表示する（実際には更新しない） yum check-update # または dnf check-update # Apache・PHP・SSL関連だけを絞り込む場合 yum check-update httpd php* mod_ssl* openssl*
メジャーバージョンの更新が含まれている場合（例: php-7.x から php-8.x）は特に注意が必要だ。マイナーバージョンのアップデートは通常は安全だが、メジャーバージョンアップはモジュールの互換性が壊れるリスクが高い。
確認2：本番適用前にテスト環境で検証する
Apacheが動作するテスト環境（VMでも可）を持ち、本番と同じパッケージ更新を先に適用して動作確認を行う。これを「面倒」と感じる人も多いが、私が担当していたサーバーはECサイト向けのWebサーバーだった。
1時間のダウンタイムが数十万円の機会損失につながる環境では、テスト環境の用意は「贅沢」ではなく「必須」だ。
クラウド環境（AWS、Azure、GCPなど）を使っている場合は、本番インスタンスのスナップショット（AMIやディスクイメージ）を取ってから更新する方法も有効だ。問題が起きたときにすぐ元の状態に戻せる保険になる。
確認3：更新後のApache設定チェックと再起動確認
更新後はApacheの設定ファイルに構文エラーがないかを確認してから起動する。# 設定ファイルの構文チェック（起動前に必ず実行） httpd -t # または（systemd環境） apachectl configtest # 問題なければ再起動 systemctl restart httpd # 再起動後のエラーログ確認（サービスが起動していてもエラーが記録される場合がある） tail -20 /var/log/httpd/error_log
サービスが起動していても、モジュールのロードエラーが記録されている場合がある。
更新後にApacheが起動しない場合は、yumのロールバック機能を使って前の状態に戻すことも選択肢のひとつだ。
# 直前のyum/dnfトランザクションを元に戻す yum history undo last # または dnf history undo last # 特定パッケージだけを以前のバージョンに戻す yum downgrade httpd dnf downgrade php
本記事のまとめ
| タイミング | 確認内容 | コマンド・方法 |
|---|---|---|
| 更新前 | 変更対象パッケージの確認 | dnf check-update httpd php* mod_ssl* |
| 更新前 | テスト環境での動作検証 | 本番と同じ環境で先行適用 |
| 更新後 | 設定ファイルの構文チェック | httpd -t |
| 再起動後 | サービス稼働確認 | systemctl status httpd |
| 再起動後 | エラーログ確認 | tail -50 /var/log/httpd/error_log |
| 問題発生時 | 更新履歴の確認 | dnf history list / dnf history info N |
| 問題発生時 | 直前の更新をロールバック | dnf history undo last |
「とりあえずアップデートしておけばセキュリティは安全」という思い込みは危険だ。
更新前の確認、テスト環境での検証、更新後のログ確認——この3ステップを習慣にすることで、同じ失敗を繰り返さずに済む。
Apacheのログ確認については Apacheのアクセスログを設定する方法｜CustomLogとLogFormatの書き方 も参考にしてほしい。
パッケージ管理コマンドの詳細については dnf/yumコマンドの使い方｜パッケージのインストール・更新・削除とリポジトリ管理 をあわせて確認すると理解が深まる。
パッケージ更新の落とし穴は「使い方を知っている」だけでは防げない。サーバー管理の全体像——依存関係・モジュール構成・本番適用プロセスの作法——を体系的に身につけてこそ、初めて予防できる問題だ。
「yum updateが怖い」を卒業するために——Linuxのサーバー管理作法を体系的に身につけませんか？
yum updateで本番が壊れた経験は「一度は通る道」ですが、事前確認と影響範囲の読み方を知っていれば防げます。まずはサーバー構築・管理の全体像を掴んでください。
ネットの断片的な情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます