Archive for the ‘Linux’ Category

サーバのSSL証明書をLet's encrypt(LE)にした時にThunderbirdなどが文句を言ったのは、Windows 7がLEに対応してない(LE対応の証明書が入っていない)せいだと思い込んでいたのだが、それは誤りだったことに今頃気付いた。

先日、たまたまLinux Mintのファイルマネージャでサーバと接続してみたら、やっぱり同じ警告が出たので、今日、その原因を調べてみた。すると、証明書にはサーバ自体のものと、認証局までのもの(中間証明書)の2種類があって、両方をサーバに指定する必要があったのだが、僕はサーバのものしか指定していなかったので、証明書が不完全になっていた。

そのために、ThunderbirdやLinux Mintのファイルマネージャが文句を言っていたのだ。ブラウザ(VivaldiやFirefox)はなぜか何も言わない(確認しても、「証明書は正しい」と言う)ので、問題の発見が遅れた。

それで、さっき、2つの証明書をサーバに設定したら、見事にファイルマネージャの警告が出なくなった。Thunderbirdは、最初に接続した時に警告を解除したので変化が分からないが、きっと大丈夫だろう。

それで、この問題が原因で、iPhoneがカレンダーを同期しなくなる問題が起こっていたのかも知れないとヌカ喜びしたのだが、やっぱり関係なかった。ただ、iCloudの設定を変えると、いきなりアクセスが始まるので、その辺りに鍵がありそうだ。

  •   0
  •   0

テキストエディタは、WindowsではNotepad++を使っていたのだが、Linuxにはないので、(いろいろ試した後に残った、)jEditを使っていた。まあ悪くなかったのだが、昨日、Atomが更新されたというニュースを目にして、ちょっと試してみた。以前試した時は、いろいろ不満があったので却下したのだが、しばらく経って改善されたのではと思ったのだ。

実際に使ってみると、結構良かった。僕が必要な機能はほとんど備えている。そして、表示がシンプル(jEditは昔のソフトのせいか、「ゴテゴテ」している)なのは好ましいし、最新のソフトのせいか、細かいところが使いやすそうだ。キー割り当ても、デフォルトでほとんど僕の慣れと同じだから、設定する手間がない。なお、jEditの「ハイパーサーチ」(検索結果を一覧表示して、押すとジャンプできる)と、選択した単語をハイライト表示する機能がなかったが、find-listとhighlight-selectedいうパッケージを追加したら、できた。

細かいことでは、色遣いが落ち着いていて目に優しい。jEditの色設定はいかにも「テキトー」だったので、自分で調整しろということだったのかも知れないが、いろいろな言語ごとにいちいち調整する気は起きなかった。あと、なぜか、同じフォントを使ってもjEditより綺麗なのもいい。

それから、ごく当たり前のことだが、日本語がまともに使えるのは大きい(jEditは、大抵日本語を入力できなかったので、その場合は別のを使っていた)。

今、一番欲しいのは、プログラムのブロックの範囲を左端に表示する機能だ。Atomでも、ブロックを囲む括弧({}など)同士の背景色を変えられるが、ブロックが大きくてウインドウに収まらない場合には見えなくなってしまうので、jEditの方が便利だ(そもそも、そんな大きなブロックは作るべきでないのではあるが、できてしまったものは仕方ない・・・)。

↑ 近い機能として、Atomにはブロックを畳む機能がある。ブロックの一部をクリックしてから行番号の右の空欄にカーソルを置くと、ブロックの最初の行に"V"が表示されるので、それをクリックすると、そのブロックが畳まれる。なお、jEditのブロックの範囲を示す線も、クリックするとそのブロックが畳まれる。

最後に、一番気に入らないことは、Google製であることだ。仕様や使用条件が勝手に変わるかも知れないし、いつ「終了」になるか分かったものではない。でも、その時は、別のいいものが出ていそうだから、まあいいか。

  •   0
  •   0

懸案だった、サーバのOS更新が無事終わった。更新後に再起動する時は、果たしてちゃんと立ち上がるか、少しドキドキしていた。結構大きいヤマが片付いて、一安心だ。あと4-5年は、こういった作業は不要だろう。

