米Alphabet傘下の自動運転企業Waymoは10月25日(現地時間)、シリーズCラウンドで56億ドルを調達したと発表した。Alphabetが主導し、これまでのラウンドに続けてAndreessen Horowitz、Fidelity、Perry Creek、Silver Lake、Tiger Global、T. Rowe Priceが参加した。Waymoの資金調達はこれで3回目。累計で110億ドル以上となった。
⇧ 金額がエグい。
By the way、
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
⇧ 取締役会の評価の意味が分からん...
過去にも、
ナデラ氏はMicrosoftの取締役でもあるHarvey Mudd College校長マリア・クロウェイ氏と登壇した。講演の終わりに、クロウェイ氏が昇給を願い出ることをためらっている女性技術者に対してアドバイスを、と促したところ、「給料アップを頼むのではなく、組織が適正な昇給をすると信じることだ」とし、「昇給を求めない女性は良いカルマ(サンスクリット語で「結果を伴う行為」の意)を持ち、良い結果を得られるだろう」と語った。同氏はインド出身だ。
⇧ とか有り得ない言動してますが、自分の利益のことしか考えない「サイコパス」野郎なのかしら?
とりあえず、2023年の話ではあるけども、
同社のサティア・ナデラ最高経営責任者(CEO)は5月10日、2023年の昇給(社内では成果による昇給を意味する「メリット・インクリース」の言葉が使われる)を凍結し、賞与と株式報酬に充てる原資を圧縮して過去の平均水準に戻すことを明らかにした。
「マイクロソフトはひどい職場」「CEO報酬は一般社員の289倍」昇給凍結発表後、社内で経営批判殺到 | Business Insider Japan
マイクロソフトは1月に1万人の従業員をレイオフすると発表。その後、2023年の昇給のほとんどを停止し、賞与と株式報酬を減らすことも発表している。
マイクロソフトのナデラCEO、期末を迎え従業員に謝意を贈るも「感謝しているなら昇給凍結の解除を」 | Business Insider Japan
⇧ 上記のようなことしているってことは、取締役会のメンバーは自分たちが不利益を被らないように、ナデラへの評価は忖度されたものになっているってことなんかね?
ほぼ、独裁政治のような状況になっていそうですな...
「マイクロソフトの職場文化に前向きな変化が見られる」と肯定的に回答した従業員の割合は、1月の62%から7月には月平均40%にまで低下した。
マイクロソフトの士気が低下している…社内意識調査で企業文化や経営陣への評価が悪化 | Business Insider Japan
⇧ 2023年がこういう状況であったにもかかわらず、2024年度は、
『報酬は前年比で63%増の7910万ドル(約120億円)に増額』
って、2023年度の時点でも過大評価にも程がある気がするんだが...
何と言うか、従業員のモチベーション上がるわけないよね...
Red Hat系のディストリビューションのバージョン9系でlogrotateの仕様が変わったらしいが
前回、
⇧「Oxidized」の「ログローテーション」をどうするかの話で、
⇧ 上記サイト様によると、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」で「ログローテーション」したいのだけど、
⇧「アクセス権限」の問題が起こりますと。
で、ネットの情報を漁って見た感じ、
⇧ 上記サイト様によりますと、「ホスト」側の「logrotate」が厳しそう...
「ホスト」側の「logrotate」が「Docker」のボリュームのマウントを解釈できないらしく、「コンテナ」側の「uid」「gid」を認識してくれないらしい...
そもそも、「Docker」の「コンテナ」で稼働しているアプリケーションのログを「ログローテーション」するアプローチとしては、
- 「ホスト」側の「logrotate」で行う
- 「Docker」の「コンテナ」側の「logrotate」で行う
のどちらが、メジャーなんだろうか?
「AWS(Amazon Web Services)」の公開している情報だと、
⇧ わざわざ、「logrotate」用の「Docker」の「コンテナ」を用意している。
なるほど、「AKS(Amazon Elastic Kubernetes Service)」のような「オーケストレーション」ツールを利用しているような環境においては、「Pod」毎に管理できるから、「コンテナ」を作ってしまった方が良いってことみたいね。
「オーケストレーション」ツールの魁「Kubernetes」のドキュメントによると、
⇧「logrotate」は「kubelet」が管理するという説明なのだけど、
⇧とあるので、「logrotate」も「コンテナ」で稼働してるということですかね。
何と言うか、「ホスト」側の「logrotate」を利用した事例が出て来ないということは、「コンテナ」で「logrotate」を稼働させて「ログローテーション」しろってことなんですかね。
後は、
⇧「ログローテーション」時に、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ホスト」というのは、
Docker のアーキテクチャとは?
Docker はクライアント・サーバ型のアーキテクチャです。Docker クライアント が Docker コンテナの構築・実行・配布といった力仕事をするには、 Docker デーモン と通信します。 Docker クライアントとデーモンは、どちらも同じシステム上でも実行できます。あるいは、Docker クライアントはリモートの Docker デーモンに接続するのも可能です。Docker クライアントとデーモンは、お互いにソケットもしくは RESTful API を経由して通信します。
https://docs.docker.jp/v1.11/engine/understanding-docker.html
⇧ 特に説明は無いのだけど、「Docker デーモン」が稼働している環境といった感じですかね?
「Dockerホスト」のややこしいところが、
⇧ 上記の図のように、「Docker」をインストールしてる環境によって立ち位置が変わってきますと。
今回の自分の環境は、上記の図で言うところの「Linux」となるイメージ。
「Windows」の方は、『ホスト(ややこしいが、ここのホストは「Dockerホスト」ではなく、通常のホスト)』側に「Docker クライアント」をインストールしてる感じ。
「Docker Desktop」については情報が見当たらず、どういう構成になってるのか分からないのだけど、「Docker Desktop」のような使い方ができるものとして登場した「Rancher Desktop」が公開している情報によると、
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.
⇧上図のような感じのアーキテクチャになっており、「k3s」という「Kubernetes」を軽量化した「オーケストレーション」ツールが含まれているのだけど、「containerd」というものが、
containerdとは何ですか?
要するに、containerdはコンテナを実行するために構築されたランタイムです。
containerdは、オペレーティングシステムと直接連携することで、コンテナの操作を容易にします。 Docker Engine は containerd の上にあり、追加の機能と開発者エクスペリエンスの強化を提供します。
⇧ とあるので、「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)」になってるのは問題ないのか?
ネットの情報を漁っていた感じでは、
⇧ 上記サイト様によりますと、
- logrotate.timer
「Active: inactive (dead)」はNG - logrotate.service
「Active: inactive (dead)」でもOK
ってことなんかね?
そもそも、「logrotate.timer」と「logrotate.service」の役割とかが分からんのだけど、
つまり、.timerユニットでタイミングを設定して、.serviceユニットで何を実行するのかを指定しているというわけですね。
RHEL9ではlogrotateがanacronではなくsystemdのtimer unitで制御されている話。 - 協栄情報ブログ
⇧ 上記サイト様によりますと、
No | ファイル | 内容 |
---|---|---|
1 | logrotate.timer | 実行タイミングをスケジュールを設定。 |
2 | logrotate.service | 実際に、各「ログローテーション」を実行する設定。 |
⇧ ということらしい。
「RHEL 9(Red Hat Enterprise Linux 9)」のドキュメントによると、
ユニットファイルには、ユニットを説明し、その動作を定義する設定ディレクティブが含まれます。
複数の systemctl
コマンドがバックグラウンドでユニットファイルと連携します。より細かく調整するには、ユニットファイルを手動で編集または作成します。
システムにユニットファイルが保存される 3 つのメインディレクトリーが存在します。/etc/systemd/system/
ディレクトリーは、システム管理者が作成またはカスタマイズするユニットファイル用に予約されます。
⇧「ユニットファイル」というものが用意されているらしく、
- logrotate.timer
- logrotate.service
は、「ユニットファイル」に該当するということらしい。
で、「ユニットファイル」の配置場所はというと、
⇧ 上記のようになっていると。
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」をインストール後に何をすれば良いのか
ここまでの情報を整理すると、
- ユニットファイルを複製する
※以下を「/etc/systemd/system/」配下にコピーする- /usr/lib/systemd/system/logrotate.timer
- /usr/lib/systemd/system/logrotate.service
- /etc/systemd/system/logrotate.timerを編集する
※タイミングを設定する - /etc/logrotate.d ディレクトリ配下に設定ファイルを追加
- 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」ディレクトリ配下に作成する。
今回は、
⇧ 前にインストールしていた「Oxidized」のログに対する「ログローテーション」の設定ファイルを追加することにします。
Dockerコンテナで稼働しているアプリケーションのログに対する「ログローテーション」を検証したいので、「Oxidzed」でなくてもOK。
とりあえず、「logrotae」の設定については、
⇧「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」を付与してみる知見を得たので試してみることに。
⇧『擬似 TTY への割り当てを無効化。 デフォルトでは `docker-compose exec` には TTY が割り当て』とありますと。
そも、「TTY」とは?
ttyとは、標準入力となっている端末デバイス(制御端末、controlling terminal)ファイルのパス名を表示するUnix系のコマンドである。元来ttyとはteletypewriter(テレタイプライター)のことを指す。
⇧ うむ、全く分からん。
ChatGPTに質問してみた。
No | 特徴 | TTY 有効 | TTY 無効 |
---|---|---|---|
1 | インタラクティブ入力 | 対話的な入力が可能 | 制限されることがある |
2 | 出力のフォーマット | 色付き出力やエスケープシーケンスが有効 | 出力がプレーンになる |
3 | プロンプト表示 | 対話的なプロンプトが表示される | プロンプトが表示されない場合がある |
4 | シグナル処理 | 通常のシグナル(Ctrl+Cなど)が機能する | シグナル処理が異なる場合がある |
5 | プログラムの動作 | TTY特有の機能を利用するプログラムが正常に動作 | エラーを出すことがある |
6 | 出力のバッファリング | バッファリングの挙動が通常 | バッファリングが異なる場合がある |
7 | 入力待機の挙動 | 入力を待機し、プロンプトを表示 | 待機せず次のステップに進むことがある |
⇧ 上記のような回答が返ってきたのだけど、うむ、全く分からん。
ネットの情報を漁っていたところ、
また、cronではTTYがないので、docker compose exec
コマンドには-T
をつけて擬似端末をオフにしたほうがいいでしょう。
⇧ なるほど、そもそも、「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しなくても良い方法を連携いただいたので備忘録として。
copytruncate
はファイル名を変更せずに、新しいファイルを作成し、そこにまるごとコピーし、元のファイルを切り詰めるオプションだ。
つまり書き込み先のinodeの変更が発生しない。
⇧ 上記サイト様にありますように、「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をサービス起動する
そしたらば、
- systemctl deamon-reload
- systemctl restart logrotate.service
- systemctl start logrotate.timer
- Docker ComposeでDockerコンテナの生成・起動
の順番で実行する。
で、「ログローテーション」されたっぽい。
なんだけど、「/etc/logrotate.d/oxidized」の設定が悪いのか、
■強制的に「ログローテーション」を実行する
logrotate -f /etc/logrotate.conf
⇧ を実行すると、エラーが出るんよね...
まぁ、ログの書き込みはされ続けているので問題ないんかな?
結局、Dockerコンテナで稼働しているアプリケーションの「ログローテーション」は、どうするのが正解なのかね?
今回も、否応なく不毛な時間を費やされて、ストレスと疲労困憊で疲弊しただけでしたな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。