※当サイトの記事には、広告・プロモーションが含まれます。

Dockerコンテナでマウントしたホスト側のディレクトリで配置されたログをローテーションしたかったが...

www.itmedia.co.jp

 米Alphabet傘下の自動運転企業Waymoは10月25日(現地時間)、シリーズCラウンドで56億ドルを調達したと発表した。Alphabetが主導し、これまでのラウンドに続けてAndreessen Horowitz、Fidelity、Perry Creek、Silver Lake、Tiger Global、T. Rowe Priceが参加した。Waymoの資金調達はこれで3回目。累計で110億ドル以上となった。

Waymo、56億ドル資金調達 ロボタクシーのさらなる普及目指す - ITmedia NEWS

⇧ 金額がエグい。

By the way、

gigazine.net

Microsoftは2024年に2550人もの従業員を解雇し、複数のゲームスタジオを閉鎖しているにもかかわらず、同社のサティア・ナデラCEOの報酬は前年比で63%増の7910万ドル(約120億円)に増額していることが明らかになりました。

Microsoftが人員削減や傘下のゲームスタジオの閉鎖を行う中でサティア・ナデラCEOの報酬は前年比63%増の120億円超だったことが明らかに - GIGAZINE

MicrosoftがSECに提出した資料によると、ナデラCEOは2024会計年度に業績連動型株式報酬として5000万ドル(約76億円)を受け取る予定となっていました。これについて、Microsoftの取締役会はナデラCEOの並外れたリーダーシップと、Microsoftの事業規模の大きさおよび複雑さを考慮すれば、「この株式報酬は適切な水準である」と述べています。

Microsoftが人員削減や傘下のゲームスタジオの閉鎖を行う中でサティア・ナデラCEOの報酬は前年比63%増の120億円超だったことが明らかに - GIGAZINE

⇧ 取締役会の評価の意味が分からん...

過去にも、

www.itmedia.co.jp

 ナデラ氏はMicrosoftの取締役でもあるHarvey Mudd College校長マリア・クロウェイ氏と登壇した。講演の終わりに、クロウェイ氏が昇給を願い出ることをためらっている女性技術者に対してアドバイスを、と促したところ、「給料アップを頼むのではなく、組織が適正な昇給をすると信じることだ」とし、「昇給を求めない女性は良いカルマ(サンスクリット語で「結果を伴う行為」の意)を持ち、良い結果を得られるだろう」と語った。同氏はインド出身だ。

MicrosoftのナデラCEO、女性技術者についての“誤った発言”を即日謝罪 - ITmedia NEWS

⇧ とか有り得ない言動してますが、自分の利益のことしか考えない「サイコパス」野郎なのかしら?

とりあえず、2023年の話ではあるけども、

www.businessinsider.jp

同社のサティア・ナデラ最高経営責任者(CEO)は5月10日、2023年の昇給(社内では成果による昇給を意味する「メリット・インクリース」の言葉が使われる)を凍結し、賞与と株式報酬に充てる原資を圧縮して過去の平均水準に戻すことを明らかにした。

「マイクロソフトはひどい職場」「CEO報酬は一般社員の289倍」昇給凍結発表後、社内で経営批判殺到 | Business Insider Japan

www.businessinsider.jp

マイクロソフトは1月に1万人の従業員をレイオフすると発表。その後、2023年の昇給のほとんどを停止し、賞与と株式報酬を減らすことも発表している。

マイクロソフトのナデラCEO、期末を迎え従業員に謝意を贈るも「感謝しているなら昇給凍結の解除を」 | Business Insider Japan

⇧ 上記のようなことしているってことは、取締役会のメンバーは自分たちが不利益を被らないように、ナデラへの評価は忖度されたものになっているってことなんかね?

ほぼ、独裁政治のような状況になっていそうですな...

www.businessinsider.jp

マイクロソフトの職場文化に前向きな変化が見られる」と肯定的に回答した従業員の割合は、1月の62%から7月には月平均40%にまで低下した。

マイクロソフトの士気が低下している…社内意識調査で企業文化や経営陣への評価が悪化 | Business Insider Japan

⇧ 2023年がこういう状況であったにもかかわらず、2024年度は、

報酬は前年比で63%増の7910万ドル(約120億円)に増額

って、2023年度の時点でも過大評価にも程がある気がするんだが...

何と言うか、従業員のモチベーション上がるわけないよね...

Red Hat系のディストリビューションのバージョン9系でlogrotateの仕様が変わったらしいが

前回、

ts0818.hatenablog.com

⇧「Oxidized」の「ログローテーション」をどうするかの話で、

dev.classmethod.jp

⇧ 上記サイト様によると、Red Hat系のディストリビューションのバージョン9系から「logrotate」のトリガーが変わったらしいですと。

例の如く、ChatGPTに質問してみたところ、

No 機能/要素 Red Had系ディストリビューション
バージョン9以前 バージョン9以降
1 主要設定ファイル /etc/logrotate.conf /etc/logrotate.conf
2 個別設定ファイル /etc/logrotate.d/ /etc/logrotate.d/
3 デフォルトのローテーション間隔 月次(weekly)または日次(daily)指定可 月次(weekly)または日次(daily)指定可
4 トリガー方式 スケジュール設定(cronなど) スケジュール設定(systemd timers推奨)
5 ユーザーごとの設定 ※1 ユーザーごとのスケジュール可能 ユーザーごとのスケジュールが難しい
6 エラーログ出力 設定で指定(notifemptyなど) 設定で指定(notifemptyなど)
7 新機能 特になし systemdログと統合のための新しいオプション
8 設定ファイルの位置 標準の位置 標準の位置

※1 おそらく、スケジュールの設定のことかと。「cron」は、「ユーザー」毎に設定ファイルが追加できた気がするので。その分、管理が煩雑になるってことかね。

⇧ 上記のような回答が返ってきた。

「cron」だと、「ユーザー」が増えたりすると、「cron」の設定が散逸して管理が大変だから、「systemd timers」に統一したってことなんかね?

