freeradius теперь нет в портах

[dimia]

Хмм ... после установки freeradius2 по инструкции из документации N+ обнаружилась одна неприятная весчь:

freeradius2 умирает со следующей диагностикой

Код:

Sun Nov 10 03:01:38 2013 : Error: Received conflicting packet from client bras1 port 29096 - ID: 202 due to unfinished request 446707.  Giving up on old request.
Sun Nov 10 03:01:38 2013 : Error: Received conflicting packet from client bras1 port 23768 - ID: 113 due to unfinished request 446708.  Giving up on old request.
Sun Nov 10 03:01:38 2013 : Error: Received conflicting packet from client bras1 port 57671 - ID: 69 due to unfinished request 446709.  Giving up on old request.
Nov 10 03:01:38 billing kernel: pid 50337 (radiusd), uid 133: exited on signal 10

радиус падает, перестают идти keepalive'ы, и все становятся неавторизованными. Сразу же начинают звонить юзеры и дружно желать "доброго утра".
Хотя я использую версию 50.33, но проблема-то, видимо, общая. До этого freeradius1 с такой диагностикой никогда не падал. Вопрос: чего подкручивать? 8.3-RELEASE-p7 amd64, серверное железо, в логах больше ничего. Да, еще, в 03:01 запускается стандартный periodic daily

Код:

ls /etc/periodic/daily/                 
100.clean-disks         150.clean-hoststat      310.accounting          406.status-gmirror      430.status-rwho         480.status-ntpd
110.clean-tmps          200.backup-passwd       330.news                407.status-graid3       440.status-mailq        500.queuerun
120.clean-preserve      210.backup-aliases      400.status-disks        408.status-gstripe      450.status-security     800.scrub-zfs
130.clean-msgs          220.backup-pkgdb        404.status-zfs          409.status-gconcat      460.status-mail-rejects 999.local
140.clean-rwho          300.calendar            405.status-ata-raid     420.status-network      470.status-named

[dimia]

У freeradius2 обнаружилась серьезная проблема, которой не было у freeradius1 - если запрос находится в очереди более 30 секунд, то freeradius2 делает

Код:

kernel: pid 1709 (radiusd), uid 133: exited on signal 11

В нашем случае все запросы обслуживаются через rlm_sql_mysql, и если mysql начинает по какой-то причине тормозить (загрузка дисков либо системы), то freeradius2 просто падает. В частности, "стандартный" скрипт бэкапа nodeny:

Код:

#!/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
passwd_root_mysql=`perl -e'require "/usr/local/nodeny/history.nod"; print $sql_root_pass;'`
mysql_cmd='/usr/local/bin/mysql'
mysqldump_cmd='/usr/local/bin/mysqldump'

fl=`date "+%d-%m-%Y"`
cd /var/backups/
echo show tables | ${mysql_cmd} -u root --password=${passwd_root_mysql} bill | \
  grep -v '^[stuvxyz]2' | grep -v 'traf_info' | grep -v '^Tables' | \
  xargs ${mysqldump_cmd} -R -Q --add-locks -u root --password=${passwd_root_mysql} \
  --default-character-set=cp1251 bill $1 > bill_${fl}.sql
tar -c -j -f ${fl}.tar.bz2 bill_${fl}.sql
rm -f bill_${fl}.sql
chmod 440 ${fl}.tar.bz2

который выполняется у нас в системе в течении 47 секунд, стабильно каждую ночь убивает freeradius2 со всеми вытекающими последствиями. freeradius1 сильно ругался при работе этого скрипта, но никогда не вываливался.

В качестве костыля поставил freeradius2 под мониторинг программкой monit с таймаутом в 30 секунд. Пользователи не успевают отвалиться ... Стоит хорошо подумать, нужен ли такой апгрейд.

[versus]

Монит в любом случае дело хорошее, но бэкап я бы снимать начал без лока таблиц, есть же уже инструменты. скрипт с 5.0 кочует и кочует(( Пора уже посмотреть вокруг )

[dimia]

Монит в любом случае дело хорошее, но бэкап я бы снимать начал без лока таблиц, есть же уже инструменты. скрипт с 5.0 кочует и кочует(( Пора уже посмотреть вокруг )

В данном скрипте таблицы не блокируются.
--add-locks - Surround each table dump with LOCK TABLES and UNLOCK TABLES statements. This results in faster inserts when the dump file is reloaded.
не тоже самое, что
--lock-tables - For each dumped database, lock all tables to be dumped before dumping them.