[Spread-users] Sess_recv_client_auth: BUG! Session is alreadyauthorized (status 0x1)

[Jonathan Stanton]

Ok. I've looked at the code and thought about it. I have a theory. Can you
run the spread monitor (spmonitor) and use option 0 to display the stats
for the daemon which the agent is attached to? One of the fields it shows
it the "num_sessions" which representst the number of sessions attached to
that daemon. Can you include that monitor output in an email and tell me if
the num_sessions looks like it is larger then what it should be (i.e. if
your system is quiescent and only the agent shold be connected to spread,
but the num_sessions variable says "2" for example).

I think I see a race condition whereby when we call 'accept()' to accept a
new connection, that new connection is given the same file descriptor (in
the daemon) as a previous connection had. However, the daemon doens't yet
know that the previous connection has closed, only the kernel does. So the
kernel reuses the filedescriptor and we confuse the states of the two
sessions (one that completed connecting and then closed, the other of which
has just begun to connect) and as a result get the error you experienced.

I was going to include a quick patch for this, but as I was working on it I
found that my initial approach to fixing it won't work I think. I'll work
on it more. If you can verify that these 'extra' sessions exist in the
monitor that would help validate that I've found the problem.


On Mon, Oct 22, 2001 at 03:07:32PM -0700, Dave Parker wrote:
> Now, when the agent parent process forks, it's forking instances of the
> parent's connection object as well.  I'm not *using* that object, but
> it's in the forked process, and when the child dies the destructor gets
> called.  Could I potentially be getting into trouble with this?
> 

I think this is fine. It is normal to inherit fd's accross a fork and if
you close it in the child that should not cause any problems for the
parent.


Thanks,

Jonathan

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------