Да, но главное, чтобы таймаут ошибки был меньше таймаута неактивности. А сейчас наоборот, из-за того, что я не нашел как в ноде устаналивать таймаут, по которому создатся ошибка ETIMEDOUT.
Вернее, я ввожу в заблуждение. Конечно событие error должно появится. С кодом ошибки: ETIMEDOUT.
Но я не обнаружил, как настраивается этот таймаут. Системно? В результате таймаут неактивности (событие timeout у сокета) у меня срабатывает раньше, поскольку таймаут короткий. Видимо, дело в этом...
Проблема в том, что когда срабатывает таймаут неактивности, я не могу понять - просто устройство перестало отвечать на прикладном уровне, но последний мой пакет к нему оно поймало. Или заглохло всё на уровни сети и последний пакет не добрался? Или ACK на него...
Нет, не происходит этого события. Например, отправляем пакет из ноды на устройство, а в ответ ничего.
По тисипдампу только видны повторы. А потом срабатывает таймут неактивности сокета.
Slava Kryvel: Согласен, но вот у меня было пониманием, как работает старый стиль, а как зависимости в upstart настроить - пока не разобрался. Тут-то проще, просто последовательность файлов. Кроме того, я обнаружил там скрипт запуск apache2. Ну, значит, имеет право на жизнь.
14.04.
Вообще да, upstart точно, может и systemd.
Но разве не сохранятся работа system-v стиля?
Вот у меня на сервере установлены mysql и apache. Среди /etc/init нет апачевского скрипта, зато он есть в rc.d-папках и апач стартует именно через system-v, а mysql наоборот, есть /etc/init/mysql.conf но нет в rc.d-папках, и стартует он получается через upstart.
Поскольку мне нужно увязать при reboot-е ожидаение выключения mysql с моим сервисом (который настроен через rc.d-папки) я сделал как описал. Т.е. mysql тоже теперь управляется через rc.d-папки.
Просто я пока не разобрался как зависимости в upstart настраивать.
Поэтому пока сделал в стиле system-v. Вопрос только в том почему игнорируется зависимость при выполнении update-rc.d
alegzz: Под init я подразумевал подсистему инициализации linux. При перезагрузке именно она, полагаю, занимается рассылкой SIGTERM. Я не очень разбираюсь в linux, но видимо мой вопрос всё-таки упирается в то, что SIGTERM не отправляется дочерним процессам. Если я запускаю скрипт прямо нодом из консоли, то он получит SIGTERM. А если через forever, то SIGTERM получает только forever и, поскольку его не обрабатывает, просто дохнет вместе со всеми потомками.
Значит, либо поискать возможность при начале перезагрузки выполнить forever.stopAll. Либо нафиг forever вообще.
alegzz: Вот тут я не уверен, возможно запущенные forever процессы его и не получат. Причина мне не известна. Я полагал, что если они не получают, то forever делает stopAll получая свой SIGTERM. Но в коде видно, что не делает. Вопрос, почему не получают дочерние? Рассылка точно есть.
alegzz: Как это? Почему же нет? Возможно это настраиваемо, но рассылается. По крайней мере процесс, запущенный в терминале
nohup nodejs app.js 1 >> consolg.log 2 >&1 &
и имеющий в коде обработчик сигнала SIGTERM, получит его при перезагрузке.
Если только дело в том, что процессы порождённые forever не получают SIGTERM от системы? А когда я пробую без foverer я запускаю из терминала через nohup, и в этом случае SIGTERM процесс ловит?
Так нет же, я как раз рассчитываю на то, что монитор forever получив SIGTERM либо сам рассылает SIGTERM по контролируемым процессам, либо хотя бы не шлёт им SIGKILL, чтобы они отреагировали на системный SIGTERM.
Да, и, если не затруднит, поясните сказанное по индексу на колонке dt. Имелось ввиду, что надо использовать DESC вместо ASC? Разве это влияет в случае, если индекс на одной колонке? Я не делал индекс на двух колонках id и dt. Там бы это имело наверное смысл.
Но где устанавливается в ноде? Нигде?