keshaLG

нехорошо - это отвечать N-ное кол-во раз на звонки в саппорт, как попугай, если можно это сделать все со стороны сервера. Мы (коммунити) разрабатываем систему для себя или юзеров и производителей винды? Извините, а как тогда "стандартные системы обновлений" у людей работают? или они купили у мелкософта спецификации? PS про *nix - не говорю, тут да, жестко все.

сколько каналов люди смотрят, нет возможности посмотреть... 20...30% примерно от всего кол-ва

Было бы не плохо, в авторизаторе предусмотреть "кнопочку - 'Обновить ПО isp'", и реализовать программно автообновление с http или ftp сервера. - Считаю очень удобным, чем каждому расказывать, что/где/как и и т.д.

система многофакторная и многоуровневая, я бы разложил все "по полочкам" (для начала показал, что на буке саппорта кабель работает). А дальше связка usb-сетевая + бук клиента - за доп. оплату, хотя случай нестандартный явно), видимо "гроза" чего-то подпалила явно.

вот срез top: top - 18:38:10 up 4 days, 1:42, 1 user, load average: 1.32, 1.16, 1.06 Tasks: 109 total, 1 running, 108 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 1.3%sy, 29.0%ni, 68.0%id, 0.0%wa, 0.0%hi, 1.7%si, 0.0%st Cpu1 : 0.0%us, 3.3%sy, 33.0%ni, 55.3%id, 0.0%wa, 0.7%hi, 7.7%si, 0.0%st Mem: 2074332k total, 1199132k used, 875200k free, 191752k buffers Swap: 2097144k total, 0k used, 2097144k free, 665288k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 692 root 15 0 537m 72m 3908 S 21.0 3.6 6:35.03 vdr 702

[kesha@dvb ~]$ cat /proc/cpuinfo |grep "model name" model name : Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz dvb-карты Technotrend TT-budget S-1401 плата от Giga-byte на ICH10 сhip Family c 5ю PCI-слотами. Каналов - все доступные на транспондере, ну сколько там у плюсов в среденем...10...14? машина сильно не нагружена, в пиках до 200Мбит нагрузка

у меня "реально декодирует", только вот тут уже проблема найти такой шаринг, что бы столько позволял запросов слать)), ну или свой сделать)

все каналы с транспондера может VDR с сц "раскрывать"

ну Вы поправили мою цитату, для кодированых используем vdr c плагином "s c"

Совершенно верно! Для этого использую проверки через nrpe nagios-a на софтом роутере в этих сегментах.

дешевое - это в пределах? уже придумано: PC + dvb-карты + VLC (vdr)

ну если unixtime, - то поддержую важность данного вопроса... походу надо конфигуратор править, да и в базу бы писать это надо, для отображения вне конфигуратора... хотя icmp не показатель, сам использую проверки arping-ом. ps rem_lex взаимно коллега)

+1 присоединяюсь к замечанию о логах

помоему это "фича", если делать как ты говоришь надо еще и дату "помнить". А вообще замечание хорошое.

пропатчил, заменил mod_store_postgresql.so, "дёрнул" - запустился нормально и база в норме. Спасибо

да, но на момент старта СТГ база была "причесана" и была в актуальносм состоянии. Ну допустим один два параметра "ошибочный скрипт" меняет, но это массово как вы видите... да и статистике я уверен - там все через sgconf меняется

rc.d-скриптом из rpm root@stg bin]# cat /etc/rc.d/init.d/stargazer |grep -8 stop .... stop() { # Stop daemons. echo -n $"Shutting down $prog: " /etc/stargazer/first 2>> /var/log/stargazer.log killall -g stargazer RETVAL=$? /etc/stargazer/last 2>> /var/log/stargazer.log echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/stargazer return $RETVAL } .... кстати, секция restart - работает некорректно (не стартует сервис). Ну если сервер в памяти держит эти параметры, значит он и смещает их местами при записи?

Тогда я в тупике... У меня сервер в аптайме уже долго: [root@stg dhcp]# uptime 11:39:11 up 19 days, 18:10, 2 users, load average: 0.00, 0.02, 0.06 [root@stg dhcp]# т.е. сервер был в "самостоятельном плавании", по логам статистики sgconf не использовался в период когда у "eric111" сбилось все. На днях был тоже случай, когда после "мягкого рестарта": service stargzer stop service stargzer start случилось тоже самое: 2010-07-01 19:48:55 -- Admin 'kesha', 10.9.2.2: User 'kredo': 'userdata0' parameter changed from '00:0E:E8:09:7E:D5' to '3584'. 2010-07-01 19:48:55 -- Admin 'kesha

жесткий ребут. гуевый ("виндовый"): 1.91.9 консольный: с пакета "Sgconf version: 1.08.9" меня смущает то, что по словам пользователя eric111 - "сбилось" у него все после 00-00 до этого все работало четко. А ночью никто не работал конфигуратором и не лазил к сервер -> следовательно что-то не так в логике сервера

версия одноименная с темой данного топика, хранилище postgresql. Изменения делают потом с конфигуратора, есть конечно php-статистика, но она только читает с базы, изменения напрямую пишет в свои таблицы, те что использует STG изменяем через sgconfig. os: CentOS 5 Перед этим тестировал на маленькой сети предыдущую версию - было тоже самое - мейтейнер заметил, что чаще всего это было после "внезапного стопа" сервера. PS если нужно я даже могу как-то мотивировать устранение данного бага, что бы пооперативнее было, а то уже переполз на данный rc в продакшн - страдает качество сервиса...

люди хелп: СТГ беспорядочно сам переставляет userdata# местами, даже когда его никто не трогает, вот пример: [root@stg stargazer]# grep eric111 /var/log/stargazer.log 2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata0' parameter changed from '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F' to '256'. 2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata1' parameter changed from '' to '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F'. 2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata8' parameter changed from '10.9.8.12' to ''. 2010-06-15 14:41:1

на одном, разаботало после того, как снял/установил флаг "всегда онлайн"

дистр: CentOS 5 (RH), скрипты использую из rpm из соседнего одноименного топика, запускаю все по средствам SysV-init: [root@stg db_backups]# ls /etc/rc.d/rc3.d/|egrep "post|star|rad|pptp" S64postgresql S87stargazer S88radiusd S89pptpd по сути все по очереди, только на практике получается, как я писал... А какие есть варианты запуска по зависимостям? База на postgresql - за 5 дней работы - 200Мб (решил писать дет.статистику только пометровки, что бы меньше была). Кстати, а по какому принципу потом "чистить" таблицу дет.статистики, да и вообще базу, что бы "мусор" не хранить и не сломат

имхо: один большой плюс, а минус, что могут 2й сервер запустить "лантухи". но тут правильно сказали dhcpdrop - тут рулит

))) значит сервер СТГ вещался из-за магнитных бурь или всплеской солнечной активности... чудом совпадающие с вызовом консольного конфигуратора ))) ладно проехали, а по существу вопрос появислся: ребутнули сервер с виртуалками где СТГ живет, и получили: 2010-06-16 17:29:11 -- Storage plugin: 'FATAL: система баз данных стартует видимо база выросла очень...и это 3 дня работы на новой версии только, а будет как Вы говорите в гигах база... СТГ запускатся скриптами из rpm Вопрос: как оптимизировать запуск, что бы такого не было? Скриптом rc.local все по очереди с использование sleep n