Bug 3335 - TAO orbsvcs fail to daemonize when -ORBDaemon is specified.
Summary: TAO orbsvcs fail to daemonize when -ORBDaemon is specified.
Status: NEW
Alias: None
Product: TAO
Classification: Unclassified
Component: orbsvcs (show other bugs)
Version: 1.6.5
Hardware: All Linux
: P3 normal
Assignee: Iliyan Jeliazkov
URL:
Depends on: 3386
Blocks: 3656
  Show dependency tree
 
Reported: 2008-06-01 14:13 CDT by Ken Sedgwick
Modified: 2009-10-15 06:57 CDT (History)
3 users (show)

See Also:


Attachments
PRF posted to tao-bugs (2.41 KB, text/plain)
2008-06-01 14:13 CDT, Ken Sedgwick
Details
Patch adding app-level "--daemon" flag to orbsvcs (14.46 KB, patch)
2008-06-01 14:19 CDT, Ken Sedgwick
Details
Update to patch for x.6.9 changes (14.31 KB, patch)
2009-04-19 12:58 CDT, Ken Sedgwick
Details
Latest orbsvcs daemon patch. (14.16 KB, patch)
2009-07-27 12:06 CDT, Ken Sedgwick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Sedgwick 2008-06-01 14:13:52 CDT
Created attachment 980 [details]
PRF posted to tao-bugs

The following orbsvcs fail to daemonize when -ORBDaemon is specified on the command line:

TAO/orbsvcs/Naming_Service/Naming_Service
TAO/orbsvcs/CosEvent_Service/CosEvent_Service
TAO/orbsvcs/Notify_Service/Notify_Service
TAO/orbsvcs/Trading_Service/Trading_Service
TAO/orbsvcs/Event_Service/Event_Service
TAO/orbsvcs/Concurrency_Service/Concurrency_Service

The status of other services is unknown.

The TAO Naming_Service fails to daemonize.  It starts and initializes
but does not fork into the background.

To debug the problem I'm running the cosnaming service in a tmp
directory under the debugger.  [mkdir /tmp/tao-cosnaming-debug]

I'm using the following command line:
/usr/sbin/tao-cosnaming \
-p /tmp/tao-cosnaming-debug/tao-cosnaming.pid \
-ORBListenEndpoints iiop://:2809 \
-f /tmp/tao-cosnaming-debug/tao-cosnaming.dat \
-ORBLogFile /tmp/tao-cosnaming-debug/tao-cosnaming.log \
-ORBSvcConf /etc/tao/tao-cosnaming.conf \
-ORBDaemon \
-ORBDebugLevel 10

The problem seems to be that ACE_Service_Config::open_i is not called.
Comment 1 Ken Sedgwick 2008-06-01 14:19:55 CDT
Created attachment 981 [details]
Patch adding app-level "--daemon" flag to orbsvcs

This patch adds an application level "--daemon" flag to each of these orbsvcs.
Comment 2 J.T. Conklin 2008-06-06 15:45:42 CDT
I'll take this one.
Comment 3 Johnny Willemsen 2008-06-13 14:16:51 CDT
Iliyan, can you check this, probably caused by the sg/sc refactoring. 
Comment 4 Johnny Willemsen 2008-06-13 14:18:01 CDT
(In reply to comment #1)
> Created an attachment (id=981) [details]
> Patch adding app-level "--daemon" flag to orbsvcs
> 
> This patch adds an application level "--daemon" flag to each of these orbsvcs.

the -orbdeamon should work, I have asked Iliyan to check this
Comment 5 Iliyan Jeliazkov 2008-06-16 08:54:16 CDT
(In reply to comment #4)
> > 
> > This patch adds an application level "--daemon" flag to each of these orbsvcs.
> 
> the -orbdeamon should work, I have asked Iliyan to check this

it does seem it should work and perhaps it is the better solution, because it makes the functionality explicit. the more complicated approach - trying to "fix" SC::open() to restore the legacy behavior - might be worth it if more cases like this were discovered. i will try to look into it
Comment 6 Richard Ridgway 2008-10-09 10:38:27 CDT
Confirmed ImR_Activator shows same regression
Comment 7 Ken Sedgwick 2009-04-19 12:58:50 CDT
Created attachment 1128 [details]
Update to patch for x.6.9 changes
Comment 8 Johnny Willemsen 2009-04-19 13:04:36 CDT
I think we just should have -ORBDeamon, having the same option in the services seems a wrong thing, duplicate code. If other people have other ideas, add them here. In case people want to have a service specific flag, why have it with --, not just -.
Comment 9 Ken Sedgwick 2009-04-19 13:19:37 CDT
Johnny,

We don't want s separate flag ... the problem is -ORBDaemon didn't seem to work correctly.

My recollection of the issue (there should be something in the mailing list about it) is that -ORBDaemon is a fairly complex ordering challenge; it seems very hard.

My patch is a workaround which attempts to solve the problem at the application layer, by not using a challenging feature which wasn't working.

Please let me know if the underlying -ORBDaemon support is now working; it would be a better solution ...

Ken
Comment 10 Ken Sedgwick 2009-07-27 12:06:54 CDT
Created attachment 1176 [details]
Latest orbsvcs daemon patch.

This is the latest version of the patch.
Comment 11 Johnny Willemsen 2009-07-27 14:33:13 CDT
I have asked OCI to see if they can address the -orbdeamon problem.