[Mimedefang] mimedfang processes not dying

[zareh at dslextreme.com]

zareh at dslextreme.com
> Hi all,
>
> I'm seeing a strange behavior in mimedefang, I can kill
> mimedefan-multiplexor but cannot kill mimedefang itself, other then
> sending it a kill -9, running linux kernel 2.4.26 with procps 3.2.1,
> mimedefang compiled using gcc 3.3.3 with glibc 2.3.3, here are the
> details:
>

[snipped for brevity ]

Sorry... for replying to my own post, but I spent a few hours looking for
more clues, heres what I've found, when mimedefang starts it spawns 2
child processes:

# pstree -p | grep mime
        |-mimedefang(5268)---mimedefang(5269)---mimedefang(5270)

The parent is constantly doing 'select', the 1st child is doing 'poll' and
the 2nd child is in 'rt_sig' state.

# ps -Alw -y -H | grep mime
S   UID   PID   PPID  C PRI  NI  RSS    SZ     WCHAN  TTY    TIME         CMD
S   125   5268     1    0  69   0   760     1009  select     ?       
00:00:00   mimedefang
S   125   5269  5268  0  69   0   760     1009  poll        ?       
00:00:00     mimedefang
S   125   5270  5269  0  69   0   760     1009  rt_sig     ?       
00:00:00       mimedefang

Doing an strace on each process shows the same thing, except for the last
child, 5270 which doesnt seem to be doing anything at all:

# strace -p 5268
process 5268 attached - interrupt to quit
select(7,  [6], NULL,  [6],  {1,  270000})  = 0 (Timeout)
select(7,  [6], NULL,  [6],  {5,  0} )          = 0 (Timeout)
select(7,  [6], NULL,  [6],  {5,  0} )          = 0 (Timeout)
etc...

#strace -p 5269
process 5269 attached - interrupt to quit
getppid()                                                =0
poll{[{fd=4,  events=POLLIN}],  1, 2000)  =0
getppid()                                                =0
poll{[{fd=4,  events=POLLIN}],  1, 2000)  =0
etc..

# strace -p 5270
process 5270 attached - interrupt to quit

and nothing is shown...

Now if I send a kill signal to the parent (5268) nothing occurs, but if I
kill the 2nd child, (5270), mimedefang shutsdown and goes away.

What does 'rt_sig' mean?

Has anyone seen this behavior before?

Can anyone help me with this please, I've tryed upgrading to kernel 2.4.28
rebuilding mimedefang v2.49, downgrading to 2.48...

I'm really at a loss here and I'm willing to try anything.