madwimax: вечное ожидание завершения скриптов if-*

[one_half_3544]

Hi!

Довольно часто madwimax не может дождаться того момента, как умрут
дети-скрипты. Т.е. затыкается на Starting if-* script и ждёт до упора.
При этом сам скрипт успешно отрабатывает. Если это происходит при
втыкании/вытыкании свистка, то на это можно не обращать внимания -
udev запустит новую копию madwimax, старая ей никак не мешает. Но при
подёргиваниях скрипта из-за плохой связи/проделок йотовцев (см.
http://groups.google.com/group/madwimax-dev/browse_thread/thread/bd53c7f46c7bca44
) получается нехорошо (обратите внимание на даты =)):
=== cut here ===
Dec 1 21:01:45 dls madwimax[7279]: State: NORMAL Number: 3
Response: 2
Dec 1 21:01:51 dls madwimax[7279]: RSSI: -42 CINR: 24.000000 TX
Power: 57344 Frequency: 2515000
Dec 1 21:01:51 dls madwimax[7279]: BSID: 00:00:15:02:12:d1
Dec 1 21:01:51 dls madwimax[7279]: Starting if-down script...
Dec 2 09:17:13 dls madwimax[16290]: Bus 001 Device 001: ID 1d6b:0001
Dec 2 09:17:13 dls madwimax[16290]: Bus 002 Device 001: ID 1d6b:0001
Dec 2 09:17:13 dls madwimax[16290]: Bus 001 Device 008: ID 04e8:6761
Dec 2 09:17:13 dls madwimax[16290]: Device found
=== cut here ===

Ну и плюс неэстетичная куча madwimax'ов в списке процессов:
=== cut here ===
% ps ax | grep madwimax
6734 ? S<s 0:00 /usr/local/sbin/madwimax -vvvvodf --exact-
device=1 4
6781 ? S<s 0:38 /usr/local/sbin/madwimax -vvvvodf --exact-
device=1 5
7215 ? S<s 0:00 /usr/local/sbin/madwimax -vvodf --exact-
device=1 6
7279 ? S<s 20:33 /usr/local/sbin/madwimax -vvodf --exact-
device=1 7
16290 ? S<s 0:00 /usr/local/sbin/madwimax -vvodf --exact-
device=1 8
17109 ? S<s 3:12 /usr/local/sbin/madwimax -vvodf --exact-
device=1 9
=== cut here ===

Процессы ждут в каком-то системном вызове (wait3() в
sighandler_wait_child()? Хотя он вроде неблокирующим должен быть
(WNOHANG))
=== cut here ===
(gdb) bt
#0 0xb7f28424 in __kernel_vsyscall ()
#1 0xb7e8db53 in ?? () from /lib/i686/cmov/libc.so.6
#2 0xb7e12ed9 in ?? () from /lib/i686/cmov/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
=== cut here ===

Система - обычный линукс 2.6.26. У кого-нибудь такое проявляется?

[one_half_3544]

On Dec 2, 3:00 pm, one_half_3544 <onehalf3...@gmail.com> wrote:
>
> Процессы ждут в каком-то системном вызове

> === cut here ===
> (gdb) bt
> #0  0xb7f28424 in __kernel_vsyscall ()
> #1  0xb7e8db53 in ?? () from /lib/i686/cmov/libc.so.6
> #2  0xb7e12ed9 in ?? () from /lib/i686/cmov/libc.so.6
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> === cut here ===

Вобщем таки действительно нужно быть аккуратнее и не вызывать из
обработчиков сигналов всякие разные функции (И не модифицировать
внешние, по отношению к обработчику, переменные за исключением
sig_atomic_t). В данном случае видимо сам syslog() (через wm_log())
затыкается. См. http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-09/msg08695.html

[one_half_3544]

Погонял некоторое время - проблема исчезла, так что действительно в
этом дело. Быстрое решение - просто не писать в лог код заврешения
скрипта:
=== cut here ===
===================================================================
Index: wimax.c
===================================================================
--- wimax.c (revision 174)
+++ wimax.c (working copy)
@@ -835,7 +835,6 @@
static void sighandler_wait_child(int signum) {
int status;
wait3(&status, WNOHANG, NULL);
- wmlog_msg(2, "Child exited with status %d", status);
}

int main(int argc, char **argv)
=== cut here ===