L.S.
Using QNX 6.2.1. with two nodes mnode and snode.
What I need is to program the behaviour of ‘on -f …’.
An attempt with spawn gives me the behaviour of ‘on -n …’:
#include <spawn.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
int main()
{
char * file = “/home/test/atoz”;
pid_t pid;
int stat_loc;
int fd_count = 3;
int fd_map[] = {
0,1,2
};
char * argv[] = {
file,
NULL,
NULL
};
char * envp[] = {
“PATH=/home/test:/bin:/usr/bin”,
NULL
};
struct inheritance inherit;
inherit.flags = SPAWN_SETND;
inherit.nd = netmgr_strtond( “snode”, NULL);
argv[1] = “/net/snode”;
printf(“spawn %s %s\n”, file, argv[1]);
pid = spawn(file, fd_count, fd_map, &inherit,
argv, envp);
if (pid == -1) {
perror(“spawn”);
} else {
printf("%s started with pid %d\n", file, pid);
}
return 0;
}
The atoz application (thanks Rob Krten) makes a directory /atoz
I can find it with:
ls /net/snode/net/mnode.net.intra/atoz or
on -n snode ls /net/mnode.net.intra/atoz
but when I start it with
on -f snode /home/test/atoz
I can find it with:
ls /net/snode/atoz or
on -f snode ls /atoz
In the documentation I can’t find how to do it. This mechanism is needed for
an application where different programs are started on the snode that have
to use a device (framegrabber) on snode. Also the resource manager needs to
be started on snode by a program from mnode.
But how ?
Thanks for reading so far,
Pim Bollen
Sattinger’s Law:
It works better if you plug it in.
Pim Bollen <pbollen+qnx@vimec.nl> wrote:
Try a chroot() before the spawn.
-David
–
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
Pim Bollen <> pbollen+qnx@vimec.nl> > wrote:
Try a chroot() before the spawn.
-David
We went down the remote spawn road once. It’s a difficult
place to go.
- “chroot” is privileged. You must be running as root.
- “chroot” is irrevocable. Once you’ve locked yourself
into a subtree, you can’t get back.
- “chroot” is process-wide, not thread-wide. Other threads
will be affected.
So you can’t do much else in the program that does “chroot”.
You need a small program that you spawn, which in turn starts
the actual program you want run. This is effectively the
“on” program. You may be better off explicitly spawning
“on” with the right parameters, which is what we ended up doing.
QNX tries to extend POSIX process semantics across the network.
It almost works. But at the points it breaks down, things
get very difficult. Some things work and some don’t.
You can create pipes to a spawned process on
another machine, and that works well. Files opened in the
spawned program open with the root of the original program
relative to the original machine, which is neat but can
lead to unexpected network file access.
Parent-child process ID relationships, and the POSIX “wait”
primitives, don’t work across nodes at all, because
process IDs are node-local.
This leads to the previously discussed
“remote zombie reaping problem”. When you spawn a process on
another machine, it becomes a child of io-net, and when that
process dies, it becomes a zombie child of io-net that stays
around until io-net is killed. As I recall, the way around
this involved an undocumented flag on “spawn”.
This area needs some heavy thinking, a tech note, and about
two more flags on “spawn” to work well. QNX is doing something
good here, but it’s currently hard to understand and use.
John Nagle
Team Overbot