Re: ldirectord fork a new daemon?

On Wed, Sep 07, 2005 at 03:41:08AM +0000, Eric Chan wrote:
> Horms <horms <at> verge.net.au> writes:
> 
> > 
> > On Tue, Aug 30, 2005 at 08:57:33AM +0000, Eric Chan wrote:
> > > Hi, 
> > > 
> > > We have modified the /usr/sbin/ldirectord perl script. The aim is to add a 
> > > check_process function using rsh to check for existence of remote process.
> > > 
> > > For the ldirectord, there is the below procedure
> > > 
> > > sub ld_daemon
> > > 
> > > This seems to cause our system call to rsh to fork a new daemon. 
> > > 
> > > system("rsh 192.168.0.111 ps -ef|grep java");
> > > 
> > > As a result, there are many time_wait for the port 514 (rsh listen port) on 
> the 
> > > ldirectord side. [netstat -na|grep 514 show many time_wait]
> > > 
> > > Is there any ways to solve this problem? We don't want to have so much 
> > > time_wait. Thx.
> > > 
> > > Best regards,
> > 
> > ld_deaemon() is run as part of ldirectord's initilalisation sequence
> > to detatch it from the terminal, and do other things that are
> > appropirate for a deamon. Once ldirectord is up and running,
> > it should not have any effect on child processes, unless
> > they expect to be attached to a terminal (perhaps rsh does).
> > 
> > On a related note, if you want to call system() from inside
> > ldirectord I recommend using system_wrapper()
> > 
> Dear Horms,
> 
> Thanks for your reply.I have carried out another test using a simple perl 
> script as below
> 
> #!/usr/bin/perl
> while(1){
>  system("rsh pct62 /tmp/alivetcp");
>  sleep 1;
> }
> 
> There is no time wait problem. It seems that the problem is not related to the 
> rsh.
> 
> I have put the above perl script within the ldirectord perl script as below and 
> the time wait problem occur.
> 
> 
> if ($opt_h) {
> 	&system_wrapper("/usr/bin/perldoc -U $LDIRECTORD");
> } else {
> 	# There is a memory leak in perl's socket code when
> 	# the default IO layer is used. So use "perlio" unless
> 	# something else has been explicitly set.
> 	# http://archive.develooper.com/[email protected]/msg85468.html
> 	unless(defined($ENV{'PERLIO'})) {
> 		$ENV{'PERLIO'} = "perlio";
> 		exec_wrapper($0, @OLD_ARGV);
> 	}
> 
> 	$initializing = 1;
> 	ld_init();
> 	ld_setup();
> 	ld_start();
> 	ld_cmd_children("start", %LD_INSTANCE);
> 	$initializing = 0;
> 	#ld_main();
>         while(1){
>            system("rsh pct62 /tmp/alivetcp");
>            sleep 1;
>         }
> }
> 
> 
> However, once I have comment the call to the &ld_daemon() within ld_init(), the 
> problem disappear.

I suspect the problem is that rsh expects a terminal,
however once &ld_daemon() has been called, there isn't one.

If you run ldirectord with the supervised directive in
the ldirectord.cf file, then it will not call &ld_daemon(),
it will not detatch from the terminal, and you should
be able to run rsh. 

Internally, your code could check for $SUPERVISED == 1,
and if this is not true then flag an error that the rsh
check will not work.

However, a better solution would be to have an implementation
of the rsh protocol that did not require a terminal. Perhaps
there is one on CPAN. If not, it should be easy enough to create.


-- 
Horms


-- 
Ultra Monkey - http://www.ultramonkey.org/
To UNSUBSCRIBE, email to [email protected], with a body:
unsubscribe ultramonkey-users [email protected]
where "[email protected]" is YOUR email address.