AI作業日誌 on sonohen's tech blog

DockerのAppArmor適用失敗：プロファイルの読み込みとreadby権限で対処

Mon, 12 Oct 2026 00:00:00 +0000

UbuntuでCodex用のDockerコンテナを起動したところ、AppArmorプロファイルの適用に失敗した。原因は、起動時に指定したカスタムプロファイルがホストに読み込まれていなかったことだった。読み込むとコンテナは起動したが、続いてコンテナ内のbubblewrapで権限不足が見つかり、プロファイルの修正も必要になった。

この記事では、Dockerを使う技術者に向けて、拒否ログによる切り分けと対処を説明する。今回確認した問題は次の2段階だった。

発生段階	ログの手掛かり	対処
コンテナの起動時	`label not found`	指定したプロファイルをホストに読み込む
起動後のbubblewrap実行時	`denied_mask="readby"`	同じプロファイルのプロセス間に`readby`を許可する

調査はCodexに依頼し、ホストの設定変更とコマンド実行は自分で行った。修正後はコンテナへのプロファイル適用を確認し、提示した直近5分のログに拒否はなかった。その後、ホストの再起動後も自分で確認し、問題なかった。

この環境でのAppArmorとbubblewrapの役割

AppArmorは、プロセスが実行できる操作をプロファイルで制限するLinuxのセキュリティ機構だ。今回の環境では、Dockerコンテナにcodex-bwrapというカスタムプロファイルを適用していた。これは自分の環境で用意した名前で、Docker標準のプロファイル名ではない。

コンテナ内では、Codexのコマンド実行を制限するためにbubblewrap（実行ファイル名はbwrap）も使っている。コンテナが起動した後も、その中のプロセスはAppArmorの制約を受けるため、bubblewrapの動作に必要な操作をプロファイルで許可する必要がある。

また、プロファイルには次の3つの状態がある。設定ファイルがあるだけでは、コンテナに適用できない。

状態	今回の対象・確認方法
設定ファイルが存在する	`~/work/codex-docker/codex-bwrap.apparmor`
ホストのLinux Kernelに読み込まれている	`apparmor_parser`で読み込み、`aa-status`で確認
コンテナに適用されている	`docker inspect`の`AppArmorProfile`で確認

以下のコマンドは、Dockerデーモンが動いているUbuntuホストの通常のユーザー端末で実行する。パスとプロファイル名は自分の環境に合わせて読み替える必要がある。掲載するルールは既存プロファイルの変更箇所であり、プロファイル全体ではない。

発生したエラーと環境

実行したのは、自作のCodex用Docker起動スクリプトだ。このスクリプトは、コンテナの起動時にcodex-bwrapを指定する。

~/work/codex-docker/run-codex.sh

出力は次のとおりだった。末尾のヘルプ案内は省略している。

Docker AppArmor setting: codex-bwrap
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: unable to apply apparmor profile: apparmor failed to apply profile: write fsmount:fscontext:proc/thread-self/attr/apparmor/exec: no such file or directory

unable to apply apparmor profileから、コンテナを準備するOCIランタイムがAppArmorを適用する段階で失敗したと分かる。コンテナ内のCodexは、まだ動き始めていなかった。調査時に確認した環境は次のとおり。

項目	バージョン・状態
Ubuntu	26.04.1 LTS
Linux Kernel	7.0.0-38-generic
Docker Client / Server	29.9.0 / 29.9.0
Docker context	default
containerd	v2.4.1
runc	1.5.2
AppArmor parser	5.0.2
AppArmor	有効、`codex-bwrap`を指定

起動時の拒否ログから、プロファイル未読み込みを確認する

エラー末尾はno such file or directoryだが、Codexが確認すると、ホストの/proc/thread-self/attr/apparmor/execは存在していた。

原因を判断する手掛かりになったのは、Linux Kernelのログだった。

sudo aa-status | rg 'codex-bwrap'
sudo journalctl -k -b --no-pager --grep='codex-bwrap|label not found' -n 30

aa-statusの抽出結果にcodex-bwrapの行はなく、ログには次の拒否が記録されていた。時刻やホスト名などを省略し、メッセージ部分を抜粋している。

apparmor="DENIED" operation="change_onexec" class="file" info="label not found" error=-2 profile="runc" name="codex-bwrap" pid=8853 comm="runc:[2:INIT]"

