私は、古いAcer Travelmate 4000ラップトップを、Ubuntu Desktopを使用する年齢のローカルサーバーとして使用しました。
今年、16.04 i386 Server Editionをインストールしましたが、これ以上満足することはできませんでした。 Linux、ネットワークスタック、Apache2のワーキングセット全体では、オンボードの2GBのうち37MBしか使用していません... No Swap For You!
問題は、再起動(またはシャットダウン)コマンドの発行が常にコンソールの同じポイントでハングすることです:「到達したターゲットシャットダウン」。ハード電源オフと再起動が必要です。
これをさらに診断するために何ができますか?
UPDATE:提案ごとに、コンソールのコマンドをSudoの下で 'systemctl start debug-Shell'に続けて 'reboot'にキー入力しました。
ただし、このVanillaサーバーにはウィンドウマネージャーがないため、最終コンソールメッセージ「Reached target Shutdown」が表示されたときに、キーストロークの組み合わせでVTを生成して失敗したジョブを一覧表示することはできません。 Alt + SysRqの呪文は、再起動を継続する場合にも効果がありません。
とにかく、「[278.430967] systemd-shutdown:DMデバイスのファイナライズに失敗しました。無視します」という新しい最後のgaspメッセージ行があります。
類似のバグレポート でシャットダウン中にスワップスペースを無効にする回避策を試みましたが、それは助けにはなりませんでした。おそらく、3GBのスワップファイルが使用されておらず、/ tmpの使用量が最小限(約2%)であるためです。
ここでマーカーを前に移動できるものはありますか?
UPDATE 2:提案されたjournalctlおよびsystemctlコマンドの出力をファイルにキャプチャしても、異常な結果は得られませんでした。
このサーバーにはGUIがないため、 このgithubコード を使用して、更新/アップグレード/再起動の前にXenial Proposedを有効にし、新しいsystemd-229が混在するようにしました。
悲しいことに、違いはありませんでした。関連するかどうかはわかりませんが、Ubuntuのインストール時に、/ boot、/ home、/ var、/ tmp、swapのデフォルトのLVMボリュームグループを使用するオプションを選択しました。
この問題を見ているのは本当に私だけですか?
(再起動を発行した後、さらに3分ほど待った後のコンソールのスクリーンショットです):
Ubuntu 16.10が入手可能になり次第、アップグレードしましたが、この問題は修正されませんでした。それ以降のパッケージのアップグレードも適用されませんでした。
ただし、今日のパッケージアップグレードには修正が含まれている必要があります。リモートSSHセッションから通常の「Sudo再起動」を喜んで発行し、1〜2分以内にサーバーに再接続できます。
/var/log/apt/history.logの最新のエントリは次のとおりです。
アップグレード:libsystemd0:i386(231-9git1、231-9ubuntu1)、udev:i386(231-9git1、231-9ubuntu1)、libudev1:i386(231-9git1、231-9ubuntu1)、python3-distupgrade:i386(1:16.10 .7、1:16.10.8)、ubuntu-release-upgrader-core:i386(1:16.10.7、1:16.10.8)、systemd-sysv:i386(231-9git1、231-9ubuntu1)、libpam- systemd:i386(231-9git1、231-9ubuntu1)、systemd:i386(231-9git1、231-9ubuntu1)、libnss-resolve:i386(231-9git1、231-9ubuntu1)
そのリストの中から、巨大な「ありがとう!」必要な魔法の呪文を適用したパッケージメンテナーに出かけます...あなたが誰であるか知っています:)
UPDATE Ubuntuはi386マシンをサポートしなくなったため、幸いにもLubuntu 18.04に切り替えました。味が良く、充填量が少ない!
この問題をいつ/どのように知っているか:「systemd-shutdown:DMデバイスのファイナライズに失敗しました。無視します。」この古いプラットフォームで修正される予定です-私が読んだことは、それがいつでもすぐになることを示唆するものではありません。
それまでの間、この回避策を使用すると、マシンの物理的な電源を入れ直すことなくサーバーを再起動できます。
以下のすべてのコマンドは、Sudoの下にあります。
echo 1 > /proc/sys/kernel/sysrq sync && echo b > /proc/sysrq-trigger
Sshを介してスクリプトをリモートで実行する場合、sshウィンドウをハードクローズして、新しいsshセッションを再確立する必要もあります(マシンが到達可能になるまで1分待った後)。