pluto not responding -- possibly not re-entrant (updown)

Hi Folks --

I've managed to get pluto into a state where it isn't
responding:

time ipsec auto --status
... bored now ... ^C

real    3m54.604s
user    0m0.000s
sys     0m0.040s


I notice some weird things in the ps listing.
   http://www.av8n.net/tmp/bad1-ps.txt

However the fact that the _downup script for one
conn runs as the descendent of the _downup for
another conn isn't as weird as you might think;
it's because I put a --replace command in my
_downup script.
   http://www.monmouth.com/~jsd/vpn/_downup
I thought this was legal;  nobody ever told me
that pluto was non-reentrant.

Things ran fine for ten days or so before hanging.
Therefore my first hypothesis was that it was a
race condition.  But after looking at the code,
I'm suspecting a plain old deadly embrace;  it
may be that this part of my _downup script had
not been exercised previously.

 >>>> If it is not allowed to put ipsec auto commands
in updown scripts, this needs to be documented. <<<<<<

Actually, if this is not allowed, it would be friendly
to defend against it, perhaps by making a run-time
check on the pgid.

Here's a traceback:
(gdb) where
#0  0x40142544 in __libc_read () from /lib/i686/libc.so.6
#1  0x40198154 in __DTOR_END__ () from /lib/i686/libc.so.6
#2  0x400dd42d in _IO_new_file_underflow (fp=0x80a19c8) at fileops.c:542
#3  0x400dfcc9 in _IO_default_uflow (fp=0x80a19c8) at genops.c:420
#4  0x400decff in __uflow (fp=0x80a19c8) at genops.c:377
#5  0x400d456d in _IO_getline_info (fp=0x80a19c8, buf=0xbffff000 "", 
n=255, delim=10, extract_delim=1, eof=0x0) at iogetline.c:71
#6  0x400d464d in _IO_getline (fp=0x80a19c8, buf=0xbffff000 "", n=255, 
delim=10, extract_delim=1) at iogetline.c:41
#7  0x400d3494 in _IO_fgets (buf=0xbffff000 "", n=256, fp=0x80a19c8) at 
iofgets.c:50
#8  0x0805b006 in do_command (c=0x80a12f8, verb=0x807c13a "up") at 
kernel.c:885
#9  0x0805dc45 in route_and_eroute (c=0x80a12f8, st=0x80a1cc8) at 
kernel.c:2362
#10 0x0805dfcd in install_ipsec_sa (st=0x80a1cc8, inbound_also=0) at 
kernel.c:2518
#11 0x0805a095 in quick_inI2 (md=0x809ee38) at ipsec_doi.c:3486
#12 0x08060a4d in process_packet (mdp=0x808bb9c) at demux.c:1663
#13 0x0805f5f4 in comm_handle (ifp=0x809e4e8) at demux.c:881
#14 0x08052a4f in call_server () at server.c:798
#15 0x08051368 in main (argc=4, argv=0xbffffb54) at main.c:441
#16 0x4007e507 in __libc_start_main (main=0x8050d74 <main>, argc=4, 
ubp_av=0xbffffb54, init=0x8049894 <_init>, fini=0x80749f0 <_fini>,
     rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffffb4c) at 
../sysdeps/generic/libc-start.c:129



The barf is available:
http://www.av8n.net/tmp/barf1.txt

I've left it in the bad state for now.  Please let me
know if you want me to make any more observations on it.