ここでいうラベルは、AppArmorがプロファイルを識別するための名前だ。name="codex-bwrap"とinfo="label not found"から、起動時に指定したプロファイルを見つけられなかったと分かる。runc 1.5.2の実装では、exec属性への書き込みでプロファイルを指定する。今回の書き込みエラーは、パス自体が存在しないという意味には限定できなかった。

Codexが起動スクリプトを調べたところ、AppArmorを自動選択するCODEX_APPARMOR=auto設定は、DockerのAppArmor対応だけを確認していた。カスタムプロファイルの登録確認や読み込みは行っていなかった。Dockerの公式資料でも、カスタムプロファイルは先に読み込み、その後でコンテナに指定する手順になっている。

今回のaa-statusと拒否ログを合わせると、指定したプロファイルをホストに読み込む必要があった。ただし、以前の登録が再起動などで失われたのか、別の理由で未読み込みだったのかは特定できていない。

プロファイルを読み込んで起動エラーを解消した

Codexがプロファイルの実ファイルを確認し、自分で次のコマンドを実行した。apparmor_parserは設定ファイルを解析してホストに読み込むコマンドで、-rは既存のプロファイルがあれば置き換える指定だ。

ここではファイルの場所が明確になるよう、絶対パスを使っている。管理者権限の実行環境では、$HOMEが通常ユーザーのホームを指すとは限らない。

sudo apparmor_parser -r -W /home/sonohen/work/codex-docker/codex-bwrap.apparmor
sudo aa-status | rg 'codex-bwrap'

実行した結果、apparmor_parserの終了コードは0となり、aa-statusにもcodex-bwrapが表示された。コンテナのdocker inspectでも同じプロファイル名を確認でき、元のOCI起動エラーは解消した。

起動後の拒否ログから、readby権限を追加する

コンテナへの適用を確認した後、Linux Kernelのログに別の拒否が出ていた。comm="bwrap"はbubblewrapのプロセスを示す。最初の起動エラーが解消しても、プロファイルの内容が実行時の操作に足りるとは限らなかった。

apparmor="DENIED" operation="ptrace" class="ptrace" profile="codex-bwrap" pid=11588 comm="bwrap" requested_mask="readby" denied_mask="readby" peer="codex-bwrap"

当時のプロファイルには、次のルールがあった。

ptrace (read, trace) peer=codex-bwrap,

このログでは、profileとpeerがともにcodex-bwrapで、拒否された権限はreadbyだ。同じプロファイルが適用されたプロセス同士のアクセスで、読まれる側の許可が不足していた。

AppArmorのptraceルールは、デバッガによる操作に加え、一部の/proc経由のプロセス情報へのアクセスも制御する。readは相手の情報を読む側、readbyは相手に読まれる側の許可を表す。Ubuntu 26.04のAppArmorマニュアルでも、アクセスする側と受ける側の双方に許可が必要とされる。同じプロファイルのプロセス間でも、readだけでは足りなかった。

Codexの提案に従い、元ファイル/home/sonohen/work/codex-docker/codex-bwrap.apparmorの該当ルールを次のように変更した。

ptrace (read, readby, trace) peer=codex-bwrap,

許可対象はpeer=codex-bwrapのままにした。今回の拒否ログではtracedbyは要求されていないため、追加していない。

修正版をホストへ配置し、再起動後も読み込めるようにする

apparmor_parserによる読み込みは、現在動いているLinux Kernelに対する操作だ。再起動後も読み込めるよう、修正版のファイルをホストのAppArmor設定ディレクトリ/etc/apparmor.d/codex-bwrapへ配置した。

作業時には、初回の配置で宛先ファイルが存在しないことを確認していた。その後のreadby追加では、配置済みのファイルをバックアップしてから更新した。以下の掲載例は、既存ファイルがある場合だけバックアップする形にまとめている。

バックアップは/var/backupsに置く。元の作業手順では/etc/apparmor.d内に置いていたが、AppArmor 5.0.2の実装では、.bak-日時は読み込みの除外対象にならない。古いファイルも読み込み対象になり得るため、掲載例では配置先を変更した。

sudo install -d -m 0700 /var/backups/codex-apparmor
if [ -f /etc/apparmor.d/codex-bwrap ]; then
 sudo cp -a /etc/apparmor.d/codex-bwrap \
 /var/backups/codex-apparmor/codex-bwrap.bak-$(date +%Y%m%d-%H%M%S)
fi
sudo install -m 0644 /home/sonohen/work/codex-docker/codex-bwrap.apparmor \
 /etc/apparmor.d/codex-bwrap