大きな問題はなかったのだが、いくつか気付いた点があったので、書いておく。

  • サーバには、なぜかdo-release-upgrade(OS更新スクリプト)がなかったが、パッケージupdate-manager-coreをインストールするだけで解決した。
  • テスト環境で起こった、do-release-upgradeの実行時に(Python(プログラミング言語)が)エラーになる問題は、なぜか起こらなかった。不思議だ。← 上に書いたように、do-release-upgradeを後からインストールしたからか?
  • なぜか、更新時にaptitude(ちょっと便利なパッケージ管理コマンド)が削除されたので、再度入れた。
  • テスト環境同様、更新後にrunlevel(OSの動作モードのようなもの)が5になっていたので、systemctlコマンドで2相当にしようとしたのだが、runlevelで見ると3になってしまった。でも、プロセス一覧を見ると、余計なものは動いていなかったので良しとした。おそらく、もうrunlevelも/etc/rc*.dの起動スクリプトも意味がないのだろう。だったら削除してほしい。。。
  • 作業で一番時間が掛かったのはバックアップで、圧縮後のサイズが9GBくらいになるせいか、1回80分くらい掛かった。更新自体は、最初は40分、2回目は20分くらいで終わった(それも結構長い気はする)。

そして、やっぱり、何をするにしても、特に、リスクのあることだったら、充分な準備をする価値はあると思った。

(23:47 若干加筆)

 

PS. みんなやっていることかも知れないけど、僕がコマンドライン(ターミナル)で作業をする時は、以下のようにしている。

  1. 実行するコマンドや順序を考えて(あるいは、どこかのページからコピーして)、どこか(例: Dropbox PaperやEvernote)に書く。
  2. それをターミナルにコピー・ペーストして実行する。

コマンドの例(PHPのバージョンを5から7に):
sudo aptitude remove php5
sudo aptitude install php php-cgi php-cli php-curl php-fpm php-gd php-intl php-mysql php-sqlite3 php-ftp php-net-socket php-sockets php-mbstring php-zip php-pdo-mysql php-exif php-apcu

こうすると、後で同じことや同様なことをするのが楽だし、何を実行するかあらかじめ考えるから、間違いが起こる可能性が減る。それに、上のような長大なコマンドだって、タイプミスせずに一発で打てる。更に、何をしたかの記録が残るから、後で何か問題が起こった場合にも、その時実行した処理に問題がなかったかを検討することができる。

また、トラブル対処などで、その場で(アドリブで?)コマンドを実行してしまった場合でも、なるべく、実行したコマンド文字列をコピーして、「**したら動いた」のように残すようにしている。

上のように書くと、「コマンドラインなんて古臭くて面倒だな」と思う人が多いかも知れないが、逆に便利だと思う。もし、GUIで上のPHPの例と同様な作業を記録するとしたら、「*を起動して、*を検索して、*と*と(中略)と*にチェックを入れて、インストールボタンを押す」なんて書くか、スクリーンショットを撮るしかないだろう。

前者の場合、オプションが多いと書くだけでも面倒なうえに、後日再実行しようとしてもコピー・ペーストは無理だから手間が多くなるし、後者の場合、手間に加えて、画像中の文字の検索は無理だから、後で調べるのが困難になるだろう(Evernoteは文字認識するから、検索できるかも知れない)。

  •   0
  •   0

ブログサーバーのOSを更新するため、2/26(日)に本サーバーを停めます。作業終了までは、断続的な動作になる可能性があります。

その日のうちに復帰する予定ですが、予期せぬ問題が起こった場合は、しばらく停まる可能性があります。

作業が終わりましたら、この投稿に追記してお知らせします。

よろしくお願いします。

2/26 10:56: 無事、OSの(2段階)更新が終わり、動作確認中です。ここまでの所要時間は約3時間でした。大きな問題はなかったです。

2/26 13時 動作確認が終わりました。正常運用に戻りました。

  •   0
  •   0