Dockerのコンテナでマウントしたホスト(「Dockerホスト」)側のディレクトリに配置されるログをローテーションしたいが、アクセス権の問題とかもあるらしい

「Docker」の「コンテナ」で「ホスト」側のディレクトリをマウントしていることもあり、「ホスト」側の「logrotate」で「ログローテーション」したいのだけど、

recruit.gmo.jp

⇧「アクセス権限」の問題が起こりますと。

で、ネットの情報を漁って見た感じ、

serverfault.com

iww.hateblo.jp

⇧ 上記サイト様によりますと、「ホスト」側の「logrotate」が厳しそう...

「ホスト」側の「logrotate」が「Docker」のボリュームのマウントを解釈できないらしく、「コンテナ」側の「uid」「gid」を認識してくれないらしい...

そもそも、「Docker」の「コンテナ」で稼働しているアプリケーションのログを「ログローテーション」するアプローチとしては、

  1. 「ホスト」側の「logrotate」で行う
  2. 「Docker」の「コンテナ」側の「logrotate」で行う

のどちらが、メジャーなんだろうか?

AWSAmazon Web Services)」の公開している情報だと、

aws.amazon.com

⇧ わざわざ、「logrotate」用の「Docker」の「コンテナ」を用意している。

なるほど、「AKSAmazon Elastic Kubernetes Service)」のような「オーケストレーション」ツールを利用しているような環境においては、「Pod」毎に管理できるから、「コンテナ」を作ってしまった方が良いってことみたいね。

オーケストレーション」ツールの魁「Kubernetes」のドキュメントによると、

kubernetes.io

⇧「logrotate」は「kubelet」が管理するという説明なのだけど、

kubernetes.io

⇧とあるので、「logrotate」も「コンテナ」で稼働してるということですかね。

何と言うか、「ホスト」側の「logrotate」を利用した事例が出て来ないということは、「コンテナ」で「logrotate」を稼働させて「ログローテーション」しろってことなんですかね。

後は、

stackoverflow.com

qiita.com

⇧「ログローテーション」時に、Dockerコンテナで稼働しているアプリケーションのプロセスを強制的に新しくするというアプローチがあるようですと。

Dockerの公式の見解を伺いたいものですな。

とりあえず、ホスト(「Dockerホスト」)側に「logrotate」をインストールする

正確には、「ホスト」ではなく「Dockerホスト」になるのだが、「ホスト」との記述は「Dockerホスト」のことを言っているんだなと捉えていただいて話を進めていきたいと思います。

※「」で囲まれていない"ホスト"や『』で囲まれた"ホスト"は「Dockerホスト」ではないと思ってもらえればと。

検証する環境としては、「WSL 2(Windows Subsystem for Linux 2)」による仮想化を利用しており、

No 環境 OS 内容
1 ホスト Windows 10 Home Tera Term、WinSCPなどインストール済み。
2 ゲスト Rocky Linux 9.4 Docker、Docker Composeなどインストール済み。

⇧ と言った感じ。

「Dockerホスト」は「Rocky Linux 9.4」になるということですね。

「Dockerホスト」というのは、

docs.docker.jp

Docker のアーキテクチャとは?

Docker はクライアント・サーバ型のアーキテクチャです。Docker クライアント が Docker コンテナの構築・実行・配布といった力仕事をするには、 Docker デーモン と通信します。 Docker クライアントとデーモンは、どちらも同じシステム上でも実行できます。あるいは、Docker クライアントはリモートの Docker デーモンに接続するのも可能です。Docker クライアントとデーモンは、お互いにソケットもしくは RESTful API を経由して通信します。

https://docs.docker.jp/v1.11/engine/understanding-docker.html

⇧ 特に説明は無いのだけど、「Docker デーモン」が稼働している環境といった感じですかね?

「Dockerホスト」のややこしいところが、

docs.docker.jp

⇧ 上記の図のように、「Docker」をインストールしてる環境によって立ち位置が変わってきますと。

今回の自分の環境は、上記の図で言うところの「Linux」となるイメージ。

Windows」の方は、『ホスト(ややこしいが、ここのホストは「Dockerホスト」ではなく、通常のホスト)』側に「Docker クライアント」をインストールしてる感じ。

「Docker Desktop」については情報が見当たらず、どういう構成になってるのか分からないのだけど、「Docker Desktop」のような使い方ができるものとして登場した「Rancher Desktop」が公開している情報によると、

docs.rancherdesktop.io

Rancher Desktop is an electron-based application that wraps other tools while it also provides the user experience to create a simple experience. On macOS and Linux, Rancher Desktop leverages a virtual machine to run containerd or dockerd and Kubernetes. Windows Subsystem for Linux v2 is leveraged for Windows systems. All you need to do is download and run the application.

https://docs.rancherdesktop.io/references/architecture/

⇧上図のような感じのアーキテクチャになっており、「k3s」という「Kubernetes」を軽量化した「オーケストレーション」ツールが含まれているのだけど、「containerd」というものが、

www.docker.com

containerdとは何ですか?

要するに、containerdはコンテナを実行するために構築されたランタイムです。

https://www.docker.com/ja-jp/blog/containerd-vs-docker/

containerdは、オペレーティングシステムと直接連携することで、コンテナの操作を容易にします。 Docker Engine は containerd の上にあり、追加の機能と開発者エクスペリエンスの強化を提供します。

https://www.docker.com/ja-jp/blog/containerd-vs-docker/

⇧ とあるので、「Dockerホスト」とは別の場所に「Docker クライアント」が配置される感じっぽいので、「Docker Desktop」も似たような構成になっているのでは無いかと。

この記事では、「ホスト」は「Dockerホスト」のことだと思ってもらえればと。

話が脱線しましたが、「WSL 2(Windows Subsystem for Linux 2)」だけの問題なのか、「Rocky Linux」の9系に「logrotate」が同梱されておらんのよね...

⇧ 個別設定ファイルだけ存在する謎...