sudo apparmor_parser -r -W /etc/apparmor.d/codex-bwrap
sudo aa-status | rg 'codex-bwrap'

ホストのポリシー変更、配置、再読み込みは自分で実施した。Codexは元ファイルのreadby追加と、配置済みファイルとの一致を読み取りで確認した。

適用結果と再起動後の確認

配置と再読み込みが終わったら、コンテナを起動して適用結果を確認する。自作スクリプトのCODEX_APPARMOR=requiredは、AppArmorを必須にする設定だ。作業対象のディレクトリで次を実行する。

CODEX_APPARMOR=required ~/work/codex-docker/run-codex.sh

起動後、別の端末から対象コンテナと拒否ログを確認する。

docker ps
docker inspect --type container --format '{{.AppArmorProfile}}' CONTAINER_ID
sudo journalctl -k --since '5 minutes ago' --no-pager \
 --grep='codex-bwrap|apparmor="DENIED"'

CONTAINER_IDには、docker psで確認した実際のIDを指定する。期待する結果は、コンテナが起動し、AppArmorProfileがcodex-bwrapとなり、対象の操作時に新しい拒否ログが出ないことだ。確認に5分以上かかる場合は、--sinceの範囲を起動時刻まで広げる。

自分が提示した修正後の結果では、docker inspectの出力はcodex-bwrapだった。直近5分のログには次の更新通知だけがあり、DENIEDはなかった。メッセージ部分を抜粋する。

apparmor="STATUS" operation="profile_replace" profile="unconfined" name="codex-bwrap" pid=12838 comm="apparmor_parser"

ここにあるprofile="unconfined"は、更新を行ったプロセス側の表示だ。コンテナに適用されたプロファイルはdocker inspectの結果で確認した。

ここまでの適用結果とログは調査記録に残っている。再起動後の自動読み込みは、その記録をまとめた時点では未確認だったが、その後、自分でホストを再起動して確認し、問題なかった。

ただし、当初行おうとしていたCodexの具体的な操作の成否は、調査記録には残っていない。コンテナ起動とAppArmor適用の確認だけで、Codexの全機能が動作したとは判断していない。また、修正後に拒否がなかったという判断は、提示したログの時間範囲に基づく。

同じ症状を調べるときの確認順序

今回の調査では、エラー末尾のno such file or directoryだけでは原因を判断できなかった。Linux Kernelのログでラベル解決失敗を確認し、読み込み後には別の権限不足を切り分けた。同じ症状を調べる場合は、次の順序で確認すると、今回の2つの問題を区別できる。

aa-statusと起動時の拒否ログで、指定したプロファイルが読み込まれているか確認する。
起動できたら、docker inspectでコンテナへの適用を確認する。
対象の操作を実行し、新しい拒否ログのprofile、peer、denied_maskから不足している許可を調べる。

CodexでレシートPDFからBeancountへの仕訳登録を自動化した

Sun, 11 Oct 2026 00:00:00 +0000

PDFで保存したレシートを、Beancountの帳簿へ転記する作業をCodexに任せることにした。既存の勘定科目を使って仕訳案を作り、人間が確認したら帳簿へ書き込む。登録するたびにbean-checkを実行し、成功するまで次の取引へ進まない運用にした。

自動化したのは読取り、仕訳案の作成、証跡の整理、帳簿への転記と検証である。仕訳案の最終確認は人間が行う。ファイル監視で無人処理する仕組みにはしていない。

全体の流れは次のとおりである。

人間がレシートをPDFで保存し、ファイル名に支払方法を付ける。
Codexが全ページを読み、既存科目と支払方法から仕訳案を作る。
人間が仕訳案と証跡の組合せを確認する。
補助ツールが証跡を保存し、1取引ずつ帳簿へ登録する。
各登録の直後にbean-checkを実行し、成功したら次へ進む。

Codexが判断し、Pythonが書き込む

帳簿は次の構成で管理している。

ファイル	役割
`account.beancount`	勘定科目と日本語の名称
`year/2026.beancount`	2026年の仕訳
`main.beancount`	科目、各年の仕訳などを読み込む入口

Codexには、レシートの内容に加えてaccount.beancountと既存の仕訳を読ませる。店舗名だけで費用科目を決めず、酒類、書籍、レジ袋などを品目に応じて分ける。消費税も既存の記帳方法に合わせて別科目へ計上する。

