動かざることバグの如し

近づきたいよ 君の理想に

Macbookのファン回転数をコマンドから変更する

環境

やりたいこと

コマンドラインからサクッとファンの回転数を変えたい

方法

smcFanControlに依存しているのでbrewでインストール

$ brew install smcfancontrol --cask

ezfインストール

$ npm install -g ezf

全てのファンの回転速度を最大にする

$ ezf --max

全てのファンの回転を自動制御に戻す

$ ezf --auto

参考リンク

docker compose downをすぐに終了させる方法

結論

docker compose down で速攻で終了させたいなら

version: "3"
services:
  app:
    image: ubuntu
    stop_grace_period: 0s

そもそもdocker compose downはなにしているのか

docker-compose.ymlのstop_grace_periodとはdocker-composeは、複数のコンテナを定義し、実行するためのツールです。

docker-composeでは、YAMLファイルにサービス、ネットワーク、ボリュームなどの設定を記述します。その後、docker-compose upコマンドで一括して起動します。

docker-composeを使うときに、サービスを停止する方法について考えたことはありますか?docker-compose downやdocker-compose stopなどのコマンドを使えば、簡単にサービスを停止できますが、その裏ではどのような処理が行われているのでしょうか?

実は、docker-composeでは、サービスを停止する前に、コンテナに対して2種類のシグナルを送信しています。それが、SIGTERMとSIGKILLです。これらのシグナルについて、簡単に説明しましょう。

SIGTERMとは

SIGTERMは、プロセスに対して終了を要求するシグナルです。このシグナルを受け取ったプロセスは、自分自身を終了するために必要な処理を行います。例えば、ファイルのクローズやメモリの解放などです。この処理は、プロセスによって異なりますが、通常は数秒程度で終わります。しかし、プロセスがSIGTERMを無視したり、終了処理に時間がかかったりする場合もあります。その場合は、SIGKILLが送信されます。

SIGKILLとは

SIGKILLは、プロセスに対して強制終了を命令するシグナルです。このシグナルを受け取ったプロセスは、何も処理せずに即座に終了します。このシグナルは、プロセスが無視できないため、確実にプロセスを終了させることができます。しかし、このシグナルは、プロセスが正常に終了するために必要な処理を行わないため、データの損失や不整合などの問題を引き起こす可能性があります。したがって、このシグナルは、最終手段として使うべきです。

stop_grace_periodとは

では、docker-composeでは、コンテナに対してSIGTERMとSIGKILLのどちらを送信するのでしょうか?

実は、docker-composeでは、両方を送信します。まず、コンテナにSIGTERMを送信し、コンテナが終了するのを待ちます。しかし、コンテナが一定時間内に終了しない場合は、SIGKILLを送信して強制的に終了させます。この一定時間を指定するのが、stop_grace_periodというオプションです。 stop_grace_periodは、docker-compose.ymlのサービスに対するオプションです。このオプションは、サービスを停止する前に、コンテナに送信されるSIGTERMとSIGKILLの間に待機する時間を指定します。デフォルトでは、この時間は10秒です。しかし、stop_grace_periodを設定することで、この時間を変更できます。例えば、以下のように設定すると、この時間を5秒に短縮できます。

version: "3"
services:
  web:
    image: nginx
    stop_grace_period: 5s

また、以下のように設定すると、この時間を0秒に短縮できます。

version: "3"
services:
  web:
    image: nginx
    stop_grace_period: 0s

この場合、コンテナにはSIGTERMとSIGKILLが同時に送信されます。これは、コンテナがすぐに停止することを意味します。

stop_grace_periodのメリットとデメリットstop_grace_periodを設定することで、サービスの停止時間を短縮することができます。これは、開発やテストなどの環境では便利な機能です。しかし、本番環境では、注意が必要です。なぜなら、stop_grace_periodを短くすることで、コンテナが正常に終了するために必要な処理を行う時間がなくなる可能性があるからです。例えば、データベースやメッセージキューなどのコンテナでは、終了処理に時間がかかる場合があります。その場合は、stop_grace_periodを長くすることで、コンテナが安全に終了することを確保する必要があります。

まとめ

docker-composeでは、サービスを停止する前に、コンテナに対してSIGTERMとSIGKILLの2種類のシグナルを送信します。この2つのシグナルの間に待機する時間を指定するのが、stop_grace_periodというオプションです。このオプションを設定することで、サービスの停止時間を短縮することができますが、コンテナが正常に終了するために必要な処理を行う時間がなくなる可能性もあります。したがって、このオプションを使用する場合は、環境やコンテナの種類に応じて、適切な値を設定することが重要です。

ssh越しにsudoでGUIアプリ起動する方法

環境

発端

MacOSからubuntusshしてsshX11 Forwardingを利用してGUIアプリをMacOS側に表示させていた

XQuartzを使っている

GSmartControl を使おうと思って sudo gsmartcontrol してみたがエラーになった

$ sudo gsmartcontrol
X11 connection rejected because of wrong authentication.

(gsmartcontrol:3072): Gtk-WARNING **: 08:10:34.175: cannot open display: localhost:14.0

ちなみにgsmartcontrolは、SMART(Self-Monitoring, Analysis and Reporting Technology)というハードディスクやSSDの健康状態を監視する技術を利用して、ストレージデバイスの状態やパフォーマンスをチェックすることができるツール

