[omniORB] Cannot switch to background (daemon) on Linux
Pánczél Levente
Levente.Panczel at compuworx.hu
Wed Oct 29 13:59:32 GMT 2003
Hello!
I'm using OmniORB 4.0.1 on Suse Linux 8.0 (2.4.18-4GB) to see how it fits my company's needs. In the server I first start the ORB and then initialize my objects (most of then have CORBA interfaces). Then I initiate some commands on the command-line I implemented into the server, and everything works fine. Then I shut the server down, which also works fine.
BUT
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.
When I have the server in the background, and all threads other then the main() killed, orb->shutdown() produces very strange behavior: it seems to hang, but on some input it continues for a short period of time, but the shutdown never finishes:
try{
...
orb->shutdown(true);
tout << "ORB shutdown done." << endl;
orb->destroy();
tout << "ORB destroyed." << endl;
}
catch(CORBA::SystemException&){cerr << "CORBA::SystemException" << endl;}
catch(CORBA::Exception&){cerr << "CORBA::Exception" << endl;}
catch(omniORB::fatalException& fe){
cerr << "OmniORB::FatalException:\n file: " << fe.file() << "\n line: " << fe.line() << "\n mesg: " << fe.errmsg() << endl;}
catch(...) {cerr << "Unknown exception." << endl;}
tout << "Closing console..." << endl;
I Sometimes get the last message "Closing console...", but never any of the messages "ORB ..." sent to tout (which is a timestamping cout) and no exception is ever caught! I can't figure out why and how the control flows.
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. I have some objects one-by-one associated to threads, and I have to shut these down, and recreate them after the call, but this is not a big deal.
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?
Is it possible, that it is enough to deactivate my objects with the POA and then to reactivate them after the daemon()?
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 think it would not be a too big problem even to be able not to lose active connections / upcalls in progress while in suspended state (at least if it is not for a long period of time as it is not in this case).
So alltogether: I want to know what are the minimal steps I have to make to be able to continue after a call to daemon().
Thanks in advance!
Panczel, Levente
More information about the omniORB-list
mailing list