読取りと判断はCodex、金額の検証とファイル操作はPythonの補助ツールに分担した。補助ツール自体にはOCRやAI APIの呼出しを組み込んでいない。

実装環境はPython 3、Beancount 3.2.0、Popplerである。手順はリポジトリのAGENTS.mdに記載し、補助ツールをscripts/receipt.pyとして作成した。

抽出テキストだけで転記しない

スキャンしたPDFには抽出可能なテキストが入っていても、数字や店舗名に誤読があった。そこで、pdftotextで抽出した内容を、pdftoppmで画像化した全ページと照合する。取引日、合計、税額、割引は画像でも確認する。

実際に、ファイル名の日付と取引日が違うレシートがあった。ファイル名が2026-10-11で始まるPDFに、10月8日の給油が記載されていた。別のPDFも、ファイル名は2026-10-11で始まるが取引日は10月9日だった。

帳簿の日付にはレシートの取引日を使う。読めない数字や証跡間の矛盾があれば、推測して登録せず人間に質問させる。

支払方法はファイル名に書く

最初は、レシートを読むたびに支払方法を質問させていた。カード払いと分かっても、どのカードかは帳簿の科目へ対応させる必要があるためだ。

毎回回答する手間を減らすため、自分でPDF名の末尾に支払方法を付けることにした。次のような形式である。

日付.店舗名.支払方法.pdf

次の表は対応の一例で、今回使った支払方法を示している。

ファイル名の支払方法	支払科目
現金	`Assets:Cash:Purse`
モバイルSuica	`Assets:ICCard:MobileSuica`
ビックカメラVIEW	`Liabilities:CreditCard:BiccameraVIEWSuicaCard`

補助ツールは.pdfの直前の要素を対応表で変換する。店舗名の一部から支払方法を推測することはない。

ファイル名から判別できれば、支払方法の質問は省略する。未記載、未知の表記、PDFの内容との明確な不一致がある場合は質問する。仕訳案の最終確認は、支払方法が分かっていても省略しない。

PDFの数と取引の数を分ける

領収書とカードの利用票は、同じ購入を示す別の証跡である。これらを別取引として登録すると、費用を二重計上してしまう。

同じPDFの再取込みは、ファイルごとのSHA-256で検出する。ハッシュをdocumentのメタデータへ保存し、取込み済みの証跡と照合する。別のPDFが同じ購入を示している場合は、取引情報でも確認する。

注文番号や伝票番号を優先し、店舗、日付、金額も使って同じ取引の証跡をまとめる。複数PDFの組合せはCodexが候補を提示し、人間が確認する。1つのPDFに領収書と利用票の2ページがある場合も、1取引として扱う。

仕訳と証跡はBeancountのリンクで紐づける。次は今回登録した給油の例で、店舗名とPDF名は説明用に置き換えている。

2026-10-08 * "ガソリンスタンド" "ハイオク給油" ^receipt-example
 Expenses:Car:Gasoline 2696 JPY
 Expenses:Tax:Consumption-Tax 270 JPY
 Liabilities:CreditCard:BiccameraVIEWSuicaCard -2966 JPY

2026-10-08 document Expenses:Car:Gasoline "../Expenses/Car/Gasoline/receipt.pdf" ^receipt-example

既存取引と日付、店舗、費用総額が一致した場合も確認を求める。後から別の証跡を受け取った場合は、既存取引に証跡だけを追加できる。

PDFは費用科目に応じたフォルダへ移動する。複数科目がある場合は、税を除いて費用額が最大の科目を保管先にする。複数取引で共有するPDFは1回だけ保存し、関連する全取引の登録が終わるまで元ファイルを残す。

1取引ずつbean-checkを通す

補助ツールは、Codexが作ったJSON形式の仕訳案を受け取り、次の順序で処理する。

既存の帳簿にエラーがないことを確認する。
今回の1取引を一時帳簿で検証する。
PDFを保管先へコピーし、ハッシュを確認する。
その取引だけを本帳簿へ書き込む。
bean-check main.beancountを実行する。
成功したら処理済みとし、不要になった元PDFを削除する。

通常のコピー、書込み、検証に失敗した場合は、今回の帳簿変更を戻して元PDFを残す。失敗した取引を飛ばして後続の処理を進めない。

専用ツールのcheckは事前検証、commitは1取引の登録を行う。ここでのcommitはGitのコミットではない。

python3 scripts/receipt.py check proposal.json --transaction receipt-example
python3 scripts/receipt.py commit proposal.json --transaction receipt-example

