[omniORB] Conflict with other ORBs?

Brent Fulgham brent.fulgham@xpsystems.com
Mon, 20 Dec 1999 15:39:48 -0800


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF4B43.84D0696A
Content-Type: text/plain;
	charset="iso-8859-1"

> > [ ... omniorb in the background seems to die when
> > GNOME is running ...]
> 
> > However, if I terminate X (CTRL-ALT-BACKSPACE) omniorb gets killed
> > along with everything running under X.  I don't think this is the
> > only case where omniorb gets killed, because I have experienced
> > omniorb stopping even when I have not terminated X.
> 
> Is this when omniNames is running in an Xterm?  Or started from one
> and running in the background?  If not, killing X shouldn't have any
> effect on omniNames.
> 
Right.  omniNames starts up during system boot (init.d script).  I
can't explain the X11 connection.

> Unless anyone else is seeing this problem, I can only assume that
> there's something very strange about your set-up.
> 
Possibly.  I just noticed that if I start the name server up at the
console (as root:  bash# omninames -start) without passing PORT or
hostname data, things seem to work fine.  I am wondering if we might
be seeing the same "bug" we spoke about last week, wherein a slight
typo in the BOA initializaton string might cause a lock condition
or "denial-of-service" type of problem.

In this case, my X11 connection might just have been simple
coincidence.

I will modify my startup script and see how this affects things.

Thanks,

-Brent

------_=_NextPart_001_01BF4B43.84D0696A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: [omniORB] Conflict with other ORBs? </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; &gt; [ ... omniorb in the background seems to die when</FONT>
<BR><FONT SIZE=2>&gt; &gt; GNOME is running ...]</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; However, if I terminate X (CTRL-ALT-BACKSPACE) omniorb gets killed</FONT>
<BR><FONT SIZE=2>&gt; &gt; along with everything running under X.&nbsp; I don't think this is the</FONT>
<BR><FONT SIZE=2>&gt; &gt; only case where omniorb gets killed, because I have experienced</FONT>
<BR><FONT SIZE=2>&gt; &gt; omniorb stopping even when I have not terminated X.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Is this when omniNames is running in an Xterm?&nbsp; Or started from one</FONT>
<BR><FONT SIZE=2>&gt; and running in the background?&nbsp; If not, killing X shouldn't have any</FONT>
<BR><FONT SIZE=2>&gt; effect on omniNames.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>Right.&nbsp; omniNames starts up during system boot (init.d script).&nbsp; I</FONT>
<BR><FONT SIZE=2>can't explain the X11 connection.</FONT>
</P>

<P><FONT SIZE=2>&gt; Unless anyone else is seeing this problem, I can only assume that</FONT>
<BR><FONT SIZE=2>&gt; there's something very strange about your set-up.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>Possibly.&nbsp; I just noticed that if I start the name server up at the</FONT>
<BR><FONT SIZE=2>console (as root:&nbsp; bash# omninames -start) without passing PORT or</FONT>
<BR><FONT SIZE=2>hostname data, things seem to work fine.&nbsp; I am wondering if we might</FONT>
<BR><FONT SIZE=2>be seeing the same &quot;bug&quot; we spoke about last week, wherein a slight</FONT>
<BR><FONT SIZE=2>typo in the BOA initializaton string might cause a lock condition</FONT>
<BR><FONT SIZE=2>or &quot;denial-of-service&quot; type of problem.</FONT>
</P>

<P><FONT SIZE=2>In this case, my X11 connection might just have been simple</FONT>
<BR><FONT SIZE=2>coincidence.</FONT>
</P>

<P><FONT SIZE=2>I will modify my startup script and see how this affects things.</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
</P>

<P><FONT SIZE=2>-Brent</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF4B43.84D0696A--