Проблемы с сервером http при медленном установлении соединения с интернет и его разрывами/восстановлениями
При длительном подключении к сети интернет или при разрывах/восстановлении соединения некоторые приложения начинают «дурить». Вот пример записей в журнале, иллюстрирующих проблемы:
Jan 18 00:00:05 device: KEENETIC GIGA II ~ V1.10.B.RU.NDMS ~ 2013-05-28 13:20:04 Jan 18 00:00:05 syslogd started: BusyBox v1.8.2 Jan 18 00:00:05 kernel: klogd started: BusyBox v1.8.2 (2013-05-22 18:54:17 MSK) Jan 18 00:00:05 kernel: Linux version 2.6.22.15 (developers@ndmsystems.com) (gcc version 4.1.2) #1 SMP Wed May 22 22:21:44 MSK 2013 ... Jan 18 00:00:11 S01swap: Start Jan 18 00:00:11 kernel: Adding 131064k swap on /media/DISK_A1/system/.swapfile. Priority:-1 extents:1 across:131064k Jan 18 00:00:11 S10dropbear: Start Jan 18 00:00:11 dropbear[625]: Running in background Jan 18 00:00:11 S12vnstat: Start Jan 18 00:00:11 S27mysqld: Start Jan 18 00:00:11 S50lighttpd: Start Jan 18 00:00:12 S90cron: Start Jan 18 00:00:12 S99ftpmodificator: Start Jan 18 00:00:14 kernel: ... Jan 18 00:00:18 udhcpc[800]: Sending discover... Jan 18 00:00:19 Firewall: Start fw.sh Jan 18 00:00:19 kernel: br0: topology change detected, propagating ... Jan 18 00:00:20 dnsmasq[1207]: read /etc/hosts - 2 addresses Jan 18 00:00:20 S99ftpmodificator: Stop Jan 18 00:00:21 S90cron: Stop Jan 18 00:00:21 S50lighttpd: Stop Jan 18 00:00:21 S27mysqld: Stop Jan 18 00:00:21 S12vnstat: Stop Jan 18 00:00:21 S10dropbear: Stop Jan 18 00:00:21 dropbear[625]: Premature exit: Terminated by signal Jan 18 00:00:21 S01swap: Stop Jan 18 00:00:21 Firewall: Start fw.sh Jan 18 00:00:21 S01swap: Start Jan 18 00:00:21 kernel: Adding 131064k swap on /media/DISK_A1/system/.swapfile. Priority:-2 extents:1 across:131064k Jan 18 00:00:21 S10dropbear: Start Jan 18 00:00:21 dropbear[1413]: Running in background Jan 18 00:00:21 S12vnstat: Start Jan 18 00:00:21 S27mysqld: Start Jan 18 00:00:21 S50lighttpd: Start Jan 18 00:00:21 S90cron: Start Jan 18 00:00:21 S99ftpmodificator: Start ... Jan 18 00:00:32 kernel: fast vpn ctrl: fb016b4e, 1 ... Jan 18 00:00:34 pppd[1538]: primary DNS address 85.21.192.5 Jan 18 00:00:34 pppd[1538]: secondary DNS address 213.234.192.7 Jan 18 00:00:35 Firewall: Start fw.sh ... Jan 18 00:00:35 dnsmasq[1656]: read /etc/hosts - 2 addresses Jan 18 04:00:49 zyntp[1708]: New time offset -> 11285213. May 28 18:47:42 zyntp[1708]: Set new system time. May 28 18:48:26 pppd[1538]: System time change detected. ...
В результате, например, vnstat
категорически не желает работать с ppp0, если запускается до появления соединения. На примере vnstat
приведу возможное решение проблемы.
В S12vnstatd
вносим изменения: добавляем путь к дампу (по нужному Вам интерфейсу), обновление данных интерфейса, само получение дампа, рестарт vnstatd если не запущен и др. В примере ниже - интерфейс ppp0
, то есть, например, медленный модем.
#!/bin/sh MOUNT="/media/DISK_A1/system" VBIN="$MOUNT/usr/sbin/vnstatd" VPID="$MOUNT/var/run/vnstat.pid" STAT="$MOUNT/www/vnstat/stat" export PATH=$MOUNT/bin:$MOUNT/sbin:$MOUNT/usr/bin:$MOUNT/usr/sbin:/sbin:/usr/sbin:/bin:/usr/bin export LD_LIBRARY_PATH=$MOUNT/lib:$MOUNT/usr/lib:/lib:/usr/lib daemon_status () { [ -f $VPID ] && [ -d /proc/`cat $VPID` ] } start_daemon() { $VBIN -d -p $VPID } stop_daemon() { kill `cat $VPID` } reload_daemon() { kill -HUP `cat $VPID` } case "$1" in start) if daemon_status then echo vnstatd already running else start_daemon fi ;; stop) stop_daemon ;; restart) stop_daemon sleep 1 start_daemon ;; reload) reload_daemon ;; status) if daemon_status then echo Running else echo Not running fi ;; dumpdb) if daemon_status then vnstat -u -i ppp0 vnstat --dumpdb -i ppp0 > $STAT/vnstat_dump_ppp0 else start_daemon fi ;; link_up) ;; ppp_up) ;; link_down) ;; ppp_down) ;; *) echo "Usage: $0 {start|stop|reload|restart|status|dumpdb|link_up|link_down|ppp_up|ppp_down}" ;; esac
Затем добавляем задание в crontab
(для проверки - 1 минута, потом заменяем, например, на 5):
*/1 * * * * /media/DISK_A1/system/etc/init.d/S12vnstatd dumpdb
Если «на ходу» выдернуть модем из разъёма USB, а потом присоединить, то, как ни странно, vnstat
продолжает работать, так что с разрывами соединения он и сам разбирается.
Аналогично можно поступить с иными приложениями, отказывающимися запускаться без соблюдения каких-либо предварительных условий.
Вторая проблема - когда нужна синхронизация времени по NTP, а подключения к сети интернет ещё нет, то приложения, критичные к астрономическому времени, оказываются запущены до подключения. В этом случае можно наблюдать, например, в статистике http-сервера, что он проработал много-много времени, а реально его запустили только что. Лично мне это не нравится)
Возможное решение - использовать лог zyntp, что находится в /tmp. Заодно решим другим способом первую проблему - с ниаличием подключения к сети интрнет при запуске - что критично, например, для davfs (помнится, просто давали задержку перед монтированием)… Хотя для этого можно использовать ping, но если мы не спешим - то пойдёт и zyntp.
Если время было получено, появится файл /tmp/zyntp.log и в нём будет строка с символами »→». Тогда можно использовать такую проверку:
#!/bin/sh local i=60 while [ $i -gt 0 ] ; do if [ -f /tmp/zyntp.log ] then if grep -q \\-\> /tmp/zyntp.log then break fi fi sleep 1 i=$((i-1)) done;
где «i=60» - задержка на 60 секунд, если за это время нет подключения, всё равно продожить.
Однако, в примере - 60 секунд - и, если использовать такой метод для http сервера, то он будет недоступен до подключения к сети интернет или до истечения интервала, и недоступен будет в том числе в локальной сети. Поэтому для http сервера можно перезапустить сервер, если обнаружилось подключение к сети интернет; ниже - фрагмент из S50lighttpd
для примера:
echo Starting lighttpd daemon... local i=0 while [ $i -lt 60 ] ; do if [ -f /tmp/zyntp.log ] then if grep -q \\-\> /tmp/zyntp.log then if [ $i -ne 0 ] then stop_daemon fi start_daemon break fi fi if [ $i -eq 0 ] then start_daemon fi sleep 1 i=$((i+1)) done;