Возможно ли это чтобы изменить расположение файла конфигурации в haproxy?
Насколько я могу судить из strace выходных данных modprobe слепо доверяет тому, что modules.builtin.bin считает встроенным. Если этот файл не синхронизирован с вашим действующим ядром, я ожидаю, что modprobe вернет успех, даже если модуля там нет.
Через / proc вы можете узнать, действительно ли драйвер загружен. Это драйвер misc , поэтому вам нужно искать в двух местах.
В / proc / devices вы найдете два раздела, в которых перечислены символьные устройства и блочные устройства. Вы должны найти это символьное устройство:
10 misc
Затем посмотрите в / proc / misc младший номер каждого драйвера. Вы должны найти это:
200 tun
Если вы обнаружите, что драйвер misc присутствует, но tun отсутствует в / proc / misc , скорее всего, ваш ] файл modules.builtin.bin на самом деле не соответствует вашему ядру.
Вот пример простого файла, который я однажды создал в среде, где у меня была ограниченная гибкость и я не использовал никаких механизмов управления службами. Этот скрипт был исполняемым и находился в пути, и запускался для запуска или перезагрузки HAProxy. Настройте с вашими путями. Разрывы строк добавлены для ясности:
#!/usr/bin/bash
echo "validating configuration..."
/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -c \
&& echo "config is valid, reloading..." \
&& /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg \
-p /var/run/haproxy.pid \
-sf $(cat /var/run/haproxy.pid)
-f указывает файл конфигурации, -c проверяет конфигурацию. Если это не удается, && предотвращает перезагрузку, потому что первый запуск HAProxy (проверка конфига) завершается ненулевым результатом.
Во втором вызове, -p указывает pid файл, в который новый процесс должен записать свой идентификатор процесса, а -sf направляет HAProxy на мягкую перезагрузку, принимая управление от номера процесса, возвращенного из старого существующего файла. Это заставит старый процесс завершить себя, когда все существующие соединения будут исчерпаны.