VirtualBox」の仮想マシンにインストールした「Rocky Linux」の9系だと「logrotate」がインストールされていたので「Rocky Linux」よく分からんよね...

とりあえず、「ホスト」側に「logrotate」をインストール。

■「logrotate」をインストール

dnf install -y logrotate

⇧ インストールされたっぽい。

「/usr/lib/systemd/system」ディレクト配下にインストールされたということなんだろうか?

どういう状態なのか確認。

■「logrotate」がインストールされたのか確認

職場の方に教えてもらい、途中まで入力して、「Tab」キーを2回タターンってすると候補が表示されるのは便利なので使っていこう。

ls -la /etc/logrotate.

■「logrotate」の起動をスケジュールしてるらしい「systemd-timer」が管理してるサービスの確認

systemctl list-timers

⇧ 何やら「logrotate」はまだ管理に含まれていないっぽい。

■「logrotate」のインストールで追加されたっぽいファイル群の確認

「Tab」キーを2回タターンってする

ls -la /usr/lib/systemd/system/logrotate.

■「logrotate.timer」のサービスの状態を確認

systemctl status logrotate.timer

■「logrotate.service」のサービスの状態を確認

systemctl status logrotate.service

■「logrotate.timer」のサービスの状態を確認の結果

[root@Toshinobu-PC ~]# systemctl status logrotate.timer
○ logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; preset: enabled)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

■「logrotate.service」のサービスの状態を確認の結果

[root@Toshinobu-PC ~]# systemctl status logrotate.service
○ logrotate.service - Rotate log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static)
     Active: inactive (dead)
TriggeredBy: ○ logrotate.timer
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

⇧ 気になるのは、「Active: inactive (dead)」になってるのは問題ないのか?

ネットの情報を漁っていた感じでは、

serverfault.com

⇧ 上記サイト様によりますと、

  1. logrotate.timer
    「Active: inactive (dead)」はNG
  2. logrotate.service
    「Active: inactive (dead)」でもOK

ってことなんかね?

そもそも、「logrotate.timer」と「logrotate.service」の役割とかが分からんのだけど、

cloud5.jp

つまり、.timerユニットでタイミングを設定して、.serviceユニットで何を実行するのかを指定しているというわけですね。

RHEL9ではlogrotateがanacronではなくsystemdのtimer unitで制御されている話。 - 協栄情報ブログ

⇧ 上記サイト様によりますと、

No ファイル 内容
1 logrotate.timer 実行タイミングをスケジュールを設定。
2 logrotate.service 実際に、各「ログローテーション」を実行する設定。

⇧ ということらしい。

RHEL 9(Red Hat Enterprise Linux 9)」のドキュメントによると、

docs.redhat.com

複数の systemctl コマンドがバックグラウンドでユニットファイルと連携します。より細かく調整するには、ユニットファイルを手動で編集または作成します。

https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/9/html/using_systemd_unit_files_to_customize_and_optimize_your_system/assembly_working-with-systemd-unit-files_working-with-systemd#assembly_working-with-systemd-unit-files_working-with-systemd

システムにユニットファイルが保存される 3 つのメインディレクトリーが存在します。/etc/systemd/system/ ディレクトリーは、システム管理者が作成またはカスタマイズするユニットファイル用に予約されます。

https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/9/html/using_systemd_unit_files_to_customize_and_optimize_your_system/assembly_working-with-systemd-unit-files_working-with-systemd#assembly_working-with-systemd-unit-files_working-with-systemd

⇧「ユニットファイル」というものが用意されているらしく、

  1. logrotate.timer
  2. logrotate.service

は、「ユニットファイル」に該当するということらしい。

で、「ユニットファイル」の配置場所はというと、

docs.redhat.com

⇧ 上記のようになっていると。

No 配置場所 優先順位 説明
1 /usr/lib/systemd/system/ 3 インストール済みの RPM パッケージで配布された systemd のユニットファイル。
2 /run/systemd/system/ 2 ランタイム時に作成された systemd ユニットファイル。このディレクトリーは、インストール済みのサービスのユニットファイルのディレクトリーよりも優先されます。
3 /etc/systemd/system/ 1 systemctl enable コマンドを使用して作成された systemd ユニットファイルと、サービスを拡張するために追加されたユニットファイル。このディレクトリーは、runtime のユニットファイルのディレクトリーよりも優先されます。

⇧ インストール直後の状態が「/usr/lib/systemd/system/[ユニットファイル]」ということになると。

「logrotate」をインストール後に何をすれば良いのか

ここまでの情報を整理すると、

  1. ユニットファイルを複製する
    ※以下を「/etc/systemd/system/」配下にコピーする
    • /usr/lib/systemd/system/logrotate.timer
    • /usr/lib/systemd/system/logrotate.service
  2. /etc/systemd/system/logrotate.timerを編集する
    ※タイミングを設定する
  3. /etc/logrotate.d ディレクトリ配下に設定ファイルを追加
  4. logrotate.timerをサービス起動する

といった感じですかね。

順を追って、進めてみますか。

●1. ユニットファイルを複製する

「ユニットファイル」の適応される優先順位があるらしいので、最も優先順位の高いとされている「/etc/systemd/system/」ディレクトリに、インストール直後に「/usr/lib/systemd/system/」ディレクトリに配置されている「ユニットファイル」の複製を配置する。

「/usr/lib/systemd/system/」ディレクトリに配置されている「ユニットファイル」はバックアップ扱いって感じになるんかね?

●2. etc/systemd/system/logrotate.timerを編集する

デフォルトだと、1日おきに「ログローテーション」するスケジュールになってしまっているので、変更します。

■「/etc/systemd/system」ディレクトリに移動

cd /etc/systemd/system

■viで「logrotate.timer」ファイルを編集する

vi logrotate.timer

最小時間は、1時間毎らしいので「[Timer]」の「セクション」の「OnCalendar」の値を「hourly」にします。

■/etc/systemd/system/logrotate.timer

