Eigentlich sollte man sich ja freuen, wenn die Bugs, denen man seit Stunden hinterherjagt, sich als langweilige Konfigurationsfehler erlegen lassen, aber befriedigend ist es nicht wirklich. Angefangen hat es mit etwa 500 Meldungen der Form:
[modprobe] FATAL: Could not load /lib/ modules/2.4.26-gentoo-r9/modules.dep: No such file or directory_
in meinen Logfiles. Diese scheinten fast zufällig und ohne Grund aufzutreten - mal nur zwei oder drei, mal 30, 50, 500 hintereinander.
Im Syslog stand zu den fraglichen Zeitpunkten ansonsten nichts bauchbares drin. Meine erste Spur war eine High-Load-Notifikation, die ich zum Zeitpunkt einiger der modprobe-Fehlermeldungen erhalten hatte. Der Fehler trat also offensichtlich u. a. beim emergen auf - allerdings nicht bei jedem Paket.
Ehr zufällig viel mir auch auf, dass nmap beim blossen Aufruf zwei dieser Meldungen triggerte ... Da hatten ich ja dann endlich mal was mehr oder weniger handfestes. Um mit gdb etwas in das nmap hineinzuschauen, wollte ich mir gerade eine neue Version kompilieren, als die Fehler-Meldung beim nmap configure erneut in den Logs auftauchte.
Ein configure zu debuggen gefiel mehr natuerlich noch etwas besser und bald hatte ich auch schon die fraglichen Zeilen entdeckt. Z. B.:
test -c /dev/bpf0
erzeugt den Log-Eintrag. Aber habe ich denn nicht eigentlich Module-Support im Kernel deaktiviert? Wer will denn hier ein Modul fuer bpf0 laden? Ein kurzer Test stellte sicher: in kmod.c wird der modprobe-Teil definitiv nicht mitkompiliert.
Und so langsam daemmerte es mir auch. /dev/ ... devfs ... devfsd ... /etc/devfsd.conf ...
Und siehe da:
# Enable module autoloading. You may comment this out if you don't use # autoloading LOOKUP .* MODLOAD
so schnell kann's gehen, wenn man sich auf default-Konfigurationen verlaesst. Aber nach einem kill -SIGHUP auf den devfsd war der Spuk dann endlich vorbei.