ICPC 2025 横浜大会でシステム担当が行った変更を紹介します。 前回の記事 ICPC 2025 横浜大会での、主なシステム関係の変更の続きです。 前回は大きめの作業として、選手からも観客からもわかりやすい、風船の話と選手カメラの話を書きました。今回はもっと細かい変更を紹介します。変更の一部は選手からも気づかれにくいですが、どれもコンテスト中の事故を防止したり、選手の不便さを改善したりするなど、コンテスト運営のクオリティを上げるのに寄与しています。
- Ubuntu 24.04 へのベースシステム更新
- Python3 を動かしたときに警告が出るようにした
- IDE が暴走したときに UI がフリーズしないようにした
- 選手が書いたプログラムを持ち帰るための Takeout ディレクトリをなくし、ホームディレクトリ以下のファイルをそのまま持ち帰れるようにした
Ubuntu 24.04 へのベースシステム更新
ベースシステムを Ubuntu 22.04 LTS から Ubuntu 24.04 LTS に更新しました。ICPC 世界大会のベースシステム更新に合わせ、LTSのリリースから1年経ったタイミングで更新しています。Ubuntu は2年ごとに新しい LTS をリリースし、リリースごとに主要なソフトウェアのバージョンを引き上げるため、これについていかないと世界大会と同等の言語機能を提供できなくなってしまいます。今回の更新は変更が比較的少なく、スムーズに移行できました。
やることが近いので、毎回 Qiita の YasuhiroAbeさんの記事 を参考にしています。記事にあるとおり、今回は前回との差分がほとんどありませんでした。
一つ影響のあった変更は pulseaudio から pipewire への変更です。Ubuntu のデフォルトサウンドシステムが変更になったので、スピーカーの設定を書き換えました。単に選手用コンピュータのスピーカーを無効にしているだけですが。
Python3 を動かしたときに警告が出るようにした
選手が Python3 を動かしたときに、Python3 ではなく PyPy を使うよう警告が出るようにしました。プログラム開始時にエラー出力に以下のメッセージが出ます。
Use `runpython3` to test your python program, not `python3`
選手に正しい Python ランタイムを使うことを促し、ランタイムの差異でエラーになってしまうのを防ぎます。
ICPC では Python3 として PyPy を提供しています。これはICPC世界大会準拠です。ただ、システムからは Python3 を排除できないので、両方載せた上で、runpython3 コマンドで PyPy が動くようにしてあります。
2024 年の ICPC 横浜大会では、PyPy で使えないライブラリを使おうとしてエラーになっていたチームを見かけました。手元で PyPy を使ってプログラムをテストしているならこのようなことにはならないと思われるので、選手が python3 を使っているのだと推測されました。選手が間違った方法でプログラムをテストしているのは選手の責任ではありますが、一方で慣れないコンテストマシンを操作しているためにこのようなエラーは起きがちではあります。システム的に警告を出して選手を助けようということになりました。
Python3 を実行させにくくするにはいろいろな方法がありますが、システムに影響を与えずそれを行うのは難しいです。理想的には Python3 を排除したり、 Python3 を起動したときに PyPy が動くようにするべきかもしれません。しかし Python は選手用プログラムだけでなく Ubuntu のいくつかのソフトウェアでも使われており、これを不用意に改造するのは危険です。色々考えた結果、上記の警告を出すプログラムを、python3 のエイリアスとして、~/.bash_aliases に配置し、選手ユーザーにのみ有効にすることにしました。これで、ユーザーがシェルを動かすときにのみ上記のエイリアスが有効になります。さらにエラー出力にメッセージを出すだけにしているため、影響はごく僅かです。
これによりどのくらい選手の助けになったかは正直わかりません。エラー出力に出しているだけなので見落とされているかもしれません。もっと大胆な変更が必要かもしれませんが、徐々に試していこうと思います。
IDE が暴走したときに UI がフリーズしないようにした
いくつかの IDE で、一度に使える CPU を制限しました。これにより、IDE が暴走してしまってもコンピュータの操作ができ、その IDE を止めることが可能になります。
2024 年にはいくつかのチームで CLion が暴走していました。マシンのCPUをすべて使い切ってしまい UI が操作不能になっていたので、システム側からセッションのリスタートをかけるほかできることがありませんでした。
同じ問題を選手自身が解決できるように、CPU 使用量の制限をかけました。IDE の暴走だけでなく、選手の書いたプログラムが暴走した場合でも対応できるようになっています。
変更の副作用として、選手の書いたプログラムをIDE経由で実行した場合、コンピューターの CPU を全ては使えないようになっています。これは問題ありません。コンテストサーバ上ではいずれにせよ選手の書いたプログラムで使える CPU 数は制限されています。
制限をかけるには cgroups を使っています。cgroups の CPUQuota を指定すれば、特定のプロセスの使う CPU を制限できます。 cgroups の制限を指定するために、 IDE を起動するための .desktop エントリーすべて (/home/$USER/Desktop/ に置いてあるものと、/usr/share/applications/ にあるもの) を以下のように書き換えています。
- もともと:
Exec=(IDE コマンド名) - 書き換え:
Exec=systemd-run --user --scope -p MemoryMax=xxG -p MemorySwapMax=yyG -p CPUQuota=NNN%% (IDE コマンド名)- xx, yy, NNN には数値が入ります。これらをシステム全体より少なく設定することで、OSやUIの制御用のリソースを確保しています。
見てのとおり、CPUQuota だけでなく MemoryMax や MemorySwapMax も指定しています。後者は何年も前から導入しており、IDE や選手のプログラムがメモリを使い切って UI フリーズを起こすことを阻止していました。
選手が書いたプログラムを持ち帰るための Takeout ディレクトリをなくし、ホームディレクトリ以下のファイルをそのまま持ち帰れるようにした
コンテスト中に選手が書いたプログラム類を持ち帰る方法を変更しました。2024 年までは 選手用コンピュータのホームディレクトリ以下に Takeout ディレクトリが用意され、そこに配置したファイルは後日選手が受け取れるようになっていました。今年は Takeout ディレクトリを廃止し、選手がホームディレクトリ以下に書いたファイルをそのまま持ち帰れるようにしました。これまでは、選手が書いたプログラムを Takeout ディレクトリ以下にコピーし忘れてソースコードを紛失するという事故が起こり得ましたが、今回の変更でそのリスクをゼロにできました。選手はコンテスト終了まで、保存場所を気にせずコーディングに集中できます。
コンテストで提供されるコンピュータは主催者が提供するので、コンテスト中に書いたプログラムはそのままでは持ち帰れません。持ち帰りを可能にすために、特定の場所に保存したファイルをコンテスト後に保全して選手に送っていました。2024年まではその場所がホームディレクトリ以下の Takeout ディレクトリでしたが、今年はその場所を指定せず、 ホームディレクトリ以下に保存したファイルをそのまま保全するようにしました。
変更理由は世界大会の方法の踏襲です。Takeout ディレクトリがいつどのように導入されたかはわかりませんが、2014年の日本のアジア地区予選 のHow to Use the System には記載があります。ある時点での世界大会での手法を踏襲したと思っています。一方世界大会のTechnical Notesには、ホームディレクトリ以下に保存したファイルはすべて後で入手できると書かれています。現行の世界大会のほうが圧倒的に親切なので、そちらに従うことにしました。
やってみると親切なだけでなく、大会進行もスムーズになりました。今までは「Takeout directory に必要なファイルを保存してください」などのアナウンスを入れる必要がありましたが、ホームディレクトリ以下をすべて保全するのであれば、その必要もありません。コンテスト終了直後に保存の時間を設ける必要もありません。変更してよかったと思います。
まとめ
前回より細かく、観客にはほぼ気づかれない変更を解説しました。しかしどれもコンテストの不便を減らしたり事故を未然に防いだりする大切な変更です。コンテストシステムとして提供しているものはあまり変わりませんが、必要な変更はこのように多岐にわたります。