Remote spawn on a "localized" node

QNX Newsgroups (Archives) qdn.public.qnx4
1

Hiya,

Is it possible to spawn a process on a “localized” node (i.e. a node with
the Proc32 -L options set) from a remote node?

I know it’s possible to establish a vc into a localized node, but I’m having
no success spawning a process from the outside. I’ve tried everything I can
think of… including closing all file descriptors (in the parent process),
doing a qnx_prefix_setroot( ) just before a qnx_spawn(),
using various qnx_spawn_options, etc. The best I’ve been able to get is
errno=11 (Resource temporarily unavailable) when attempting a qnx_spawn().

TIA

Rob

2

Rob <rob@spamyouself.com> wrote:

Hiya,

Is it possible to spawn a process on a “localized” node (i.e. a node with
the Proc32 -L options set) from a remote node?

I don’t actually know. There’s a lot of two-way communication going
on for that.

I know it’s possible to establish a vc into a localized node, but I’m having
no success spawning a process from the outside. I’ve tried everything I can
think of… including closing all file descriptors (in the parent process),
doing a qnx_prefix_setroot( ) just before a qnx_spawn(),
using various qnx_spawn_options, etc. The best I’ve been able to get is
errno=11 (Resource temporarily unavailable) when attempting a qnx_spawn().

I’d try setting the _SPAWN_NOZOMBIE flag as well. This says that the
parent does need sigchld notification of the child, and also prevents
the creation of the parent-child vc. This might be the final piece
that is burning you – or there might, still, be something more.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

3

Thanks David, but that would be a “or there might, still, be something more”
:wink:
I’ve tried with and without _SPAWN_NOZOMBIE. Same results, errno=11.
FYI… doing things like leaving fds open and/or not referencing a path on
the localized node’s file system for the executable being spawned, gives an
errno of 1011 (No License).

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:a6lbqn$8p9$3@nntp.qnx.com…

Rob <> rob@spamyouself.com> > wrote:
Hiya,

Is it possible to spawn a process on a “localized” node (i.e. a node
with
the Proc32 -L options set) from a remote node?

I don’t actually know. There’s a lot of two-way communication going
on for that.

I know it’s possible to establish a vc into a localized node, but I’m
having
no success spawning a process from the outside. I’ve tried everything I
can
think of… including closing all file descriptors (in the parent
process),
doing a qnx_prefix_setroot( ) just before a
qnx_spawn(),
using various qnx_spawn_options, etc. The best I’ve been able to get is
errno=11 (Resource temporarily unavailable) when attempting a
qnx_spawn().

I’d try setting the _SPAWN_NOZOMBIE flag as well. This says that the
parent does need sigchld notification of the child, and also prevents
the creation of the parent-child vc. This might be the final piece
that is burning you – or there might, still, be something more.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

4

Rob <rob@spamyouself.com> wrote:

Thanks David, but that would be a “or there might, still, be something more”
:wink:
I’ve tried with and without _SPAWN_NOZOMBIE. Same results, errno=11.

Oh well.

I guess the next question is, why do you need to do this, and how
desperately.

/* spawn_server.c */
…
while(1) {
Receive(0, msg, sizeof(msg) );
spawn(msg.executable);
}

/* spawnlib.c */

int myspawn(executable)
{
find_remote_pid();
msg.executable = executable;
Send(remote_pid, &msg, NULL, sizeof(msg), 0 );
}

I THINK you should be able to do a qnx_name_attach() on the
protected node, and a qnx_name_locate( protect_nid, name, … )
to find it – though I haven’t directly tested.

Of course, this does depend on having spawn_server running all
the time, and given that, really, Proc32 is a spawn_server, and
is already running all the time, this really shouldn’t be neccessary.
(Though, apparently, there are more side-effects to get proper “spawn”
behaviour that require something.)

FYI… doing things like leaving fds open and/or not referencing a path on
the localized node’s file system for the executable being spawned, gives an
errno of 1011 (No License).

Yes, that makes sense – I looked at those kernel paths a few (well, many)
moons ago when I was implementing the -L2 option, it generates an
ENOLIC whenever it fails a vc create due to the no inbound or no
outbound options.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

5

HeHe… I wouldn’t say “desperately” is really in my nature. I was just
looking for a definitive yes or no as to whether this would work, before
beating my head against the wall any more :wink:

Actually, there already are spawn facilities available on our “localized”
nodes, that essentially works just like your little example. They’ve been
in place for years. I’ve been working on a new sub-system that I was hoping
to make independent of all that. But, if I have to, I guess I’ll just have
to use what’s already in place.

Thanks for nothing… as it were :wink:

Rob “It may be boring and old, but it works.”

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:a6lpa5$kif$1@nntp.qnx.com…

Rob <> rob@spamyouself.com> > wrote:
Thanks David, but that would be a “or there might, still, be something
more”
:wink:
I’ve tried with and without _SPAWN_NOZOMBIE. Same results, errno=11.

Oh well.

I guess the next question is, why do you need to do this, and how
desperately.

/* spawn_server.c */
…
while(1) {
Receive(0, msg, sizeof(msg) );
spawn(msg.executable);
}

/* spawnlib.c */

int myspawn(executable)
{
find_remote_pid();
msg.executable = executable;
Send(remote_pid, &msg, NULL, sizeof(msg), 0 );
}

I THINK you should be able to do a qnx_name_attach() on the
protected node, and a qnx_name_locate( protect_nid, name, … )
to find it – though I haven’t directly tested.

Of course, this does depend on having spawn_server running all
the time, and given that, really, Proc32 is a spawn_server, and
is already running all the time, this really shouldn’t be neccessary.
(Though, apparently, there are more side-effects to get proper “spawn”
behaviour that require something.)

FYI… doing things like leaving fds open and/or not referencing a path
on
the localized node’s file system for the executable being spawned, gives
an
errno of 1011 (No License).

Yes, that makes sense – I looked at those kernel paths a few (well, many)
moons ago when I was implementing the -L2 option, it generates an
ENOLIC whenever it fails a vc create due to the no inbound or no
outbound options.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.