解決策

$ sudo DISPLAY=$DISPLAY XAUTHORITY=/home/thr3a/.Xauthority gsmartcontrol

ポイント

  • sudoは、スーパーユーザー(管理者)としてコマンドを実行するためのプログラムです。gsmartcontrolは、デバイスの情報にアクセスするために管理者権限が必要なので、sudoを使っています。
  • DISPLAY=$DISPLAYは、環境変数DISPLAYの値をそのまま引き継ぐという意味です。DISPLAYは、X Window SystemというGUI環境で、どの画面に表示するかを指定するための変数です。この部分は、sudoで実行すると環境変数が引き継がれない場合があるので、明示的に指定しています。
  • XAUTHORITY=/home/thr3a/.Xauthorityは、X Window Systemの認証情報を格納したファイルの場所を指定するものです。このファイルは、ユーザーがログインしたときに自動的に作成されます。この部分も、sudoで実行すると認証情報が失われる場合があるので、明示的に指定しています。

参考リンク

Linuxでミスってchmod -Rしたパーミッションを一発で修正する方法

環境

背景

linuxでファイルやディレクトリのパーミッションを変更するときに、chmodコマンドを使うことが多いと思います。

しかし、時々ミスってしまって、例えば/path/to/dirというディレクトリ以下のすべてのファイルやサブディレクトリに対して、

chmod 777 -R path/to/dir

というように、全てのユーザーに読み書き実行の権限を与えてしまうことがあります。これは、セキュリティ上とても危険な状態です。

そこで、この記事では、このようなミスをしたときに、一括でパーミッションを修正する方法を紹介します。

コマンド

chmod -R a=rX,u+w path/to/dir

解説

このコマンドの意味は、以下の通りです。

  • chmodは、ファイルやディレクトリのパーミッションを変更するコマンドです。
  • -Rは、再帰的に変更するオプションです。つまり、指定したディレクトリの中にあるファイルやサブディレクトリも同じように変更します。
  • a=rXは、すべてのユーザー(a)に対して、読み取り権限(r)と実行権限(X)を与えるという意味です。ただし、Xは大文字であることに注意してください。これは、ディレクトリには実行権限を与えるが、ファイルには元々実行権限がある場合のみ与えるという特別な指定です。
  • u+wは、所有者(u)に対して、書き込み権限(w)を与えるという意味です。
  • path/to/dirは、パーミッションを修正したいディレクトリのパスです。

したがって、このコマンドの効果は、path/to/dirというディレクトリとその中身に対して、以下のようなパーミッションを設定するということです。

  • 所有者:読み取り、書き込み、実行が可能
  • グループ:読み取り、実行が可能
  • その他のユーザー:読み取り、実行が可能

ディレクトリまたは実行可能ファイルが 755 に、それ以外が 644 になります。

このようにして、パーミッションを一括で修正することができます。もちろん、このコマンドはあくまで一例であり、必要に応じて変更することができます。例えば、グループにも書き込み権限を与えたい場合は、g+wを追加すればよいです。また、実行権限を与えたくない場合は、Xをxに変えればよいです。詳しくは、chmodコマンドのマニュアルを参照してください。

参考リンク

MySQLのレプリケーションでLast_SQL_Errno: 1594

MySQLレプリケーションを構築している際、スレーブノードのリレーログ解析中にエラー番号1594が発生し、レプリケーションプロセスが中断される問題について、対処策を提案します。

このエラーの発生は、マスターサーバのバイナリログが破損、スレーブサーバにおけるリレーログの損傷、ネットワーク問題、またはMySQLソフトウェア自体の不具合が考えられます。

この問題を診断するためには、スレーブサーバでSHOW SLAVE STATUSを実行し、リレーログの状態を確認することから始めます。

マスターサーバのバイナリログ自体に問題がない場合、それはスレーブサーバでのリレーログの破損が主因であり、その部分からレプリケーションを再開する手段として、以下の手順を踏むよう推奨します。

解決手順

スレーブサーバで以下のコマンドを実行し、マスターサーバのバイナリログファイル名とスレーブへのログ転送位置の情報を取得し、記録しておきます。

SHOW SLAVE STATUS\G

必要な情報は、以下の出力に含まれます。

Master_Log_File: mysql-bin.000001
Exec_Master_Log_Pos: 1111111111

この内容を控えておきます

スレーブの動作を一時停止させます。

STOP SLAVE;

スレーブサーバのレプリケーション状態をリセットします。

RESET SLAVE;

マスターサーバのバイナリログファイルと読出し位置を指定してレプリケーションを設定し直します。

CHANGE MASTER TO 
  master_host='the-master-host', 
  master_user='replication-user', 
  master_password='the-password', 
  master_log_file='mysql-bin.000001', 
  master_log_pos=1111111111;

スレーブの動作を再開し、レプリケーションプロセスを再開します。

START SLAVE;

これらの手順を適切に実行すれば、エラーが解消され、スムーズにレプリケーションプロセスが再開されることが期待できます。

このプロセスでは、データ一貫性を確保しつつ、リレーログの誤っているセクションを回避し、安全にレプリケーションを復旧させる方法を提唱しています。レプリケーションの問題解決にあたっては、慎重さと正確な情報が重要であり、これらの手順を適応する前に、可能な限りバックアップを取ることをお勧めします。