Что с "сервером" bridge не так ума не приложу.
Один и тот же rtorrent.
Регулятрно падает на bridge (каждую ночь) - но тот же rtorrent на mine - имеет аптайм с момента переустановки сервера (правда ядро ещё старое - всё никак не дойду перезагрузить его).
Теперь вот с nginx столкнулся.
Мой старый пост на почтовый туннель до черезчур бдительного/жадного провайдера
(разблокирует доступ из внешки на локальные pop3 ящики только за деньги) - не сработал.
Тот же конфиг. Та же версия nginx. На майне работает - на бридже нет.
Выдаёт в логах:
socket() failed (97: Address family not supported by protocol) while in http auth state, client: 127.0.0.1, server: 0.0.0.0:110, login: "xxx"
Ну оно и понятно - по strace он вызывает
socket(0x2058, SOCKET_STREAM,0) - что естественно EAFNOSUPPORT
(хм. версия 0.7.65 "из коробки" выдавала другое число: 0x55c8 - сейчас версия 0.8.50)
Прокинул натом 110 порт через туннель на mine.. Но это не дело..
Отлаживать попробовал - удалённо даже разобрался в gdb как -
но как-то не впечатляет пока отладка в консоли :)
2010-09-13
2010-09-10
rtorrent with screen под супервайзером
rtorrent из svn стал падать на быстром канале чаще чем никогда.
Соответственно возникла задача его супервайзить.
Работающие супервайзеры от DJB способствовали.
Но поскольку rtorrent на ncurses - да ещё и под screen - чтобы можно было детач-аттач делать,
то встал вопрос как мониторить живость процесса.
(pidof / ps ax) && sleep - некошерно.
cron - то же и некошерно.
Даже мониторить живость сокета screen через inotify. Всё равно много телодвижений.
Сделал так (после стандартной отправки в бекграунд с screen -dm):
exec strace -s 16 -p `pidof -sc SCREEN` &> /dev/null
велосипед, однако достаточно надёжно и мало ресурсоёмко :)
Пойдёт любой супервайзер runit, daemontools, и даже, наверно, upstart..
Соответственно возникла задача его супервайзить.
Работающие супервайзеры от DJB способствовали.
Но поскольку rtorrent на ncurses - да ещё и под screen - чтобы можно было детач-аттач делать,
то встал вопрос как мониторить живость процесса.
(pidof / ps ax) && sleep - некошерно.
cron - то же и некошерно.
Даже мониторить живость сокета screen через inotify. Всё равно много телодвижений.
Сделал так (после стандартной отправки в бекграунд с screen -dm):
exec strace -s 16 -p `pidof -sc SCREEN` &> /dev/null
велосипед, однако достаточно надёжно и мало ресурсоёмко :)
Пойдёт любой супервайзер runit, daemontools, и даже, наверно, upstart..
2010-09-09
IPv6 && aptitude
Доигрался. Скоростной интернет канал которым разжился на прошлой неделе начали ограничивать ipv6 туннели.
Нативной поддержки у провайдера ipv6 адресов не планируется - а внешний туннель даёт от силы 1 мегабит.
Это пол беды. apt-get update && install настроены на внешнее зеркало ru.archive.ubuntu.com
которое в числе прочих даёт ipv6 адрес 2a02:6b8:0:201::1
Вот только аптитьюд (или libc) не рандомизирует список адресов - точнее порядок следования ipv6 и ipv4 адресов. И выдаёт видимо сначала ipv6. Что вынуждает аптитюд лезть в интернет через медленный ipv6 туннель. round-robin не заработал :)
Блокируем роутинг на неугодный адрес - и скорость обновления-установки взлетает с 1 мегабита до 1 мегабайта - что есть гуд :)
ip -6 route add 2a02:6b8:0:201::1 dev lo
Нативной поддержки у провайдера ipv6 адресов не планируется - а внешний туннель даёт от силы 1 мегабит.
Это пол беды. apt-get update && install настроены на внешнее зеркало ru.archive.ubuntu.com
которое в числе прочих даёт ipv6 адрес 2a02:6b8:0:201::1
Вот только аптитьюд (или libc) не рандомизирует список адресов - точнее порядок следования ipv6 и ipv4 адресов. И выдаёт видимо сначала ipv6. Что вынуждает аптитюд лезть в интернет через медленный ipv6 туннель. round-robin не заработал :)
Блокируем роутинг на неугодный адрес - и скорость обновления-установки взлетает с 1 мегабита до 1 мегабайта - что есть гуд :)
ip -6 route add 2a02:6b8:0:201::1 dev lo
Подписаться на:
Сообщения (Atom)