GUIでログインできなくなった(Ubuntu22.04)

古いNUCにUbuntuをインストールして24時間耐久稼働をはじめてからおよそ2年半。

その間に幾度となくストレージへの書き込みができなくなり、ひょっとしてハズレの2.5”HDDを買ってしまったのかな?と思いながらも毎度毎度fsck /dev/sda2と呪文のように唱えては何事もなかったかのように復活してくれる堅牢さにも関心していたりします。

NUC自体も10年選手だし、排熱に若干問題ありそうな筐体のなかに2TBのHDDを内蔵しているということもあり、さらには24時間連続稼働というのも相まって怪しいところだらけですがちゃんと動きつづけてくれています。きっと私よりよっぽど働き者。

■唐突にCUIでしかログインできなくなり

しかしつい先日、再起動したら fsck を求められるのでいつものごとく実行し、shutdown -r nowのあとでGUIログイン画面が出てくるものと遠目に待っていても、いつまでたっても黒い画面のまま。

近づいてよーく見てみるとCUIでログインを促されているじゃありませんか。

いよいよ修復も適わず、いっそUbuntu丸ごと再インストールしないといけないかなという諦めの境地にさしかかったわけです。

ですが、さすがにすぐに実行するほどの時間的余裕がなく、さらにはGUIで無いだけでそのほかのサービスは全て正常に稼働している様子だったのでしばらく様子見を決め込むことに。

■ひとまずファイルを退避

翌日から、時間の隙間を縫うようにファイルのコピー退避をはじめ、ある程度逃がすことができたので再インストール前に少し実験

ネット界隈を眺めていると時々同じような症状に悩まされる方もいるようで、解決策としてubuntu-desktopを再インストールすればGUIに戻ってくるよ、とのこと。

それならOS丸ごと再インストールよりも楽ちんでよいなと、まずはCUIでログインし、

sudo apt install –reinstall ubuntu-desktop

と実行してみるとなんとなく手ごたえ感(Localeを指定してないので文字化けしてて表示内容がよくわからない状態ですが)

一通りの動作が済んだのを見計らって、期待に胸躍らせ再起動。。。ダメでした。

■CUIからGUIに行ける?

気を取り直し、つぎはCUIでログインしてから startx でGUI起動できるかどうか(先に確認しろよと自分に突っ込みをいれたくなります)※起動を期待したわけじゃなくログを取るつもりでした。

すると、予想に反してGUIに移れるじゃないですか。予想外です。

ひととおりちゃんとGUI操作ができていることを確認し、ログアウトするともとのCUIに戻ってきます。

で、sudo systemctl get-default として設定値をubuntuさんに問うてみると、戻ってくる答えは graphical.target (GUI起動)というわけで ここでも実は multi-user.target(CUI起動) と出てくるんじゃないかと思ったわけなのですが予想が外れました。

■別アカで再設定は?

あんまり意味はないと思いつつも、別のユーザーアカウントでCUIログインしなおし、設定を確認してから apt –reinstall ubuntu-desktop と繰り返してみるも、やはり結果は改善されないまま。

しかし、ふと頭をよぎったのが、

sudo systemctl set-default multi-userこの時点ですでにgraphical.targetなのは承知のうえで

として一旦CUIに設定変更し(変更しなくってもCUIになっちゃってたわけですがあえて)、

sudo systemctl set-default graphical.target

と、再度GUIに設定しなおしてあげる操作をしてから shutdown -r now

すると、一見無駄なような切り替え操作が功を奏して数日ぶりにGUIログインの画面が現れたのでした。

■再インストールよりは時間も手間も省けたかな

定期的に fsck を求められるという不具合の可能性を1つでもつぶしていくために再インストールしたほうが気持ちいいのじゃないかという期待もあったわけですが、

結局のところ再インストールしてもあとから設定を書き戻したりするわけなので、原因を完全につぶせる確率もそれなりに低いわけで、動いているならまあいいか。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

一部サーバーを移設しました

一部のサービスで利用しているサーバーですが、そろそろ稼働させつづけるのも限界が見えてきたようなので移設を計画しておりました。

が、しかし、計画より半年ほど早くあれこれと不具合が出てきたため(私の余計な操作が原因の多くを占めていると思いますが)、当初は2週間かけて行うはずであった移設作業を先週末から昨日まで実施しておりました。およそ半分の期間、かつ日中は他の仕事がわんさか入っている中での作業なので当初の計画は破棄して「突貫移設計画」での作業です。

先に書いておきますがこの記事には技術的な内容は全く含まれていません(だって詳しく書くわけにいかない)。なのでトラブルシュートのために解決策を検索されている方々がもし居たとしたら何の参考にもならない記事だということを先に述べておきます

■さて何が変わったでしょう?