今回作成したツール専用のコマンドなので、Beancountをインストールするだけでは使えない。この記事は実装と運用の記録であり、ツールの配布手順は扱っていない。

最初にPDFを1件登録し、続いて5件を登録した。後者では領収書と利用票を含む全8ページを確認し、各取引の登録直後に検証が成功した。証跡の移動後はハッシュの一致も確認できた。

補助ツールの13件のテストも通った。対象には、複数証跡、重複候補、未確認の仕訳、ファイル名の支払方法、コピー失敗、検証失敗後の停止と再開が含まれる。

残高照合で未記帳のチャージを見つけた

レシートのない鉄道、飲料、Suicaチャージも、日付、金額、支払方法を伝えて登録した。その後、自分が確認したモバイルSuicaの実残高を帳簿に追記した。

2026-10-11 balance Assets:ICCard:MobileSuica 11362 JPY

この時点でbean-checkは失敗した。識別に必要なメッセージを抜粋すると、次の内容だった。

Balance failed for 'Assets:ICCard:MobileSuica': expected 11362 JPY != accumulated 1362 JPY (10000 too little)

帳簿が実残高より10,000円少なかった。自分が10月5日のチャージを思い出して伝えると、Codexがその日の帳簿にチャージがないことを確認した。ビックカメラVIEW Suicaカードからの10,000円チャージを追加したところ、残高照合を含めて検証が成功した。

仕訳の検証が通っていても、取引の漏れまでは見つからない。実残高をbalanceで照合したことで、未記帳を発見できた。

現状の対象は2026年の日本円による通常の購入で、外貨や返品は扱っていない。また、突然のプロセス終了や電源断に対して、帳簿とPDFの更新を完全に一体化する保証はない。今回確認できたのは、通常の失敗時の巻き戻しと、対話で確認した仕訳を順番に登録する運用である。

サスペンド復帰後にNextDNSが応答しなくなる問題を調べ、自動再起動を設定した

Sun, 11 Oct 2026 00:00:00 +0000

Ubuntuの端末をサスペンドから復帰させると、NextDNSから応答を得られなくなることがあった。そのたびに自分でNextDNSを手動再起動していた。毎回操作するのは面倒なので、Codexに症状の調査と自動再起動の実装を依頼した。

NetworkManagerの接続イベントを受け、約5秒後に稼働中のNextDNSを再起動する仕組みを設定した。内部原因は未特定で、自動再起動による復旧効果は今後確認する。

調査した環境

項目	バージョン
Ubuntu	26.04.1 LTS
Linux Kernel	7.0.0-38-generic
NextDNS CLI	1.47.3
NetworkManager	1.54.3-2ubuntu3.1
systemd	259.5-0ubuntu3.4

以下の実装は、NetworkManagerで接続を管理し、NextDNS CLIがsystemdのnextdns.serviceとして動作する環境を前提とする。

Wi-Fiが戻ってもDNS問い合わせは失敗していた

Codexにログ調査を依頼した。10月11日のホストのjournalでは、次の時系列を確認できた。

journalctl -b -u nextdns -u systemd-suspend -u NetworkManager \
 --since '2026-10-11 09:05:00' --until '2026-10-11 09:35:00' --no-pager

時刻	ログで確認した内容
09:17:40	サスペンドを開始し、Wi-Fiを切断
09:31:19	サスペンドから復帰
09:31:25	NetworkManagerが`CONNECTED_GLOBAL`を報告
09:32:24以降	NextDNSのエンドポイント取得がタイムアウト
09:34:04	DNS問い合わせのタイムアウトが多数発生
09:34:13	自分でNextDNSを再起動
09:34:18	新しいプロセスがDoH接続を再確立

名前解決のエラーには、次の文字列が含まれていた。ログ全文ではなく、識別に必要なメッセージ部分を抜粋している。

doh resolve: context deadline exceeded

エンドポイント取得でも、次のエラーが出ていた。

exchange: roundtrip: context deadline exceeded

Wi-Fiの接続復旧が報告された後も、同じNextDNSプロセスでDNS問い合わせの失敗が続いていた。この事例では、サービスが落ちたというより、動いたまま上流への通信を回復できていないように見える。

内部原因は未特定で、NetworkManagerの接続状態だけでは外部との通信が正常とは言い切れない。手動再起動後のログではDoH接続の再確立が記録されており、自分でもDNSの実応答を確認した。