[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=hourly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

■変更前

■変更後

●3. /etc/logrotate.d ディレクトリ配下に設定ファイルを追加

実際に、「/etc/systemd/system/logrotate.service」の実行時に、「ログローテーション」の設定ファイルを「/etc/logrotate.d」ディレクトリ配下に作成する。

今回は、

ts0818.hatenablog.com

⇧ 前にインストールしていた「Oxidized」のログに対する「ログローテーション」の設定ファイルを追加することにします。

Dockerコンテナで稼働しているアプリケーションのログに対する「ログローテーション」を検証したいので、「Oxidzed」でなくてもOK。

とりあえず、「logrotae」の設定については、

github.com

⇧「Oxidized」の公式のサンプルだと、案の定というか、動作しなかったので、手を加える。「Oxidized」はドキュメントも適当だし、動かないコードも平気で掲載してるしで、なかなかに酷過ぎるんよね...

■「/etc/logroate.d」ディレクトリに移動

cd /etc/logroate.d

■viで「oxidized」ファイルを作成・編集する

vi oxidized

■/etc/logrotate.d/oxidized

/var/log/oxidized/*.log {
    hourly
    rotate 3
    size 1M
    compress
    delaycompress
    missingok
    postrotate
      docker-compose -f /home/ts0818/work/app/docker-compose.yml exec oxidized bash -c 'ps -u 30000 -o pid= | xargs -r kill -9' 
    endscript
}

⇧ かなり、無理やり感がありますが、「ログローテーション」されたタイミングで、「Oxidized」のDockerコンテナにログインして、「Oxidized」のプロセスを「kill -9 [PID]」してます。

「Runit」の影響なのか、killすると直ぐに「Oxidized」の新しいプロセスが生成されるので、「kill -9 [PID]」した後に「/usr/bin/ruby3.2 /usr/local/bundle/bin/oxidized」の実行は不要。

2024年10月29日(火)追記:↓ ここから

職場の方に連携いただき、docker-compose exec のオプションで「-T」を付与してみる知見を得たので試してみることに。

docs.docker.jp

⇧『擬似 TTY への割り当てを無効化。 デフォルトでは `docker-compose exec` には TTY が割り当て』とありますと。

そも、「TTY」とは?

ttyとは、標準入力となっている端末デバイス(制御端末、controlling terminal)ファイルのパス名を表示するUnix系コマンドである。元来ttyとはteletypewriter(テレタイプライター)のことを指す。

tty - Wikipedia

例えば、SSH などを経由し、Unix98 PTY の擬似端末に接続している状況で tty を実行すると、以下のような表示が返される。

tty - Wikipedia

⇧ うむ、全く分からん。

ChatGPTに質問してみた。

No 特徴 TTY 有効 TTY 無効
1 インタラクティブ入力 対話的な入力が可能 制限されることがある
2 出力のフォーマット 色付き出力やエスケープシーケンスが有効 出力がプレーンになる
3 プロンプト表示 対話的なプロンプトが表示される プロンプトが表示されない場合がある
4 シグナル処理 通常のシグナル(Ctrl+Cなど)が機能する シグナル処理が異なる場合がある
5 プログラムの動作 TTY特有の機能を利用するプログラムが正常に動作 エラーを出すことがある
6 出力のバッファリング バッファリングの挙動が通常 バッファリングが異なる場合がある
7 入力待機の挙動 入力を待機し、プロンプトを表示 待機せず次のステップに進むことがある

⇧ 上記のような回答が返ってきたのだけど、うむ、全く分からん。

ネットの情報を漁っていたところ、

zenn.dev

また、cronではTTYがないので、docker compose execコマンドには-Tをつけて擬似端末をオフにしたほうがいいでしょう。

Docker Composeにおけるログのローテート

serverfault.com

⇧ なるほど、そもそも、「logrotate」に「TTY」が無いらしい。

■全てのプロセスを確認

[root@Toshinobu-PC ~]# ps -A
  PID TTY          TIME CMD
    1 ?        00:00:00 systemd
    2 ?        00:00:00 init-systemd(Ro
    7 ?        00:00:00 init
   34 ?        00:00:00 systemd-journal
   48 ?        00:00:00 sshd
   49 ?        00:00:00 systemd-logind
   55 ?        00:00:04 containerd
   56 hvc0     00:00:00 agetty
   60 tty1     00:00:00 agetty
   85 ?        00:00:00 dbus-broker-lau
   86 ?        00:00:01 postmaster
   87 ?        00:00:00 dbus-broker
   96 ?        00:00:00 postmaster
   97 ?        00:00:00 postmaster
   98 ?        00:00:00 postmaster
  111 ?        00:00:02 dockerd
  211 ?        00:00:00 postmaster
  212 ?        00:00:00 postmaster
  213 ?        00:00:00 postmaster
  214 ?        00:00:00 postmaster
  215 ?        00:00:00 postmaster
  216 ?        00:00:00 postmaster
  361 ?        00:00:00 SessionLeader
  362 ?        00:00:00 Relay(363)
  363 pts/0    00:00:00 bash
  364 ?        00:00:00 login
  370 ?        00:00:00 systemd
  371 ?        00:00:00 (sd-pam)
  380 pts/1    00:00:00 bash
  410 ?        00:00:00 sshd
  412 ?        00:00:00 sshd
  413 ?        00:00:00 sftp-server
  431 ?        00:00:00 sshd
  434 ?        00:00:00 sshd
  435 pts/2    00:00:00 bash
  465 ?        00:00:00 sshd
  468 ?        00:00:00 sshd
  469 ?        00:00:00 sftp-server
  563 ?        00:00:00 docker-proxy
  569 ?        00:00:00 docker-proxy
  594 ?        00:00:00 containerd-shim
  614 ?        00:00:00 my_init
  657 ?        00:00:00 syslog-ng
  667 ?        00:00:00 runsvdir
  668 ?        00:00:00 runsv
  669 ?        00:00:00 runsv
  670 ?        00:00:00 runsv
  671 ?        00:00:00 runsv
  672 ?        00:00:00 runsv
  674 ?        00:00:00 cron
  675 ?        00:00:00 run
  676 ?        00:00:00 run
  680 ?        00:00:00 sleep
  686 ?        00:00:00 sshd
  689 ?        00:00:00 sshd
  690 pts/3    00:00:00 bash
  725 ?        00:00:00 sshd
  727 ?        00:00:00 sshd
  728 ?        00:00:00 sftp-server
 1785 ?        00:00:02 oxidized
 1869 ?        00:00:00 sleep
 1971 pts/3    00:00:00 ps

■全てのプロセスを確認

[root@Toshinobu-PC ~]# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3 169004 12452 ?        Ss   17:55   0:00 /sbin/init
root         2  0.0  0.0   2616  1444 ?        Sl   17:55   0:00 /init
root         7  0.0  0.0   2616  1096 ?        Sl   17:55   0:00 plan9 --contr
root        34  0.0  0.2  26692  9588 ?        Ss   17:55   0:00 /usr/lib/syst
root        48  0.0  0.2  15800  9328 ?        Ss   17:55   0:00 sshd: /usr/sb
root        49  0.0  0.2  19092  8996 ?        Ss   17:55   0:00 /usr/lib/syst
root        55  0.0  1.2 2170788 51476 ?       Ssl  17:55   0:04 /usr/bin/cont
root        56  0.0  0.0   3064  1048 hvc0     Ss+  17:55   0:00 /sbin/agetty
root        60  0.0  0.0   3020  1060 tty1     Ss+  17:55   0:00 /sbin/agetty
dbus        85  0.0  0.1  10824  4536 ?        Ss   17:55   0:00 /usr/bin/dbus
postgres    86  0.0  1.3 1114604 54616 ?       Ss   17:55   0:01 /usr/pgsql-15
dbus        87  0.0  0.0   4984  2580 ?        S    17:55   0:00 dbus-broker -
postgres    96  0.0  0.1  63048  5620 ?        Ss   17:55   0:00 postgres: log
postgres    97  0.0  0.3 1114732 15256 ?       Ss   17:55   0:00 postgres: che
postgres    98  0.0  0.3 1114740 13104 ?       Ss   17:55   0:00 postgres: bac
root       111  0.0  2.2 2367816 90696 ?       Ssl  17:55   0:02 /usr/bin/dock
postgres   211  0.0  0.5 1114604 23072 ?       Ss   17:55   0:00 postgres: wal
postgres   212  0.0  0.2 1116208 8676 ?        Ss   17:55   0:00 postgres: aut
postgres   213  0.0  0.2 1116184 8472 ?        Ss   17:55   0:00 postgres: Tim
postgres   214  0.0  0.1 1116168 6652 ?        Ss   17:55   0:00 postgres: log
postgres   215  0.0  0.4 1118492 18944 ?       Ss   17:55   0:00 postgres: Tim
postgres   216  0.0  0.4 1118488 19124 ?       Ss   17:55   0:00 postgres: Tim
root       361  0.0  0.0   2648   124 ?        Ss   17:55   0:00 /init
root       362  0.0  0.0   2648   136 ?        S    17:55   0:00 /init
root       363  0.0  0.0   4948  3968 pts/0    Ss+  17:55   0:00 -bash
root       364  0.0  0.1  12912  6084 ?        Ss   17:55   0:00 login -- root
root       370  0.0  0.2  20736 11208 ?        Ss   17:55   0:00 /usr/lib/syst
root       371  0.0  0.0 170408  2672 ?        S    17:55   0:00 (sd-pam)
root       380  0.0  0.0   4964  3992 pts/1    Ss+  17:55   0:00 -bash
root       410  0.0  0.2  19156 11568 ?        Ss   17:55   0:00 sshd: root [p
root       412  0.0  0.1  19156  6720 ?        S    17:55   0:00 sshd: root@no
root       413  0.0  0.1   8404  5324 ?        Ss   17:55   0:00 /usr/libexec/
root       431  0.0  0.2  19152 11480 ?        Ss   17:55   0:00 sshd: root [p
root       434  0.0  0.1  19152  6300 ?        S    17:55   0:00 sshd: root@pt
root       435  0.0  0.0   4972  3904 pts/2    Ss+  17:55   0:00 -bash
root       465  0.0  0.2  19156 11520 ?        Ss   17:56   0:00 sshd: root [p
root       468  0.0  0.1  19156  6688 ?        S    17:56   0:00 sshd: root@no
root       469  0.0  0.1   8404  5460 ?        Ss   17:56   0:00 /usr/libexec/
root       563  0.0  0.1 1745804 7008 ?        Sl   17:57   0:00 /usr/bin/dock
root       569  0.0  0.1 1819792 7172 ?        Sl   17:57   0:00 /usr/bin/dock
root       594  0.0  0.3 1238704 14288 ?       Sl   17:57   0:00 /usr/bin/cont
root       614  0.0  0.3  23448 13492 ?        Ss   17:57   0:00 /usr/bin/pyth
root       657  0.0  0.2 386152 10172 ?        Sl   17:57   0:00 /usr/sbin/sys
root       667  0.0  0.0   2712  1152 ?        S    17:57   0:00 /usr/bin/runs
root       668  0.0  0.0   2564  1184 ?        Ss   17:57   0:00 runsv cron
root       669  0.0  0.0   2564  1108 ?        Ss   17:57   0:00 runsv sshd
root       670  0.0  0.0   2564  1168 ?        Ss   17:57   0:00 runsv update-
root       671  0.0  0.0   2564  1136 ?        Ss   17:57   0:00 runsv auto-re
root       672  0.0  0.0   2564  1176 ?        Ss   17:57   0:00 runsv oxidize
root       674  0.0  0.0   9720  2796 ?        S    17:57   0:00 /usr/sbin/cro
root       675  0.0  0.0  10264  3588 ?        S    17:57   0:00 /bin/bash ./r
root       676  0.0  0.0  10264  3772 ?        S    17:57   0:00 /bin/bash ./r
root       680  0.0  0.0   8612  1004 ?        S    17:57   0:00 sleep infinit
root       686  0.0  0.2  19156 11392 ?        Ss   17:57   0:00 sshd: root [p
root       689  0.0  0.1  19156  6644 ?        R    17:57   0:00 sshd: root@pt
root       690  0.0  0.1   4972  4068 pts/3    Ss   17:57   0:00 -bash
root       725  0.0  0.2  19152 11344 ?        Ss   17:58   0:00 sshd: root [p
root       727  0.0  0.1  19152  6564 ?        S    17:58   0:00 sshd: root@no
root       728  0.0  0.1  11656  6736 ?        Ss   17:58   0:00 /usr/libexec/
30000     1785  0.2  1.0 255344 42868 ?        Sl   19:00   0:02 /usr/bin/ruby
root      2003  0.0  0.0   8612  1104 ?        S    19:17   0:00 sleep 600
root      2046  0.0  0.1  15872  6144 pts/3    R+   19:20   0:00 ps aux    

■全てのプロセスを確認

[root@Toshinobu-PC ~]# ps -aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3 169004 12452 ?        Ss   17:55   0:00 /sbin/init
root         2  0.0  0.0   2616  1444 ?        Sl   17:55   0:00 /init
root         7  0.0  0.0   2616  1096 ?        Sl   17:55   0:00 plan9 --contr
root        34  0.0  0.2  26692  9588 ?        Ss   17:55   0:00 /usr/lib/syst
root        48  0.0  0.2  15800  9328 ?        Ss   17:55   0:00 sshd: /usr/sb
root        49  0.0  0.2  19092  8996 ?        Ss   17:55   0:00 /usr/lib/syst
root        55  0.0  1.2 2170788 51476 ?       Ssl  17:55   0:04 /usr/bin/cont
root        56  0.0  0.0   3064  1048 hvc0     Ss+  17:55   0:00 /sbin/agetty
root        60  0.0  0.0   3020  1060 tty1     Ss+  17:55   0:00 /sbin/agetty
dbus        85  0.0  0.1  10824  4536 ?        Ss   17:55   0:00 /usr/bin/dbus
postgres    86  0.0  1.3 1114604 54616 ?       Ss   17:55   0:01 /usr/pgsql-15
dbus        87  0.0  0.0   4984  2580 ?        S    17:55   0:00 dbus-broker -
postgres    96  0.0  0.1  63048  5620 ?        Ss   17:55   0:00 postgres: log
postgres    97  0.0  0.3 1114732 15256 ?       Ss   17:55   0:00 postgres: che
postgres    98  0.0  0.3 1114740 13104 ?       Ss   17:55   0:00 postgres: bac
root       111  0.0  2.2 2367816 90696 ?       Ssl  17:55   0:02 /usr/bin/dock
postgres   211  0.0  0.5 1114604 23072 ?       Ss   17:55   0:00 postgres: wal
postgres   212  0.0  0.2 1116208 8676 ?        Ss   17:55   0:00 postgres: aut
postgres   213  0.0  0.2 1116184 8472 ?        Ss   17:55   0:00 postgres: Tim
postgres   214  0.0  0.1 1116168 6652 ?        Ss   17:55   0:00 postgres: log
postgres   215  0.0  0.4 1118492 18944 ?       Ss   17:55   0:00 postgres: Tim
postgres   216  0.0  0.4 1118488 19124 ?       Ss   17:55   0:00 postgres: Tim
root       361  0.0  0.0   2648   124 ?        Ss   17:55   0:00 /init
root       362  0.0  0.0   2648   136 ?        S    17:55   0:00 /init
root       363  0.0  0.0   4948  3968 pts/0    Ss+  17:55   0:00 -bash
root       364  0.0  0.1  12912  6084 ?        Ss   17:55   0:00 login -- root
root       370  0.0  0.2  20736 11208 ?        Ss   17:55   0:00 /usr/lib/syst
root       371  0.0  0.0 170408  2672 ?        S    17:55   0:00 (sd-pam)
root       380  0.0  0.0   4964  3992 pts/1    Ss+  17:55   0:00 -bash
root       410  0.0  0.2  19156 11568 ?        Ss   17:55   0:00 sshd: root [p
root       412  0.0  0.1  19156  6720 ?        S    17:55   0:00 sshd: root@no
root       413  0.0  0.1   8404  5324 ?        Ss   17:55   0:00 /usr/libexec/
root       431  0.0  0.2  19152 11480 ?        Ss   17:55   0:00 sshd: root [p
root       434  0.0  0.1  19152  6300 ?        S    17:55   0:00 sshd: root@pt
root       435  0.0  0.0   4972  3904 pts/2    Ss+  17:55   0:00 -bash
root       465  0.0  0.2  19156 11520 ?        Ss   17:56   0:00 sshd: root [p
root       468  0.0  0.1  19156  6688 ?        S    17:56   0:00 sshd: root@no
root       469  0.0  0.1   8404  5460 ?        Ss   17:56   0:00 /usr/libexec/
root       563  0.0  0.1 1745804 7008 ?        Sl   17:57   0:00 /usr/bin/dock
root       569  0.0  0.1 1819792 7172 ?        Sl   17:57   0:00 /usr/bin/dock
root       594  0.0  0.3 1238704 14288 ?       Sl   17:57   0:00 /usr/bin/cont
root       614  0.0  0.3  23448 13492 ?        Ss   17:57   0:00 /usr/bin/pyth
root       657  0.0  0.2 386152 10172 ?        Sl   17:57   0:00 /usr/sbin/sys
root       667  0.0  0.0   2712  1152 ?        S    17:57   0:00 /usr/bin/runs
root       668  0.0  0.0   2564  1184 ?        Ss   17:57   0:00 runsv cron
root       669  0.0  0.0   2564  1108 ?        Ss   17:57   0:00 runsv sshd
root       670  0.0  0.0   2564  1168 ?        Ss   17:57   0:00 runsv update-
root       671  0.0  0.0   2564  1136 ?        Ss   17:57   0:00 runsv auto-re
root       672  0.0  0.0   2564  1176 ?        Ss   17:57   0:00 runsv oxidize
root       674  0.0  0.0   9720  2796 ?        S    17:57   0:00 /usr/sbin/cro
root       675  0.0  0.0  10264  3588 ?        S    17:57   0:00 /bin/bash ./r
root       676  0.0  0.0  10264  3772 ?        S    17:57   0:00 /bin/bash ./r
root       680  0.0  0.0   8612  1004 ?        S    17:57   0:00 sleep infinit
root       686  0.0  0.2  19156 11392 ?        Ss   17:57   0:00 sshd: root [p
root       689  0.0  0.1  19156  6644 ?        R    17:57   0:00 sshd: root@pt
root       690  0.0  0.1   4972  4068 pts/3    Ss   17:57   0:00 -bash
root       725  0.0  0.2  19152 11344 ?        Ss   17:58   0:00 sshd: root [p
root       727  0.0  0.1  19152  6564 ?        S    17:58   0:00 sshd: root@no
root       728  0.0  0.1  11656  6736 ?        Ss   17:58   0:00 /usr/libexec/
30000     1785  0.2  1.0 255344 42088 ?        Sl   19:00   0:02 /usr/bin/ruby
root      2003  0.0  0.0   8612  1104 ?        S    19:17   0:00 sleep 600
root      2068  0.0  0.1  16000  5988 pts/3    R+   19:22   0:00 ps -aux

■全てのプロセスを確認

[root@Toshinobu-PC ~]# ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3 169004 12452 ?        Ss   17:55   0:00 /sbin/init
root         2  0.0  0.0   2616  1444 ?        Sl   17:55   0:00 /init
root         7  0.0  0.0   2616  1096 ?        Sl   17:55   0:00  \_ plan9 --c
root       361  0.0  0.0   2648   124 ?        Ss   17:55   0:00  \_ /init
root       362  0.0  0.0   2648   136 ?        S    17:55   0:00  |   \_ /init
root       363  0.0  0.0   4948  3968 pts/0    Ss+  17:55   0:00  |       \_ -
root       364  0.0  0.1  12912  6084 ?        Ss   17:55   0:00  \_ login --
root       380  0.0  0.0   4964  3992 pts/1    Ss+  17:55   0:00      \_ -bash
root        34  0.0  0.2  26692  9588 ?        Ss   17:55   0:00 /usr/lib/syst
root        48  0.0  0.2  15800  9328 ?        Ss   17:55   0:00 sshd: /usr/sb
root       410  0.0  0.2  19156 11568 ?        Ss   17:55   0:00  \_ sshd: roo
root       412  0.0  0.1  19156  6720 ?        S    17:55   0:00  |   \_ sshd:
root       413  0.0  0.1   8404  5324 ?        Ss   17:55   0:00  |       \_ /
root       431  0.0  0.2  19152 11480 ?        Ss   17:55   0:00  \_ sshd: roo
root       434  0.0  0.1  19152  6300 ?        S    17:55   0:00  |   \_ sshd:
root       435  0.0  0.0   4972  3904 pts/2    Ss+  17:55   0:00  |       \_ -
root       465  0.0  0.2  19156 11520 ?        Ss   17:56   0:00  \_ sshd: roo
root       468  0.0  0.1  19156  6688 ?        S    17:56   0:00  |   \_ sshd:
root       469  0.0  0.1   8404  5460 ?        Ss   17:56   0:00  |       \_ /
root       686  0.0  0.2  19156 11392 ?        Ss   17:57   0:00  \_ sshd: roo
root       689  0.0  0.1  19156  6644 ?        S    17:57   0:00  |   \_ sshd:
root       690  0.0  0.1   4972  4068 pts/3    Ss   17:57   0:00  |       \_ -
root      2113  0.0  0.1  16032  6196 pts/3    R+   19:26   0:00  |          p
root       725  0.0  0.2  19152 11344 ?        Ss   17:58   0:00  \_ sshd: roo
root       727  0.0  0.1  19152  6564 ?        S    17:58   0:00      \_ sshd:
root       728  0.0  0.1  11656  6736 ?        Ss   17:58   0:00          \_ /
root        49  0.0  0.2  19092  8996 ?        Ss   17:55   0:00 /usr/lib/syst
root        55  0.0  1.2 2170788 51476 ?       Ssl  17:55   0:05 /usr/bin/cont
root        56  0.0  0.0   3064  1048 hvc0     Ss+  17:55   0:00 /sbin/agetty
root        60  0.0  0.0   3020  1060 tty1     Ss+  17:55   0:00 /sbin/agetty
dbus        85  0.0  0.1  10824  4536 ?        Ss   17:55   0:00 /usr/bin/dbus
dbus        87  0.0  0.0   4984  2580 ?        S    17:55   0:00  \_ dbus-brok
postgres    86  0.0  1.3 1114604 54616 ?       Ss   17:55   0:01 /usr/pgsql-15
postgres    96  0.0  0.1  63048  5620 ?        Ss   17:55   0:00  \_ postgres:
postgres    97  0.0  0.3 1114732 15256 ?       Ss   17:55   0:00  \_ postgres:
postgres    98  0.0  0.3 1114740 13104 ?       Ss   17:55   0:00  \_ postgres:
postgres   211  0.0  0.5 1114604 23072 ?       Ss   17:55   0:00  \_ postgres:
postgres   212  0.0  0.2 1116208 8676 ?        Ss   17:55   0:00  \_ postgres:
postgres   213  0.0  0.2 1116184 8472 ?        Ss   17:55   0:00  \_ postgres:
postgres   214  0.0  0.1 1116168 6652 ?        Ss   17:55   0:00  \_ postgres:
postgres   215  0.0  0.4 1118492 18944 ?       Ss   17:55   0:00  \_ postgres:
postgres   216  0.0  0.4 1118488 19124 ?       Ss   17:55   0:00  \_ postgres:
root       111  0.0  2.2 2367816 90696 ?       Ssl  17:55   0:02 /usr/bin/dock
root       563  0.0  0.1 1745804 7008 ?        Sl   17:57   0:00  \_ /usr/bin/
root       569  0.0  0.1 1819792 7172 ?        Sl   17:57   0:00  \_ /usr/bin/
root       370  0.0  0.2  20736 11208 ?        Ss   17:55   0:00 /usr/lib/syst
root       371  0.0  0.0 170408  2672 ?        S    17:55   0:00  \_ (sd-pam)
root       594  0.0  0.3 1238704 14192 ?       Sl   17:57   0:00 /usr/bin/cont
root       614  0.0  0.3  23448 13492 ?        Ss   17:57   0:00  \_ /usr/bin/
root       657  0.0  0.2 386152 10172 ?        Sl   17:57   0:00      \_ /usr/
root       667  0.0  0.0   2712  1152 ?        S    17:57   0:00      \_ /usr/
root       668  0.0  0.0   2564  1184 ?        Ss   17:57   0:00          \_ r
root       674  0.0  0.0   9720  2796 ?        S    17:57   0:00          |  /
root       669  0.0  0.0   2564  1108 ?        Ss   17:57   0:00          \_ r
root       670  0.0  0.0   2564  1168 ?        Ss   17:57   0:00          \_ r
root       675  0.0  0.0  10264  3588 ?        S    17:57   0:00          |  /
root       680  0.0  0.0   8612  1004 ?        S    17:57   0:00          |  s
root       671  0.0  0.0   2564  1136 ?        Ss   17:57   0:00          \_ r
root       676  0.0  0.0  10264  3772 ?        S    17:57   0:00          |  /
root      2003  0.0  0.0   8612  1104 ?        S    19:17   0:00          |  s
root       672  0.0  0.0   2564  1176 ?        Ss   17:57   0:00          \_ r
30000     1785  0.1  1.0 255344 42088 ?        Sl   19:00   0:02             /    

⇧ 「?」のものが「TTY」が無いということで良いんだろうか?

「logrotate」がタイマー起動なのが影響しているのか、プロセスに見当たらない...

結局、TTYの利用有無の確認方法が分からん...

「logrotate」の「Oxidized」用の設定を以下のようにする必要がありますと。

■/etc/logrotate.d/oxidized

/var/log/oxidized/*.log {
    hourly
    rotate 3
    maxsize 10K
    dateformat -%Y%m%d-%s
    compress
    delaycompress
    missingok
    postrotate
      docker-compose -f /home/ts0818/work/app/docker-compose.yml exec -T oxidized bash -c 'ps -u 30000 -o pid= | xargs -r kill -9;exit' 
    endscript
}

⇧ というような感じにして保存。

Docker Composeで「Oxidized」を起動します。

で、1時間後、無事に、切り替わりましたと。

ただ、「Oxidized」のプロセスを再起動して欲しく無いので、このアプローチは使えないとなりました。

「ファイルディスクリプター」を新しい方に切り替えて欲しいだけなんだけど、稼働している「アプリケーション」のプロセスの再起動なしに実現する方法が分からんのよな...

2024年10月29日(火)追記:↑ ここまで

2024年10月30日(水)追記:↓ ここから

職場の方に連携いただき、プロセスをkillしなくても良い方法を連携いただいたので備忘録として。

qiita.com

copytruncateはファイル名を変更せずに、新しいファイルを作成し、そこにまるごとコピーし、元のファイルを切り詰めるオプションだ。
つまり書き込み先のinodeの変更が発生しない。

logrotateでログが欠損するケースとその対策 #logrotate - Qiita

⇧ 上記サイト様にありますように、「copytruncate」オプションを設定してあげれば良い模様。

■/etc/logrotate.d/oxidized

/var/log/oxidized/*.log {
    hourly
    rotate 3
    maxsize 10K
    dateformat -%Y%m%d-%s
    compress
    delaycompress
    missingok
    copytruncate
}

⇧ というような感じにして保存。

2024年10月30日(水)追記:↑ ここまで

「Oxidized」はDocker Composeで稼働させているアプリケーションなので、ログの出力先のディレクトリをマウントしておく。

まずは、「Oxidized」のconfigのファイルを編集する。

■「Oxidized」の「config」ファイルの配置ディレクトリに移動

cd [「Oxidized」の「config」ファイルの配置ディレクトリ]

■viで「oxidized」の「config」ファイルを編集する

vi config

「log」の設定項目を追加しておく。

続いて、「docker-compose.yml」で「ホスト」側のディレクトリとDockerコンテナ側のディレクトリとをマウントする設定を追加しておく。

■「docker-compose.yml」ファイルの配置ディレクトリに移動

cd [「docker-compose.yml」ファイルの配置ディレクトリ]

■viで「docker-compose.yml」ファイルを編集する

vi docker-compose.yml

ログに付いて、「Oxidized」の公式サンプルに合わせたディレクトリにしてますが、「Oxidized」の公式サンプルが動作しなかったので、マウントするディレクトリはどこでも良さそう。(「ログローテーション」の時に、無理やり「kill -9 [PID]」するしかないので)

ログ用のマウントするためのホスト側のディレクトリを作成しておく。


●4. logrotate.timerをサービス起動する

そしたらば、

  1. systemctl deamon-reload
  2. systemctl restart logrotate.service
  3. systemctl start logrotate.timer
  4. Docker ComposeでDockerコンテナの生成・起動

の順番で実行する。

で、「ログローテーション」されたっぽい。

なんだけど、「/etc/logrotate.d/oxidized」の設定が悪いのか、

■強制的に「ログローテーション」を実行する

logrotate -f /etc/logrotate.conf

⇧ を実行すると、エラーが出るんよね...

まぁ、ログの書き込みはされ続けているので問題ないんかな?

結局、Dockerコンテナで稼働しているアプリケーションの「ログローテーション」は、どうするのが正解なのかね?

今回も、否応なく不毛な時間を費やされて、ストレスと疲労困憊で疲弊しただけでしたな...

毎度モヤモヤ感が半端ない…

今回はこのへんで。