まず大きく変わったのが、東京リージョンから大阪リージョンへ物理的に設置場所が変わりました。と言っても場所もハードも借り物なわけですが(総務省への提出書類に「東京」とか余計なことを書いてなくってよかった

そしてCentOSからUbuntuへとOSも変わりました。CentOSにする前はDebianだったので単純にもとの系統に戻っただけという見方もありますが・・・なにせ6~7年前にCentOSに頑張って移した時はもうディストリビューションを変えることは無いだろうという気持ちだったのです、が・・・情報が多いであろう多勢主流に乗ったつもりが世の中の移ろいはとても速く非情なものでして。

同じLinuxなんだから大差なくて簡単でしょ、と思われがちなのですが似て異なるものってのはずいぶんと厄介なものです。しかも稼働しはじめてから6~7年も経過していればなおさら。

ずっと日常的にLinuxの様々なディストリビューションに触れている猛者な方々にとっては小さな差異なのだろうけれど、そりゃ私だってWindows3.1以降Windows11に至るまで4桁回に迫るほどOSのインストールやトラブルシュートをしてきましたからWindows系ならそれなりに痒い所に勘が働きますが、そういった勘がLinuxに対してはまったく働かないもどかしさがあるものです。

というわけで細かいところまで完璧に移してくることは最初から放棄して、表面上のサービスだけいくつか見た目をそのままにすることだけを考えようというのが突貫移設計画の1項目目。

トラブルが山積みの画像

■いつもなぜか悩むBIND

外部公開用という側面より内部処理用にBINDを使っていて、いいかげん自前で上げるのやめたいなと思っていたのですが、突貫計画では何も考えずにサーバー移行。

でも、なぜかいつもBINDの設定はスムーズにいかないのですよ
私の圧倒的な経験不足。
お名前ドットコムさんのセカンダリーDNSを使わせてもらっているんですが、なんかWEB設定画面でしつこく別メニューに飛ばそうとしてくる構成に戸惑うことが多いような。

何年か前に弄ったときもまずセカンダリに反映されず、あれこれ触っていたものの単純にゾーン設定のシリアル値をカウントアップしてなかっただけというオチだったのですが。

今回も同様にセカンダリに反映されず、ちゃんとシリアル値をカウントアップしているのになぁ、まさか「ミスタイプかなにかで桁違いに大きな値を転送してしまっていた」のかなあ・・・そうなると(1)符号なし整数が溢れるような値を転送して(2)その値が浸透するのを待って(3)再び正常な値を転送・・・とかやってたら72時間x2テイクというぞっとする時間がかかってしまうじゃないか、とか思っていたのですが。

なんのことはない、複数のconfファイルでrecursionの設定がダブってしまいrecursion no;と指定しているつもりが yes;で上書きされていたためオープンリゾルバ対策の一環なのか転送が拒否られていたというオチでした、たぶん(confが複数ファイルに細分化されていくとどうも見落としがちで苦手)

■Postfixというハードルも

いつでも悩ましいPostfixでも、SASL認証ファイルのPermissionが無いとかそもそもファイルが存在しないとかいろいろとログにサーバーからの文句が書かれています。

なにも考えずにCentOSから設定をもってくるとどうもUbuntuとの相性が悪いのか違いが大きくなりがちなところなのかもしれないですね。

ある程度の設定ができたところで外部への送信がうまくいかない。
なぜだろうと調べてみるとOP25Bというハードルが。そうだサーバー契約完了してから72時間くらいは送信できないという制限があるのだった。突貫計画以前の計画では72時間なんか余裕で過ぎてからの作業だったはずなので失念しておりました。ひたすら待つだけ。

その待っている間にも他のサーバーのメールキューにひたすら溜まり続けているのは一体なぜ?と思ったら、オープンリレー対策にと厳しくしすぎたあおり。あれこれPATHが変わったらそりゃPermission deniedやらFile not foundが多発するのを想定すべきところが抜けていたりと反省。ログ見て「あれー権限つけてるのになんでだろう?」とか悩んであれこれ試している暇があったら参照している位置が違っていることに早く気づけ自分と言ってあげたい

■nginxもApacheもサクサク動く

旧サーバーも新サーバーもストレージやメモリ容量などの外形的なスペックは同じなのですが、やはりハードウェアの進化なのかCUIで操作していても速さを感じますね。

おかげで従来はApacheだけでも重さを感じるシーンがあったのが、すっかり解消されてnginxと併存してくれています。これは初期設定作業をしていても気持ちがいい。

というわけで調子にのって、物理的に2台に分散していたサービスを1台に集約してさらにスッキリしました(と言っても内部的なお話なので外から見れば何も変わっていないはずですが)

ただここでもやはりpathが変更になっている影響に悩まされ・・・内部で絶対パスで書くのは極力控えようと猛省。

■綺麗にできなかった部分も残るが

唯一心残りなのはWordPressのサイト構成が従来のまま。気分一新してシンプルに作り直したかったのだけれど、そんな時間的余裕は無いということでHTMLとSQLをまるごとごっそり持ってきて展開しただけ

ただHTMLのパスが変わったのでSQLを流し込む前にSQL文中のパス文字列を書き換えて、ついでにデータベースとしてlatin1なんて設定が残っていた文字コードもごっそりUTF-8に置き換えるという強引な手を使っていますが。

文字コードの違いにはいつも忘れたころに悩まされますよね

今回もデータベースのデフォルト値が変わっていたおかげで「取り込んだデータがなんか化けてるなー」と気づいて変換するきっかけができたわけですが、手元のCUI環境で化けないように整形して満足していたらそのデータベースから文字列を提供するAPIの出力が化けていて、わざわざAPI内でlatin1からUTF-8へ変換していた処理を無効化してあげる余計な作業が発生しました(たぶんまだ見逃している部分があるに違いない)

というわけで作業待ち時間の間にサイトの動作確認を兼ねてだらだらと書き連ねてみたわけですが、この記事のアップも突貫計画の160ステップ目の項目だったりします。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/