Yes, I underserstand.
Removing $ORACLE_SID from "dbi:Oracle:" forces the driver to look for
the service name in
environment variables $ORACLE_SID and $TWO_TASK.  If envirmonment
variable $ORACLE_SID is set,
the connection is local and a dedicated server is bequeathed (spawned)
directly.
Next a signal handler is set up to catch all SIGCHLD's, but
unfortuncately, catches
the child spawned by Perl's 'system' function.

The Net Services Admin Guide lists a sqlnet.ora flag to turn the signal
handler off.
BEQUEATH_DETACH = yes

The documentation says this leaves the job of catching the dedicated
server
to th 'Unix init process'.  I'm not sure what 'Unix init process' is,
but when I set the flag,
the Perl 'system' function catches the process it spawned and
the 'Unix init process' catches the 'dedicated server'.
No zombies left at the end.

My tsnames.ora and sqlnet.ora are in /mydir.
/mydir/sqlnet.ora contains 'BEQUEATH_DETACH = yes'.

export TNS_ADMIN=/mydir
perl -Mblib t/10general.t

This appears to work

thank you so much for your help.

Albert Tom
2600 Camino Ramon
San Ramon, Ca. 94583
925-823-9881



-----Original Message-----
From: Charles Jardine [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 17, 2008 9:23 AM
To: TOM, ALBERT K (ATTSI)
Cc: [email protected]
Subject: Re: DBD::Oracle install failed for fork test in t/10general.t


On 16/06/08 20:23, TOM, ALBERT K (ATTSI) wrote:
> Hi,
> 
> I'm installing DBD::Oracle 1.20 and I'm getting the following error
> from 't/10general.t'.
> 
> not ok 1 - system exit 1 should return 256
> #     Failed test (t/10general.t at line 45)
> #          got: '-1'
> #     expected: '256'
> not ok 2 - system exit 0 should return 0
> #     Failed test (t/10general.t at line 46)
> #          got: '-1'
> #     expected: '0'
 
I have seen this exact symptom reported before. I believe it happens
with Oracle 10 (but not with Oracle 9), the the 'bequeather' connection
methoid is usedd - fore example, by setting the environment variable
ORACLE_SID to the system identifier of a local database instance.

> I think something harvest the child that 'system' spawned before
> 'system' could reap it.

I think, thought I am not sure, that, in the 'bequeather' case,
Oracle sets a SIGCHLD handler in the perl scripts process.
This would break the test above, and also break perl's 'system'
built in, backticks, and all forms of '|' opens.

Avoid the bequeather.

> This is also puzzling.
> It works when I ran a script pointing to the 'blib'.
> Here is the script:
> 
> #!/usr/local/perl/bin/perl -w
> use lib '/tmp/at2191/tmp_perl/lib/perl5/site_perl';          # tmp lib
> containing DBI 1.604
> use blib '/tmp/at2191/install/dbd_orc/DBD-Oracle-1.20/blib'; # use
blib
> containing DBD 1.20
> use DBI qw(:sql_types :utils);
> print "$_\n" for @INC;
> 
> $ORACLE_SID  = 'uclde';
> $ORACLE_HOME = '/usr/local/opt/oracle/product/10.2.0';
> $ENV{'ORACLE_HOME'}     = $ORACLE_HOME;
> 
> $dbh = DBI->connect( "dbi:Oracle:$ORACLE_SID",

This form of connect will not use the 'bequeather'. You
have not set the ORACLE_SID environment variable.

>                      'ndpprod',
>                      'prod',
>                      { RaiseError => 0,
>                        PrintError => 1,
>                        AutoCommit => 0
>                      }
>                    ) ||
>            die "Database connection not made: $DBI::errstr";
> print "Database Name is $dbh->{Name}\n";
> 
> for (1, 0) {
>   $rc = system("exit $_;");
>   print "\$rc [$rc]\n";
>   print "\$!  [$!]\n";
> }
> 
> END {
>   $dbh->disconnect if $dbh;
>   print "end of script\n";
> }
> 
> The output from the script is:
> 
> /tmp/at2191/install/dbd_orc/DBD-Oracle-1.20/blib/arch
> /tmp/at2191/install/dbd_orc/DBD-Oracle-1.20/blib/lib
> /tmp/at2191/tmp_perl/lib/perl5/site_perl
> /appl_dsl/mod_perl/lib/perl5/site_perl
> /usr/local/cm58/lib/perl5/5.8.7/sun4-solaris-64
> /usr/local/cm58/lib/perl5/5.8.7
> /usr/local/cm58/lib/perl5/site_perl/5.8.7/sun4-solaris-64
> /usr/local/cm58/lib/perl5/site_perl/5.8.7
> /usr/local/cm58/lib/perl5/site_perl
> .
> Database Name is uclde
> $rc [256]
> $! []
> $rc [0]
> $! []
> end of script
> 
> I was wondering if anyone knows the cause of why the test in
> 't/10general.t' failed.
> 
> Albert Tom
> 2600 Camino Ramon
> San Ramon, Ca. 94583
> 925-823-9881
> 
> 


-- 
Charles Jardine - Computing Service, University of Cambridge
[EMAIL PROTECTED]    Tel: +44 1223 334506, Fax: +44 1223 334679

Reply via email to