想定外のことがあって、しばらく休みになった。自宅謹慎とかではなくて、インフルエンザである。それで、懸案のブログサーバーのOS更新を試してみた。KUSANAGIを使わないのであれば、確認・移行用に新たなサーバー(VPS)を借りなくても、自分のPCに仮想環境を作って、無料でいくらでも試せることに気付いたのだ(KUSANAGIも仮想マシンを配布しているのかも知れないけど、使う気がないので、パスした)。

試した結果は、いくつか気になる点や注意事項はあるものの、現行のサーバーをインプレースで(「上書き」)更新しても大丈夫そうだった。今日1日(実質半日)で、仮想環境で、古かったOSを最新版に更新でき、テスト用ブログサーバーが動いた。しかも、PHPを7.0にしたせいか、何もしなくても4倍くらい速くなった。

最も気になるのは、「ゴミ」である。今使っているOSは古いため、最新版に更新するには、2回(2段階で)更新する必要がある。その過程でゴミが残って(あるいは、不足が生じて)動作に悪影響がないかと、今までの数年間の運用や試行錯誤でさまざまなゴミが溜まっているだろうから、その影響も気になる。

もしゴミをなくしたいなら、新しいサーバを借りて、最初からセットアップするべきだが、それはかなりの手間だ。

まあ、趣味だし、とりあえず動いたから、上書き更新でもいいような気がする(が、今までの経験上、そうやって手を抜くと、あとで思わぬトラブルが勃発して慌てるのだが)。それならほとんど時間が掛からないでできるし、トラブル対処の勘所も分かったので、もう少し考えてみよう。

