From: grahn+nntp@snipabacken.se   
      
   On Sun, 2010-04-25, Barry Margolin wrote:   
   > In article ,   
   >  Jorgen Grahn  wrote:   
   >   
   >> On Fri, 2010-04-23, Barry Margolin wrote:   
   >> > In article ,   
   >> >  Jorgen Grahn  wrote:   
   >> >   
   >> >> On Thu, 2010-04-22, Barry Margolin wrote:   
   >> >> > In article ,   
   >> >> >  Jorgen Grahn  wrote:   
   >> >> >   
   >> >> >> On Tue, 2010-04-20, Singh wrote:   
   >> >> >> > Hi,   
   >> >> >> > I am developing a daemon which will monitor an agent running on a   
   >> >> >> > linux system. A client from some other host connects to the agent   
   and   
   >> >> >> > performs some work, once the client disconnects i need to stop that   
   >> >> >> > agent.   
   >> >> >>   
   >> >> >> It would be much, much better if the agent could stop itself. Or be   
   >> >> >> implemented as an inetd service, so it happens automatically[1].   
   >> >> >>   
   >> >> >> The way the design looks now ...   
   >> >> >>   
   >> >> >> > for that i need to get the information in the daemon when the   
   >> >> >> > client's connection close to the agent so that i can proceed to stop   
   >> >> >> > the agent from the daemon running.   
   >> >> >>   
   >> >> >> ... it's not really a networking question in the normal sense. It's   
   >> >> >> a Linux process monitoring question.   
   >> >> >>   
   >> >> >> /Jorgen   
   >> >> >>   
   >> >> >> [1] I guess inetd services still need to implement their own timeouts   
   >> >> >>     though.  I'm not 100% sure about that, and too lazy to RTFM.   
   >> >> >   
   >> >> > Inetd uses a completely different model.  It starts a new instance of   
   >> >> > the server for each connection, there's no single agent   
   >> >> > that needs to be stopped.   
   >> >>   
   >> >> Yes. My concern was that if the peer host disappears, he may need   
   >> >> timeouts in the agent to avoid TCP connections (and thus agenty   
   >> >> processes) hanging for a long time.  I have a feeling such problems   
   >> >> is the reason he wants something monitoring the agent ...   
   >> >   
   >> > That's orthogonal to the problem he's trying to solve.   
   >>   
   >> Is it? I fail to see how. Unless the agent cannot be modified -- then   
   >> all of what I wrote is of no use to him.   
   >>   
   >> The part of his question quoted above seems like a perfect match for   
   >> inetd, except if his agent doesn't have timeouts in the right places.   
   >   
   > I don't see how.  Inetd never stops the agent.  It starts the agent when   
   > a connection comes in, but the agent is expected to exit by itself when   
   > it's done, which may be when the client closes the connection, or after   
   > a timeout.   
      
   We agree on the facts, so I think we mean the same thing. If he can   
   change the agent to guarantee that it always exits, then he can use   
   inetd.   
      
   Maybe a crude hardcoded SIGALARM is enough. Maybe (if he cannot change   
   the agent) wrapping it in a process which forks the agent and then   
   kills it after 60 seconds is enough.   
      
   -Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)