Буквально вчера мне пришлось разбираться с одним очень тонким и специфичным багом. Баг оказался фичей, которая спотыкалась о другой баг. В ходе изучения проблемы я был вынужден изучить несколько особенностей Debian, угробить 4 часа времени и получить массу опыта.
В слегка прилизанном виде привожу хронологию событий, надеюсь, кому-то будет интересно посмотреть, как работают системные администраторы.
Предыстория
В ходе разворачивания стенда для экспериментов из нескольких идентичных серверов захотелось иметь возможность запускать нужные версии приложения без ручной работы по обновлению кода на куче хостов. Было решено запускать нужные программы с NFS-шары. Приложения были internal use only, одноразовые, причём написанные под конкретную задачу. Шара монтировалась в каталог /opt при загрузке и приложения оттуда запускались с помощью скрипта rc.local. Поскольку речь шла про экспериментальный стенд с очень частым изменением кода, играть в честного разработчика (пакеты, репозиторий, обновления, init.d скрипты) было лениво. Всё происходило под Debian Squeeze.
Шара была прописана в /etc/fstab, запуск нужных тестов — в rc.local. Казалось бы, всё сделано.
… И тут я наткнулся на Мистику. Приложения стартовали раз из пяти, причём версия «кривое приложение» была отметена почти сразу — ровно так же иногда не запускались любые другие исполняемые файлы. Причём, с /opt. Из других каталогов отрабатывали нормально. При этом руками rc.local запускаешь — 100% всё хорошо. При загрузке — успешный запуск раз из пяти, или даже реже.
В начале я не воспринимал эту проблему как серьёзную, и пытался её решить нахрапом. Поскольку проблема проявлялась только для /opt я дописал в rc.local команду ls -a1 /opt >/var/log/ls. Как и предполагалось, в /opt на момент выполнения rc.local было только два файла — точка и две точки. Другими словами, NFS-шара не подмонтировалась. Иногда. А иногда подмонтировалась.