NextDNSの公式リポジトリにあるIssue #699にも、サスペンド復帰後のDNS問い合わせのタイムアウトが報告されている。こちらはNextDNS 1.37.11とUbuntu 22.04の事例だ。今回と同じ原因とは限らない。

接続イベントから再起動する

プロセスが生きたまま応答できなくなる症状には、終了時の再起動を設定するだけでは対応できない。Codexはこの症状に対応するため、NetworkManagerの接続イベントからNextDNSを再起動する構成を実装した。

NetworkManagerのdispatcher仕様では、upはインターフェースの接続完了、vpn-upはVPNの接続完了を表す。Codexの実装では、この2つを対象にしている。

処理は次の順序で進む。

dispatcherがupまたはvpn-upを受け取る。
NextDNSが稼働中なら、systemd timerを再始動する。
timerが約5秒後にサービスを呼び出す。
稼働中のNextDNSを再起動する。

実装には、接続直後の状態が落ち着くまでの猶予として5秒の待ち時間を設けている。外部との通信が復旧したことを確認する処理ではない。

タイマーの待ち時間中に別の接続イベントを受け取ると、待ち時間を設定し直す。そのため、接続イベントが短時間に続いても、最後のイベントから約5秒後にNextDNSを1回だけ再起動する。通常のWi-Fi再接続やVPN接続でも動作するため、サスペンド復帰だけに限定した仕組みではない。再起動時には短時間DNSが途切れる。

dispatcher、timer、serviceの内容

接続イベントを受け取るスクリプト

/etc/NetworkManager/dispatcher.d/90-nextdns-reconnectに配置する。

#!/bin/sh
# NetworkManager dispatcher: coalesce connection activation events.
PATH=/usr/sbin:/usr/bin:/sbin:/bin
export PATH
case "${2:-}" in
 up|vpn-up) ;;
 *) exit 0 ;;
esac
# Do not undo an intentional stop of NextDNS.
systemctl is-active --quiet nextdns.service || exit 0
exec systemctl --no-block restart nextdns-reconnect.timer

--no-blockでタイマーの再始動を依頼し、dispatcher内では待たない。dns-changeには反応しないため、NextDNSの再起動に伴うDNS設定変更が次の再起動を誘発するループを避けられる。

5秒後に処理するタイマー

/etc/systemd/system/nextdns-reconnect.timerに配置する。

[Unit]
Description=Delay NextDNS restart after network activation

[Timer]
OnActiveSec=5s
AccuracySec=1s
Unit=nextdns-reconnect.service

NextDNSを再起動するサービス

/etc/systemd/system/nextdns-reconnect.serviceに配置する。

[Unit]
Description=Restart running NextDNS after network activation

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl try-restart nextdns.service
TimeoutStartSec=45s

Codexはtry-restartを使い、管理者が停止しているNextDNSを勝手に起動しないようにした。

実機へのインストール

Codexはインストール用のinstall.shも作成した。既存の同名ファイルがあれば停止し、ユニットの検証後に設定を配置する。

同じディレクトリに次の5つを保存すると、インストール・アンインストールのスクリプトを利用できる。

保存したディレクトリで、ホストの端末から実行する。

sudo sh ./install.sh

dispatcherはroot所有で実行可能にし、グループやほかのユーザーから書き込めない権限にする。インストールスクリプトでは0755、ユニットファイルは0644に設定している。

NetworkManager自体の再起動やタイマーのenableは不要だ。インストール直後にNextDNSを再起動せず、次の接続イベントから動作する。

Codex環境からはsudo認証できなかったため、自分でホストの別ターミナルからインストールした。

検証状況と復帰後の確認

Codexはsh -nでシェルの構文を確認し、イベント分岐をモックで検証した。upとvpn-upでは稼働中の場合だけタイマーを操作し、停止中や対象外のイベントでは操作しないことを確認した。

Codexの隔離環境ではsystem busへの接続やソケット設定が制限され、現在のサービス状態の取得とsystemd-analyze verifyは失敗した。モック検証は、実際のsystemdやサスペンド復帰を使った検証ではない。実機へのインストールは済んだ。手動再起動後のDNSの実応答は自分で確認したが、接続イベントによる自動再起動と、その後の名前解決の回復は未確認だ。

次回のサスペンド復帰後には、自分で次のコマンドを実行し、ログと名前解決を確認する。

journalctl -b -u nextdns-reconnect.service -u nextdns.service --since '-10 min' --no-pager
dig @127.0.0.1 example.org +time=3 +tries=1
getent ahosts example.org

