On 4/26/2019 4:18 PM, Lowell Gilbert via Xenomai wrote:
Hi.
I have an application working successfully with Xenomai 3.0.8 on a 4.14
kernel. I use Yocto to build the system; when I tried to move to a newer
version of Yocto, my application hung on trying to become a daemon. This
is happening with the daemon() call (which is what I've used up to now)
and with fork().
I built a test application so that I could confirm that this problem
only occurs when I link (and wrap) with Xenomai. However, Xenomai
doesn't seem to do anything significant with fork, so I'm puzzled about
why this might be happening. I am not using libdaemon.
Here are the changes that I thought might be significant:
| newer (nonworking setup) | older (working) |
| gcc-cross-arm-8.2.0 | 7.3.0 |
| glibc-2.28 | 2.26 |
| glib-2.0-1_2.58.0 | 1_2.52.3-r0 |
| binutils-cross-arm-2.31.1 | 2.29.1 |
| coreutils-8.30 | 8.27 |
Does anything jump out as a candidate for causing problems with a fork()
call? Is there anything else I should be considering?
Thanks.
Be well.
I can tell you that I have a hang issue due to fork() in a Xenomai
program if, after the fork(), I don't do an exec(). I believe
the hang is related to registry access, and the fact that the
Unix domain socket connecting to sysregd that is inherited by
the forked process (which has FD_CLOEXEC set) hasn't yet gotten
closed (no exec() yet so no action on FD_CLOEXEC flags yet).
If you are running into the same problem, and you don't require
registry access, you should see the problem go away if you throw
the --no-registry switch on the command line that invokes your
program. That's not a real fix, but it's perhaps a way to know
if you're seeing a related problem.
In my case, the way I see the "hang" is via an attempt to list
the contents of /run/xenomai using find:
root:~ # find /run/xenomai
If I run a program XX that uses the registry, that does a fork() call
and then does not exec(), and while that program is running, I
execute the above find command, it will hang part way through the
listing. If I kill program XX, the listing continues (un-hangs).
If I run a program that uses the registry, that does a fork() and
then an exec(), no such hang occurs during the find command.
Phillipe made the change to fix this originally by adding SOCK_CLOEXEC
to the socket() call in sysreg.c, and it did fix it but I realized
much later it fixes it only if you actually call exec(), which in my
code I always do, but more recently one of our developers had some
code that didn't exec(), which was the first time I saw this hang.
Phillipe, I had it on my list to ask you about this but it hasn't
bitten me lately and I forgot until I saw this msg about fork().
I think deamonizing in its canonical form of: fork(), let the forked
process take over, and then exit() in the parent, is problematic when
you have a wrapped main() where the wrappers already initialized the
sysreg mechanism but the process that was done for is now gone, and
the fork()'ed process has no idea it has a sysreg socket in hand.
Perhaps the better answer when daemonizing is to use --no-init and then
have the forked() process do manual xenomai_init() call?
HTH,
Regards,
Steve
