[omniORB] Trouble when daemonising

[Thorsten Glaser]

Hello everyone,

I?ve got some trouble with omniORBpy when d?monising. I?ve written a
Python module which basically does the same as the BSD libc daemon(3)
call (fork, setsid, close stdio, chdir to /) and also switches our
logging module from stdio to syslog. So far, this has worked quite ok.

Now I want to d?monise just before calling the run method of the ORB,
but I need to initialise the ORB much earlier, since, for example, it
needs to parse command line arguments before I do. D?monising cannot
(easily) be done before ORB initialisation, since there?s a flag that
disables it, for debugging, similar to OpenNTPD.

Now the trouble is: when d?monising, I do not get any CORBA calls,
unless I move the call to daemon() to _before_ the ORB is first
initialised (instantiated). I don?t know what really goes wrong, as
this is the first project where I use Python at all, even if I tried
to track it down, call poaCache.clear, etc. ? when not d?monising at
all (or before ORB initialisation), stuff works.

If this is desired, I could try to create a minimal example to re-
produce the problem. I?m using a hello-world-style IDL for testing.
But maybe someone already has an idea what the cause is.


Thanks in advance!

//Thorsten

[Thorsten Glaser]

daemonize();

Something like that will not work (the flag is ?-d?), because it may
be the argument to some other flag.

A quite icky approach would be to parse the options ourselves without
help of the ORB, and recognise the -ORBfoo options, which are, of course,
not really documented, and only ?usually? take one extra argument after
them (not always?), then d?monise while keeping a FIFO open, which can
then be closed shortly before orb.run() is called so that the parent
process can exit.

A *huge* drawback is that error messages between d?monisation and call
to orb.run() will not end up on stdio using this approach, that?s why
I?d only consider it if there is no different way.

Reinitialisation of the magic setup might be possible, but I don?t know
about the threads thing. Granted, if they don?t survive fork() there?s
almost certainly no way around.

Thanks,
//Thorsten

[Duncan Grisby]

Post by Thorsten Glaser
I?ve got some trouble with omniORBpy when d?monising. I?ve written a
Python module which basically does the same as the BSD libc daemon(3)
call (fork, setsid, close stdio, chdir to /) and also switches our
logging module from stdio to syslog. So far, this has worked quite ok.
Now I want to d?monise just before calling the run method of the ORB,
but I need to initialise the ORB much earlier, since, for example, it
needs to parse command line arguments before I do. D?monising cannot
(easily) be done before ORB initialisation, since there?s a flag that
disables it, for debugging, similar to OpenNTPD.

ORB_init() creates several threads. Forking only gives you a copy of the
thread that did the fork(), meaning the child process is broken. There's
no way you can daemonise after ORB_init, I'm afraid.

If you want to do your own command line parsing, all the -ORB arguments
apart from -ORBhelp take a single extra argument. That isn't going to
change.

Cheers,

Duncan.

[Thorsten Glaser]

Post by Duncan Grisby
ORB_init() creates several threads. Forking only gives you a copy of the
thread that did the fork(), meaning the child process is broken. There's
no way you can daemonise after ORB_init, I'm afraid.

Okay, thanks for confirming.

Post by Duncan Grisby
If you want to do your own command line parsing, all the -ORB arguments
apart from -ORBhelp take a single extra argument. That isn't going to
change.

Aah, okay. I just wrote something which calls -ORBhelp (python two-liner)
from a shell script, parses its output and creates a file which then calls
parse.add_option() from optparse on every argument, while cursing that it
now needs two dashes (that?s life).

But I?ll consider that -ORBhelp is the only exception, and maybe in the
future will change that code ? Now it already exists.

Thanks!
//Thorsten