On Tuesday 31 March 2009 20:26:08 Marek Lindner wrote:
thanks a lot for addressing this issue by sending your patch. Although I'm not too happy about the chosen approach. Changing the default behaviour and adding a new command line option seems not to be the best solution. Do you think we can put this exec call into batman itself and thus hiding this ulibc thread disaster ?
First thing is that you have to add a option to disable the fork to the background. Otherwise all batmand execs will again fork to the background and exec again a batmand. Then there is the issue of finding the right executable to execute. The argv[0] approach isn't ideal since there must not be any connections to the real executable. Take for example this small snipped:
#include <unistd.h> int main() { char* const argv[] = {"/fake", NULL}; execv("/bin/sh", argv); return 0; }
Make a `echo $0` in a normal shell and one in the shell started by this program. An approach to start a program again is to use start the program again over /proc/self/exe. This can fail due to different reasons. First one is that there is no proc filesystem mounted. Second one is that there is that the file which was used to start the program was moved to another location (or deleted). Maybe there are other ways I don't know, but please don't suggest fexecve since this is even less POSIX and takes a similar approach, but involves more 'guessing' since you first have to open a file to get the correct fd. Under (Free)BSD you will have to find a similar approach since it doesn't have /proc/self/exe unless you mounted linprocfs.
As you can see the real problem is the association between the process and it's executable you need to execute batmand again. I will post a proof-of- concept patch to show this approach. Be prepared that it eats your pets and converts wine into water. I cannot test the patches again the current openwrt trunk since https://svn.openwrt.org/openwrt/trunk is broken at the moment.
Regards, Sven