[omniORB] Cannot switch to background (daemon) on Linux

[Luke Deller]

Pánczél Levente wrote:

>Hello!
>
Hi!

>The is a command in the server wich puts it into the background (into daemon mode), so it not listed by 'ps' anymore, and so on. This command's implementation uses the daemon(true,true) system call to push the process into the packground, and to detach from the console, so the shell can continue.
>
...

>Though I cannot explain the behavior I experienced but I think I konw the reasons of the error:
>As far as I know, the daemon call copies only the calling thread into the background, so all other threads are lost.
>
Yes this is true.  It's a really bad idea to call daemon() from a 
multithreaded application.  The daemon() function calls fork(). The 
child process produced by fork() has only one thread in it.  This thread 
can easily hang if it expects other threads to still be around, or if it 
tries to acquire a lock which was held by another thread in the parent 
process while the fork() occurred.

>My problem is, that some of the main objects (wich share the main thread, and therefore survive the daemon call) must not be destroyed or deactivated by any means.
>So I think the seqence
>  orb->shutdown();
>  orb->destroy();
>  daemon(true,true);
>  orb=CORBA::ORB_init(argv,argc);
>should be good to get around the problem, but I'm not sure, that's good for me, 'cos while this is happening, a CORBA object (the servant class' name is Container) is still running, and I want it to survive the whole seqence. Will orb-shutdown() or orb->destroy() delete the servant?
>
orb->shutdown will result in _remove_ref() being called on all active 
servants.  This will only cause the servant to be deleted if the 
reference count reaches zero (assuming your servant extends 
PortableServer::RefCountServantBase ).

>Is it possible, that it is enough to deactivate my objects with the POA and then to reactivate them after the daemon()?
>
This sounds reasonable to me (but try it out for yourself!) - only make 
sure that you hold a reference to your servant so that it is not deleted 
by deactivating the object.

>The solution I would like them most would be that the ORB has two additional services: one for suspending it (meaning it destroys all its threads) and another for resuming normal operation (making it recreate all the threads, and per-thread data structures it need to resume normal operation - without the need to activate/deactivate objects).
>
I wonder if it would be worth adding such a non-standard extension to 
the ORB, if the same result can be achieved using standard CORBA 
facilities (deactivate, destroy, init, activate).

Regards,
Luke.