「今はこの問題を見せられないの」。妻が自宅のパソコンの不調を訴えた際、夫が「なぜ再現できないの？」と尋ねると、妻は首をかしげたくなる答えを返しました。「だって、今日は水曜日だから」。
2009年、Ubuntuコミュニティは不可解なシステム障害に遭遇しました。多くのユーザーが、OpenOffice経由で印刷を実行すると散発的に失敗することに気づいたのです。初期調査における唯一のヒントは、他のアプリケーションからの印刷は正常に行えるのに、OpenOfficeの印刷ジョブだけがブラックホールへと消えてしまうことでした。そのため、ほとんどの開発者はOpenOffice本体のバグだと疑っていました。
再インストールでは解決しない「火曜日の呪い」
中には「OSの再インストール」という最終手段を試すユーザーもいました。木曜日にクリーンインストールを完了し、印刷テストに成功して安心したものの、2週間後の火曜日にプリンターは再び黙り込んでしまいました。
問題の原因はOpenOfficeのコードではありませんでした。真の犯人は、より深い基盤コンポーネントに潜んでいたのです。Linuxシステムは file コマンドを使用してファイル形式を特定しており、これにはコミュニティが手動で維持している1600以上の magic pattern ルールが使われています。システムは印刷を実行する前に、まず file コマンドで対象が PostScript 形式かどうかを確認します。
図：PostScriptファイルヘッダーの描画日付とmagic patternルールの衝突。出典：自作図解
2001年、file のルールデータベースに Erlang JAM ファイルを識別するためのルールが追加されました。しかし、スペースのエスケープが漏れていたため、ルール内の Tue が単独でマッチングするパターンになってしまい、しかもその優先度が PostScript よりも高く設定されていました。その結果、ファイル内に Tue が含まれていると、システムはそれを Erlang ファイルだと誤判定してしまうことになります。低レイヤーの些細な見落としが、システム全体の正常な動作を麻痺させたのです。
カレンダーこそが最も正確なデバッガー
火曜日にOpenOfficeで印刷を実行して PostScript ファイルが生成されると、ファイルヘッダーには作成日時として %%CreationDate: (Tue ...) が自動的に書き込まれます。file コマンドがこの Tue を検出すると、即座に印刷用ファイルではない（Erlang バイナリである）と判断し、プリンターへの送信を拒否していたのです。
図：低レイヤーの些細なエラーが上位アプリケーション全体の不具合を引き起こす。出典：自作図解
15年前のこのエピソードは、2026年の現在でもLobstersの話題一覧で上位にランクインしました。コミュニティのエンジニアたちは、これをトラブルシューティングの生きた教材として語り継いでいます。複雑なシステムにおいては、時間という次元そのものが謎の不具合を解明するキー変数となり得ることを示しています。
複雑なシステムにおいて、無関係なコンポーネントなど存在しません。**基盤ツールにおけるたった1つのスペースの書き忘れが、プリンターの動作を完全に停止させたのです。**特定の日だけに発生する障害に遭遇したときは、まずカレンダーを最も重要なデバッガーとして活用すべきかもしれません。本分析は筆者のエンジニアリング経験と公開コミュニティの議論に基づいています。
参考リンク：
- OpenOffice は火曜日に印刷できない
- Lobsters コミュニティの議論 (s/im3eeh)
