antiX 26.1 i386 / runit環境における inetd・Telnet自動起動設定記録

はじめに

令和8年10月1日、とある目的で「でじこ」に仮想Ｌｉｎｕｘ環境を整えた時の記録をここに残します。なお、本文章の大半はChatGPTによる生成の結果であり、私ことＣ．ｐａｎｄａはほぼコピペしかしていないことをここに告白します (´・ω・｀)

対象環境

- 仮想環境：VirtualBox
- OS：antiX 26.1 i386
- ホスト名：chokanji-workshop
- 用途：超漢字2向け開発・検証環境
- 接続方式：Tera Term → Telnet

目的

VirtualBox上のantiX環境へTera Termから接続するため、 Telnet環境を整備する。

なお、当初の目的は・・・

- 仮想・超漢字工房への遠隔操作環境確保
- GUI操作に依存しない保守経路確保

でしたが・・・以下の問題が発生しました。

`inetutils-telnetd` 導入後、手動起動では動作するが、再起動後にはTelnet接続できなかった。

そこで、まずは確認作業としてTelnetの待ち受けをしているかどうかを調べてみると・・・

ss -ltn | grep ':23 '

その結果、待ち受けしていなかった事がわかりました。

なので、まずは、そもそも'inetd'が起動しうるのかどうか調べる事に。

service inetutils-inetd start

その結果、手動だと正常に起動することが確認できました。さらに、

ss -ltn | grep ':23 '

にて23番ポートの待ち受けも確認。このことから、原因はinetd本体やTelnet設定ではないと判断。

原因調査

どうにも雲をつかむような話しでしたが、まずはantiXのinit方式を確認。なお、この時点で私ことＣ．ｐａｎｄａは全く以てついて行けていません(´；ω；｀)ｳｯ…

init確認

ps -p 1 -o pid,comm,args

その結果・・・

PID 1 runit

さらにrunlevelを確認

runlevel

その結果・・・

N 2

さらにantiXのrunit設定を確認。

/etc/runit/no.emulate.sysv

設定ファイルはあった・・・そしてREADME確認。すると次の一文が・・・

Skip all sysv scripts enabled in rc2.d during the boot sequence

つまり、antiXはSysV方式の起動スクリプトである

/etc/rc2.d/*

は起動時に実行されない。そのため、

/etc/rc2.d/S03inetutils-inetd

が存在していても、自動起動されないという事が判明しました。

解決方針

そこで、antiXの設計に合わせ、 SysV方式ではなくrunit native serviceとして登録することで、自動起動を実現できました。

上述の調査方法含め、antiXでの自動起動の実現はChatGPTによるコマンド等の生成が大いに役立ちました。

今回得られた運用知識

antiX + runit環境では、 Debian系パッケージを利用できますが、 initシステムは標準Debianとは異なる場合があります。具体的に言うと、Debian系パッケージはSysV init用の設定を提供する場合がありますが、 runit環境ではそれらが起動経路として利用されない場合があります。つまり、Debian系パッケージを導入しても、

/etc/init.d
/etc/rc*.d

だけでは自動起動しない場合があり、その時は

1. `/etc/sv`
2. `/etc/service`
3. `sv status`

を確認する必要があります。ですので、他にも、FTPなど、自動起動させたいサービスを導入する際は runit native service方式を基本とするべきだという結論に至りました。他のDebian系と同じように扱うと嵌まりますよ・・・

今後の注意事項

antiX上でサービス追加を行う場合、まずinit方式を確認する。
systemctlが存在しても、必ずしもsystemd環境とは限らない。
runit環境では/etc/svへのサービス登録を基本とする。
設定変更前には必ず現状確認とバックアップを行う。

Important Notes: antiX, Debian Packages and runit

antiX is based on Debian and can use many Debian packages. However, the init system used by antiX may differ from a standard Debian installation.

Therefore, installing a package does not always mean that the service will automatically start during system boot.

In particular, when using antiX with runit, traditional SysV init methods may not work as expected.

Service Management Considerations

Before adding services on antiX, first confirm which init system is currently running.
The presence of systemd-related tools does not always indicate that they are the active service management system.
In a runit environment, registering services as runit native services under /etc/sv should be considered the standard approach.
Before modifying system configuration files, always check the current state and keep a backup whenever possible.

Technical Background

Debian packages may provide service configuration files intended for SysV init, such as:

/etc/init.d
/etc/rc*.d

However, in an environment using runit, these scripts may not be used as the actual service startup mechanism.

This is not a problem caused by Debian packages themselves. Rather, it is a compatibility issue between:

Debian package design
the selected init system
the service management method

When working with legacy systems or specialized environments, understanding the relationship between these three components is essential.

Lessons Learned

The Telnet configuration issue described in this document was not caused by inetd or telnetd themselves.

The actual cause was that a SysV-style service registration was placed into a runit-based boot environment.

The solution was to adapt the service configuration to the native runit method rather than forcing the traditional SysV approach.

This experience demonstrates an important principle when maintaining old or specialized computing environments:

"Do not assume that the familiar method is always the correct method. First understand the system architecture, then configure the system accordingly."

電脳仮想館へ戻る