digの例は、NextDNSが127.0.0.1:53で待ち受ける場合の直接問い合わせだ。待受先が異なる場合は、アドレスとポートを設定に合わせる。getentではOSの通常の名前解決を確認する。

確認したいのは、接続後に自動再起動したログが残り、名前解決も成功することだ。サービスがactiveというだけでは、今回の症状が解消したとは判断しない。

アンインストール

仕組みをアンインストールするときは、ファイルを保存したディレクトリから次を実行する。

sudo sh ./uninstall.sh

アンインストールスクリプトは配置済みファイルと元の実装を比較し、変更されている場合は削除しない。NextDNS本体の設定は変更しない。

EmacsでCodexを使う環境を整え、関連書籍を買った日

Sat, 10 Oct 2026 00:00:00 +0000

今日は、EmacsからCodexを使うための環境を整えていた。CLIのインストールから始めたのだが、ターミナルと日本語入力、Docker、権限の設定まで、思ったより作業が増えた。

Codexをインストールする

まず、Codexをコマンドラインから使えるようにした。今日の環境では、次のコマンドでインストールしている。

sudo npm install -g @openai/codex
which codex

which codexの結果は/usr/local/bin/codexだった。

Emacsではvtermを使うことにした

Codexをインストールしたものの、Emacsのシェルではうまく動かなかった。そこで、vtermを使うためのパッケージを入れた。

sudo apt install -y cmake libvterm-dev libtool-bin

ところが、今回の環境ではvterm上でDDSKKによる日本語入力ができなかった。別のターミナルならどうかと思い、Eatも試してみた。

NonGNU ELPAをパッケージの取得先に追加し、leafで次のように設定した。

(leaf eat
 :ensure t
 :bind ("C-c v" . eat-project-other-window))

Eatでも日本語入力ができず、動作も安定しなかったため、今回はvtermを使うことにした。DDSKKで入力するという当初の希望は、ひとまず保留にした。これは今日の自分の環境での結果であり、ほかの環境でも同じとは限らない。

Codex用のDocker環境を作る

次に、CodexをDockerで動かすための環境を作った。Dockerの導入は公式のUbuntu向けインストール手順を参考にした。

インストール後、次のコマンドで確認した。

sudo docker run hello-world

Hello from Docker!と表示されたので、続いてCodex用のDockerfileと起動スクリプトを用意した。

当日の作業メモに残した初期構成では、イメージのベースにnode:22-bookworm-slimを使い、Git、ripgrep、PythonなどとCodex CLIをインストールする。コンテナ内では一般ユーザーのnodeで実行し、作業ディレクトリを/workspaceにした。

起動スクリプトでは、ホスト側の共有ディレクトリを/workspaceにマウントし、Codexのホームには名前付きボリュームを使った。当日のメモに残した初期のスクリプトを以下に示す。Dockerfileと起動スクリプトはその後も変更しているため、以下は初期構成の記録として読む。

#!/bin/sh
set -eu

shared_dir=/home/sonohen/dockershared
mkdir -p "$shared_dir"

exec docker run --rm -it --init \
 -e TERM \
 -v codex-home:/home/node/.codex \
 --mount "type=bind,src=$shared_dir,dst=/workspace" \
 codex-cli "$@"

shared_dirは自分の環境のパスなので、別の環境で使う場合は変更する。コンテナから共有ディレクトリ内のファイルは変更できるため、何を共有するかは意識しておきたい。

イメージの作成と起動には、次のコマンドを使った。

docker build -t codex-cli -f Dockerfile .
./run-codex.sh

bubblewrapとAppArmorの設定で悩む

環境を整える途中で、bubblewrapが新しいnamespaceを作成できないというメッセージにも遭遇した。作業メモに残した原文は次のとおりだ。単語間の空白も記録どおりに示す。

bwrap:No permissions tocreate a new namespace,likely because the kerneldoes not allow non-privileged user namespaces.

メッセージには、非特権ユーザーによるnamespaceの作成がカーネルで許可されていない可能性が示されていた。そこで、UbuntuのAppArmor設定を調べた。

まず、次の設定値を確認した。

sysctl kernel.apparmor_restrict_unprivileged_userns

結果は次のとおりだった。

kernel.apparmor_restrict_unprivileged_userns = 1

この値を確認したうえで、/usr/bin/bwrapにusernsを許可するAppArmorプロファイルを作った。管理者権限で次のコマンドを実行し、apparmor_parserで読み込んだ。