以下は、更新に当たって起こったできごとや注意事項などのメモである。OS名を明記しないので、余り参考にならないかも知れない(が、よく読めば、自明なはずである)。

  • OSの更新は、基本的に、do-release-upgradeコマンドでできる(これは、ご丁寧にも、古い版のOSにログインした時に表示されたので、何も調べなくても分かった)。ただし、更新が失敗する場合やパッケージがあった。
    • 1つ前の版から最新にする時、do-release-upgradeが実行できなかった。これは、pythonが古くてaptというモジュールがなかったからのようで、一旦削除してインストールしなおしたら、動くするようになった。
    • mysqlのDBのディレクトリ名(/var/lib/mysql/*)に異常なものがあって、更新に失敗した。使っていないものだったので、そのディレクトリを削除したら成功した。
  • 現行サーバーの環境をコピーするため、ディスクの内容を新しい仮想環境に上書きしたのだが、ファイルの選択がいい加減だったので、/etc/fstabまで上書きしてしまい、ディスクのマウントがおかしくなってしまった。まあ、当たり前のことであるが、/が読み出しのみでマウントされて、fstabの修正もできなかったので、手で読み書き可にマウントしなおして編集できるようにした。
  • PHPはパッケージ版を使ってみた。すると、php-fpmはなぜか/etc/rc?.dから起動できず、プログラムの場所も分からず、再起動するにはOSを再起動しないといけなくて、面倒だった。良く調べたら、場所は/usr/sbin/php-fpm7.0だった。また、なぜか、/etc/init.d/php7.0-fpm startなら起動した。起動スクリプトの仕様が変わったようだが、他にも同様なことがあるので、要調査だ。
  • パッケージ版のPHPは、現在ビルド時に指定している、さまざまなモジュールをapt-getに"php-curl"のように指定して追加すれば、今使っているものと同等の機能のものがインストールできた。
  • 当然ながら、パッケージ版のPHPに移行するには、元々の(自分でビルドした)PHP関連コマンドを削除しないと、誤動作する。
  • ブログ(WordPress)を正しく動作させるためには、仮想環境にドメイン名を付け、それに合わせて、webサーバの設定とWordPressの設定(設定ファイルと「サイトアドレス」)を変える必要があった。webサーバの設定はもう少し綺麗にしたいが、仕様が難解で難しい。。。
  • ブログでは、以前PHP 7を試した時に生じた問題(ウィジェットの設定画面がおかしい)が再発した。しかし、検索しても同様の問題はないので、更に調べたら、自作のウィジェットが原因だった。一部の標準ウィジェットをカスタマイズするため、コピー・変更して使っていたのだが、その使い方がPHP 7に互換でなかったようだ。これはフックにできないだろうか。
  • PHP 7.0にしたら、ブログの表示は約4倍速になった。ただし、正規表現での検索は10倍くらい遅くなった。自作したものなので、効率の悪い点がありそうだ。また、ページを最初に表示する時は遅い。これは、PHP 7.0の動作(JITやキャッシュ?)に関係しているのかも知れない。
  • もう一つのブログや他のwebサービスも、問題なく動いている感じだ。
  • カレンダー・アドレス帳サーバーは、最初は予想外のエラー(HTTP 400)が出て動かず、ちょっと苦労したが、何とかなった。設定の、「信頼するドメイン」に、サーバー自身のドメインを追加する必要があるようだ。それがどういう意味なのか(自分すら信頼できないのか??)、今ひとつ分からない。
  • パッケージ版のwebサーバーも試したが、ログやSSL証明書の場所の設定を若干修正する程度で問題なく動いた。僕の用途では、最小構成で充分なようなので、得した気分だ。(20:47)
  • パッケージ版のPHPのバージョンは最新ではなく、約3か月遅れで、辛うじて許せるレベルだ。一方、webサーバーは、約10か月遅れなので、ちょっと古い感じだ。今までwebサーバーの問題を見たことがないから古くてもいいが、心配なのは、セキュリティ面だ。
  • https(SSL)の証明書は、現行サーバからコピーしたものではブラウザに文句を言われたが、sshの鍵は、コピーしたものがそのまま使えた。確かにそういうものだが、本当にそれでいいのかと思う・・・
  • OSを仮想環境にインストールしたせいか、runlevelが5(デスクトップ用らしい)になっていて、時々文句を言われた。直し方は不明だが、とりあえず動いたし、実環境は2なので、問題ない。

(2/16 17:21追記) その後、準備や調査をした結果を書く。

  • php-fpmが/etc/rc?.dから起動できなかった問題は、Linuxの起動時のプログラム起動システムが(、さまざまなものを経て、)今は、systemdというものに変わっているためだった。ただ、昔ながらの起動スクリプト(/etc/init.d/*や/etc/rc?.d/*)も残っているので、それを使ったら騙され失敗した。何とも中途半端だ。だから、php-fpmは、正しくはsystemctlコマンドで起動するべきだったのだ。だが、これもいつまで続くか分からないし、手で自作のサーバープログラムを追加するのは面倒そうなので、なかなか覚える気がしない。
  • ランレベルも同様で、昔は設定ファイル(/etc/inittab)があったのに、今はなくなっていて、"systemctl set-default multi-user"などのようにして変更するそうなので、分かる訳がなかった。
  • なかなか苦労して、webサーバの設定をかなり綺麗に簡素にでき、行数を半分以下にできた。今までは、文法が難解なので、いろいろなサイトのコピーをベースにして、おそるおそるいじっていたため、ゴミが多かったのだが、今回は観念して腰を据えて、気合を入れて文法を理解しつつ抜本的に作りなおしたので、「どうしてこうなんだろう?」という箇所はなくなり、ゴミもほぼ0になった。また、非推奨の処理もなくせた。でも、これがサーバの高速化に繋がるかと言えばそうでもない。だが、保守性の向上とかセキュリティホールができにくくなることには繋がる。以下に新旧の行数の比較を載せる。
    • 現行: 705行 (2ファイル)
    • 改良後: 310行 (4ファイル)
  • 自作のウィジェットがPHP 7.0でエラーになる問題も対処できた。どういう訳か、作成当時にエラーになったので止めていた方法(元になるウィジェットのサブクラスを作る)がすんなり通ったので、PHP 7.0でのエラーは起こらなくなり、コピーの部分もほとんどなくなった。不思議なことに、それが今のPHP 5でも通ったので、当時のPHP 5にバグがあったのか、僕の思い込みだったのか不明だ。

そんな訳で、OS更新までに残る作業は、作り直したwebサーバの設定の動作確認程度である。これが、(手でやる場合には)拒否・通過設定しているURLをブラウザで1個1個開いていくという、なかなか手間が掛かるうえに間違いやすい作業なのだが、設定修正のたびに繰り返すのは嫌なので、確認用スクリプトを作って自動化したいと思っている。

(2/18 17:02追記) その後、サーバのセキュリティ関連設定確認用スクリプトを作って確認し、問題を見付けて修正して、問題なくなったことが分かったのだが、その後でブログを見たら、みごとに崩れていて、とても参った。「完璧な設定」に見えたのは、どうも、サーバの各種プログラムの不思議な動作(いちいち停めないと駄目だったり、OSの再起動すら要る場合がある)やブラウザのキャッシュによって作られた「幻」だったようだ。

今でも、「修正できたと思ったら、実は駄目だった」の繰り返しである。このwebサーバは、なかなか一筋縄に行かないようだ。

それから、その設定確認用スクリプトを作っている時にも、大いにはまった。スクリプトは、準備として、外部(web)からアクセスできない場所にファイルを作る(それをアクセスしても、サーバの設定でブロックされることを確認する)のだが、2回目に実行すると、必ずサーバにssh接続ができなくなってしまう。いろいろな原因を疑って一つずつ潰して行ったのだが、原因が分からなかった。そして、試してみたら、現行のサーバでも同じ現象が起こった。それで、かなり悩んで、ふと、(自分で設定した)IPフィルタ(簡易なファイアウォール)かも知れないと思って調べたら、本当にそうだった。

ブログサーバを立ち上げた頃に、sshを頻繁に繰り返す攻撃を無効化する設定を、どこからか見付けて入れていたのだ。その後、そんな設定をしたなんてことはすっかり忘れていたのだが、今回の設定確認用スクリプトは、確認用ファイルを作るために、まさに頻繁にssh接続するので、すぐに限界(例: N回/時間)に達してしまっていた。OS更新テスト用の仮想環境も、ブログサーバの内容をほぼまるごとコピーしたので、設定が有効になっていたのだ。全くあてにしていなかったのにちゃんと動いてくれてうれしかった反面、思わぬ落とし穴にどうしたものかと思った。

一時的に無効にすることは可能だが、何度もやるうちに戻し忘れるのが嫌だ。それで、いろいろ考えて、確認用ファイルの作成と削除は、1ファイルごとにssh接続せず、まとめて1回のsshで実行するようにした。その(長々とした)コマンドを作るのがかなりの手間だったが、とりあえず動いて、問題は起こりにくくなった。めでたし、なのか??

(2/19 8:30追記) 大変な苦労の末、サーバの設定の改良が終わった。仮想環境では再起動しても壊れなかったので、おそらく大丈夫だろう。そして、今朝、実サーバにも適用した。いくつか問題が見つかったので、修正した。今のこれが幻でないことを祈るばかりである。

ちょっと残念なのは、いくつか、例外的な「汚い」処理が必要だったことだ。まあ、今の僕の技量ではそこまでってことだ。でも、今までの設定に比べたら、随分まともになったと思う。そんな訳で、設定の行数は361行に増えた。

  •   0
  •   0

ブログサーバーのOS更新の件。

KUSANAGIについて、一番気になっている点(複数のブログ/httpサービスが実現できるのか)を調べたのだが、ドキュメントが貧弱過ぎて、確実なことは分からなかった。あと、全体をKUSANAGI固有の環境とか操作手順(コマンド)に変えてしまっているのが、(僕に言わせれば)何ともセンスが悪い。更に、セキュリティについては、元々良い訳ではなく、自分で設定を変更して向上させる必要があるようだった。しかも、そのレベルが低い。「(独自環境にしたんだから)そんなのデフォルトでやっとけよ」って感じだ。

そして、こんな(言い過ぎかも知れないが、いい加減な)会社に少なくとも10年も依存していいのかという疑念すら生じた。例えば、WordPressの更新がリアルタイムにでき(てい)るのだろうか? とか、数年で会社がなくなることはないのだろうか? などだ。そもそも、高速化しなくたって、何も問題はないのだ。

大体、あのキャラ(わざわざそんなのを作ったこと自体)も、起動時の大げさなバナーも全然気に入らない!

そんな訳で、僕の体温に反比例して、KUSANAGI熱は一気に醒めてしまった。

CentOSについても、10年のサポート期間は魅力だが、(今使っているOSの)5年だって大きな問題はないと思える。5年に1度、ちょっと手間を掛ければいいだけだ。逆に、10年も経つと、次のOSはものすごく変わっていて、更新は更に大変ではないだろうか。仕事でCentOSを使う可能性はあるが、そんなの会社でやれば充分で、自宅でまで苦労したくない。OSなんて、(WindowsやMacのなどを除いて)何だって良くて、ちゃんと動けばいいのだ。

という訳で、今は、今使っているOSの最新版に更新する方向に傾きつつある。

  •   0
  •   0

このブログサーバーのOSは、かなり古い。まだサポート期間内だが、もうすぐ切れる。それで、そろそろ最新版に更新しようかと思っている。それで、昨日、手順や起こりうる問題などを考えたり検索したりしていたら、思わぬ新機軸が見つかり、それまでの考えとは全く違う方向に行く(暫定の)結論になった。

まず、コンセプトや目指すところは、それまでの「現状維持」(単に今のOSを更新する)から、以下になった。

  • 管理の手間を減らす。
    • 毎月のようにPHPを更新(ソースからビルド)しているが、もう止めたくなった。
    • Webサーバの更新も、頻度は低いが、やっぱり面倒。
  • ブログの高速化 : 遅くても問題はないが、速い方が気持ちいい。

手段としてはKUSANAGIというシステムに移行する。

実際には、使っているサーバー会社のサポートするOSのページを見たら、KUSANAGIもサポートしているのを知り、それ(以前見たことがあるのだが)を使えばブログ(WordPress)を劇的に高速化できそうなことに気付いた。しかも、WordPressの環境が最初から全部構築されているので、PHPやwebサーバーなどの更新は自動で行われそうだし(そうでなくても更新のコマンドを実行するだけだろう)、Let's encryptのSSL証明書のサポートも入っているようなので、管理の手間がかなり減りそうなことが分かった。

KUSANAGIでは、副次的ではあるが、セキュリティの強化も期待できそうだ(少なくとも今よりは良くなりそうだし、自分でセキュリティに配慮する負担は減るだろう)。更に、新しいLinuxの勉強もできそうだ(というか、しなくてはならない)。というのは、サーバー会社が提供するKUSANAGIはCentOSで動くのだが、(それは今と同じLinuxではあるが、)系統が違うので、管理方法や操作が若干異なる。でも、仕事で使いそうだし、覚えておいて損はないと思う。また、CentOSはサポート期間が10年と長いのが魅力的だ(今のは5年程度)。

次に、移行手順だが、今使っているサーバーをいきなりKUSANAGIに変えることは無理だし危険だし苦労が多いので、そうはせず、「軟着陸」させる。

実際には、今のOSを更新するだけと考えていた時から、直接更新せずに一旦別のサーバーを借りて、そこで動作確認してから移行することを考えていた。それで、サーバー会社のページでKUSANAGIを見つけたのである。

移行手順は以下を考えている。

  1. 移行先のサーバーを借りる。(OS=KUSANAGIで設定)
  2. 新サーバーに、仮のドメイン名を付ける。(サーバー会社が提供するのが使える?)
  3. 新サーバーに、今のサーバーのコンテンツなどをコピーする。
  4. しばらく(3か月以内を目標)、動作確認と調整を行う。
  5. 新旧サーバーの切り替え
    1. 新旧サーバーのwebサーバーを停止する。
    2. 新サーバーのコンテンツを最新にする。
    3. 新サーバーのドメイン名を今のに変える。
    4. 新サーバーのwebサーバーを起動する。
  6. 仮のドメイン名の契約を終了する。
  7. 新サーバーの安定動作を確認後(3か月程度)、旧サーバーの契約を終了する。

移行期間は長くて半年程度と考えているので、コストは1万円未満(新旧サーバーの重複期間の使用料+仮ドメイン名の費用)だろう。

懸念事項は以下である。

  • KUSANAGIに致命的な問題がないか? → 出てからしばらく経っているので、大丈夫では?
  • いつまでKUSANAGIが続くか? → 終わったらまた考える。どうせ、後継が出てくるだろう。
  • 今使っているWordPressの機能・設定・プラグインが全部動くか。→ 駄目な時は代替を探す。
  • PHPが高速版(HHVM)に置き換わるが、他のPHPのプログラムが問題なく動くか。→ 動作確認して、調整する。それでも駄目なら、HHVMを使わない。
  • 自分で追加した機能がうまく移行できるか。→ 同等のものがKUSANAGIにあればそれを使い、なければ自分のを動かす。
  • HHVMがFacebook製なのが気に入らない。→ MSよりはマシなので、我慢する。
  • "KUSANAGI"とか"HHVM" (Hip Hop VM)とか、名前が気に入らない。KUSANAGIのキャラも気に入らない。→ 我慢する。
  •   0
  •   1

Wi-Fiルーターを交換した頃から、時々、PCを休止する時にハングするようになった。休止とルーターは全く関係ないと思うのだが、妙な符合である。古いルーターは壊れてしまったので、元の環境では試せないから、全く関係ないともいえない。

結論としては、解決していない。今日、休止時にPCの電源を完全に切るようにLinuxを設定して(/etc/pm/config.d/hibernate_modeにHIBERNATE_MODE="shutdown"と書く)、様子を見ようとしている。これだとキーボードを押しても復帰せず、毎回電源ボタンを押す必要があるが、ハングするよりはマシだと思う。

他に、休止でなくスタンバイ(スリープ)にするという手もある(Linuxでは、デフォルトでは休止は無効になっており、こちらが推奨されている。Linux Mintだけが休止を有効にしている)のだが、停電とか間違って電源を落としたりした時に保存した状態が失われるので、避けたい。

ハングした時、pm-suspendのログでは最後まで成功したように書いてあるし、ホットキー(Alt+PrintScreen+R+S+E+I+U+O: 下線を押したまま、次のキーを連続して打つ)での終了・停止は可能なので、おそらく、PCを微妙なスタンバイ状態(S4?)にするのに失敗している、あるいは、何かを待ち続けているのではないかと想像している。

なお、今までに以下を試したが、効果がなかった。

  1. 休止前に、メモリ中のキャッシュやバッファを書き出す。
  2. 休止前に、ネットワークを停める。
  3. /etc/pm/sleep.d/下のスクリプトの順序を変更する。
  4. BIOSの”Memory remap feature”を無効にする。

BIOSの設定を変えた後は、しばらく(10日間くらい)大丈夫だったので、ぬか喜びしていたのだが、今日再発してしまった。理論的に考えれば、それは当たり前で、もしBIOSが原因なら、もっと頻繁に現象が起こるし、Windowsでも駄目だったはずだからだ。

結局、上記の休止時にPCの電源を切る設定は効果がなかった。設定の5日後(1/26)にハングした。そのため、休止は諦めて、スリープ(スタンバイ)を使うことにした。まだまだLinuxの休止は難しいようだ。。。(1/27 3:19)

 

PS. この問題については解決に至っていないのだが、ArchLinuxのWikiには、僕が使っているLinux Mintとは異なる場合があるながらも、さまざまな有益な情報やヒントが書いてあって、大変役立っている。

PS2. Linuxの休止からの復帰は、(体感で)Windowsの数倍速い。Windows 7の時は復帰完了を待つのにイライラしたが、Linuxだとほんの数秒で終わるから(メモリの使用量が少ないからなのかも知れない)、全然苦にならない。そういうこともあって、是非、休止をちゃんと使えるようにしたいのだ。(1/22 6:55)

  •   2
  •   0

以前から気になっていたのだが、Vivaldi(Linux版)で、フォーム(文字入力欄)に入力をする際、日本語入力のモード反映が遅れるのか、1文字目がおかしくなる。

具体的には、日本語入力(ローマ字入力)がONなのに、最初の1文字だけアルファベット(半角)で入る。例えば、「あいうえお」と入れたのに、「aいうえお」になる。

最初の文字がおかしいのを見て、反射的に日本語入力切り替え(全/半)キーを押すと、(それまでONだったので)逆にOFFになってしまって、全部打ち込み直しになる。それで、文字を入れる時は、日本語入力の状態アイコンを慎重に確認し続ける必要があって、入力のスピードが落ちるし、大体毎回打ち込み直しさせられるのにも、イライラしていた。

それが、先日、ダメモトで検索してみたら、関連しそうなページを見つけた。リンク先の「アドレスのオートコンプリートを無効に」である。書いてある現象がほとんど同じだったので、試しにオートコンプリートをOFFにしてみたら、まだ2日間程度ではあるが、問題が起こっていない。

なお、これはLinux版だけの問題なのか、他の版(Windowsなど)でも起こるのかは不明だ(確か、Windowsでは起こっていなかった気がする)。ちなみに、僕の環境は以下である。

  • OS: Linux Mint 18
  • 日本語入力環境: Fcitx+Mozc
  • Vivaldi: 1.6.689.46

また、Chromeでも同様の現象があると聞いたことがあるが、上の情報が見つかる前に、スペルチェックをOFFにすると直るという情報が出て来た(Vivaldiにはスペルチェック機能はない)。また、もしアドレスのオートコンプリートがあるなら、それも効くのかも知れない。

PS. 題に追加したように、これは効果がないのかも知れない。以前よりはいい感じだが、やっぱり、1文字目や2文字目がおかしいことがある。まあ、諦めずに試行錯誤しよう。。。(1/11 21:28)

  •   0
  •   0

(個人用プログラムで公開する予定がないので、それについて書いてもあまり意味がないかも知れないが、デジカメ画像の取り扱いにまつわる問題や、それへの対処方法のヒントとして書く)

数か月前からの懸案だった、デジカメからLinuxへの画像取り込みプログラムの「1万枚問題」への対応ができた。これで概ね完成だ。

問題への対処として、カメラ内の親ディレクトリ名もカメラ識別記号の生成要素にすることにした。そのため、カメラ内の親ディレクトリが変わると、画像ファイル名に追加される識別記号も変わる(はずである)。

例(".JPG"の前の10桁の数字が識別記号):

  • カメラA内の、親ディレクトリが"DCIM/147CANON/"の画像ファイル名: "IMG_1234_1234567890.JPG"
  • カメラA内の、親ディレクトリが"DCIM/148CANON/"の画像ファイル名: "IMG_3456_9876543210.JPG"
  • カメラB内の、親ディレクトリが"DCIM/100APPLE/"の画像ファイル名: "IMG_0039_0918273645.JPG"

内部的には、カメラや画像の識別記号が2種類に増えた。一つは、以前から使っていた、カメラの型名やSNなどから生成される値。もう一つは、上記の、親ディレクトリ名も含めて生成される値である。前者は、取り込み済み画像ファイル一覧の中でカメラごとにファイル名を保存するために使用し(ファイル名は、親ディレクトリ別に保存するようにした)、後者は、各種のカメラから取り込んだ画像ファイル(カメラ間・カメラ内でファイル名が重複する可能性がある)を区別するために使用する。

それから、以下の便利な機能も追加した。

  • 画像の保存ディレクトリを、(以前は手動でやっていたが、)自動的に3か月ごとに区切る。(例: "2017/2017_01-03/2017_01_08"の太字の部分) こうすることで、年直下のディレクトリ数が減って、すっきりする(月ごとでもいいが、以前に合わせて3か月ごとにした)。
  • 新しく取り込んだファイルの判別が容易になるように、特定のディレクトリ(例: "New")に、取り込んだファイルへのシンボリックリンクを作る。取り込んだファイルの後処理(例: タグ付けやコメントの記載)が終わったら、そのシンボリックリンクを削除すれば、「新しい」という情報を簡単にクリアできる。
  •   0
  •   0