Re: ldirectord fork a new daemon?

Horms <horms <at> verge.net.au> writes:

> > 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/perl5-porters <at> 
perl.org/msg85468.html
> > 	unless(defined($ENV{'PERLIO'})) {
> > 		$ENV{'PERLIO'} = "perlio";
> > 		exec_wrapper($0,  <at> 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.
> 

Dear Horms,

Thx for your reply. After viewing your advice, I go to have a detail look of 
the rsh from the man page and discover that there is a bug with rsh. I have 
copy that part as below

BUGS
       If  you  are  using  csh(1)  and put a rsh(1) in the background without
       redirecting its input away from the terminal, it will block even if  no
       reads  are  posted  by  the remote command.  If no input is desired you
       should redirect the input of rsh to /dev/null using the -n option.

After adding the -n attribute, the time_wait disappear. 

Eric





-- 
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.