sudo install -m 644 /dev/stdin /etc/apparmor.d/bwrap <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
 userns,

 include if exists <local/bwrap>
}
EOF

sudo apparmor_parser -r /etc/apparmor.d/bwrap

この設定後、私が使っている範囲ではbubblewrap関連のエラーは出なくなった。すべての実行条件を検証したわけではないため、今回確認できた範囲での結果として記録しておく。

また、Codexのconfig.tomlには次の設定を追加した。これは今回の環境で追加した内容の記録なので、末尾のパスはインストール先に合わせる必要がある。

default_permissions = "project-edit"

[permissions.project-edit.filesystem]
":minimal" = "read"
"/usr/local/lib/node_modules/@openai/codex" = "read"

OpenAIのサンドボックスの説明にも、Linuxで必要になるbubblewrapと、UbuntuでのAppArmor設定について記載がある。Ubuntuのバージョンによって扱いが異なるため、同じメッセージが出た場合も、自分の環境に合う手順を確認したい。

Ubuntuで行ったほかの作業

aptの段階的な更新を知った

sudo apt upgradeを実行したところ、Not upgrading yet due to phasingと表示され、20個のパッケージが更新されなかった。

作業メモから、表示の冒頭と更新件数を抜粋する。途中のパッケージ一覧は省略した。

Not upgrading yet due to phasing:
（パッケージ一覧を省略）

Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 20

調べると、Ubuntuには更新を一度に全員へ配布せず、対象を段階的に広げる仕組みがある。Phased updatesの公式説明によると、不具合が見つかった際の影響を小さくするためのものだ。今回の表示は、その段階的な配布に関係していた。

localsearchを一時的に止めた

localsearch-extractor-3の動作が気になったので、ひとまず次のコマンドでサービスを停止し、起動を抑止した。原因はまだ分かっていない。

systemctl --user mask --now localsearch-3.service

実行すると、すぐにプロセスが停止した。元に戻すときのコマンドも記録しておく。

systemctl --user unmask localsearch-3.service
systemctl --user start localsearch-3.service

ibus-skkを入れた

vtermではDDSKKによる日本語入力ができなかったので、ibus-skkと辞書もインストールした。

sudo apt install ibus-skk skkdic

ところが、vtermとの組み合わせでは変換した文字が消えてしまうなどの問題があり、ibus-skkは使わないことにした。今回の環境では、vterm上の日本語入力はUbuntuのMozcに頼るしかなさそうだ。

Codexの本を買った

本屋で『Codexではじめるエージェンティックコーディング』を見かけ、タイトルが気になったので購入した。

初版ということもあり、少し誤植が気になる。今後の修正に期待しつつ、読書メモを残しているところだ。

指示に目標と完了条件を書く

読書メモには、Mini Codexテンプレートとして、指示に含める4つの項目を整理した。

Goal：達成したい目標を書く。
Context Pointers：既存の実装や仕様など、参照してほしい情報の場所を示す。
Constraints：変更してはいけない仕様や、守るべき規約を書く。
Done When：作業が完了したと判断する条件を書く。

AIに必要な情報を渡さなければ、推論や一般的な情報で補われてしまう。自分の作業に必要な文脈を、指示の中に具体的に含めることが大切だと受け取った。

特に完了条件は、実行や確認によって判定できる形にしたい。「きれいなコードにする」よりも、「lintエラーが0件」「既存テストがすべてpassする」のように書く。

Plan modeを使う場面を考える

Plan modeについては、方向性は決まっていても、詳細を相談しないと完成形が決まらない作業に向いているとメモした。タイプミスの修正や、単一ファイルの文言変更なら、計画を作る手間との釣り合いを考えたい。

計画を確認するときは、目標、参照情報、制約、完了条件に加え、変更の範囲と順序も見る。変更が広がりすぎていないか、戻しやすい単位になっているかを確認する。

また、調査やテスト、小さな変更を先に置き、影響の大きい変更を後にできるかも考える。タスクの分け方を判断するときには、複数の観点で検証できるかを確認したい。

今日はCodexをEmacsから使う準備に多くの時間を使った。vtermを使う方針が決まり、使っている範囲ではbubblewrapのエラーも出なくなった。日本語入力はDDSKKとibus-skkを試したものの、Mozcに頼る方向で考えている。次は、用意した環境で実際の作業を続けながら使い勝手を見ていきたい。