tags:

views:

352

answers:

5

We have an stub that we are launching from inittab that execv's our process. (ARM Linux Kernel 2.6.25)

When testing the process it fails only if launched from inittab and execv'd. If launched on the command line it work perfectly, every time.

The process makes heavy use of SYS V IPC.

Are there any differences between the two launch methods that I should be aware of?

+1  A: 

Could it be an issue of environment variables? If so, consider using execve or execle with an appropriate envp argument.

Matthew Flaschen
+2  A: 

As Matthew mentioned it, it is probably an env variable issue. Try to dump yout env list before calling your program in both case - through the stub or 'by hand'.

BTW It could help a lot if you could provide more information why your program did crash. Log file ? core dump/gdb ? return value from execve ?


Edit: Other checks: are you sure to pass exactly the same parameter list (if there are parameters)?

To answer your question , there is no differences between the 2 methods. Actually your shell fork() and finally call execve() to launch your process, feeding it with parameters you've provided by hand, and the environement variables you've set in your shell. Btw when launching your program through init it could launch it during an early stage of your machine startup. Are you sure everything is ready for the good running of your application at that point?

yves Baumes
A: 

The environment variable suggestion is pretty good - specifically I'd check $PATH to make sure your dependent libraries are being found (if you have any). Another thing you could check is, are you running under the same uid/gid when run as inittab?

Paul Betts
A: 

And if you replace your stub with a shell script ? If it works from the command line, it should work from a shell script, and you can know wether it is your stub or the fact that it is in inittab.

Could it be a controlling tty issue ?

Another advantage of the shell script is you can edit it and strace your program to see where it fails

shodanex
A: 

Was a mismatched kernel/library issue. Everything cleaned up after a full recompile.

gbrandt