Re: [B.A.T.M.A.N.] [PATCH] Don't detach batmand to background by default

[Sven Eckelmann <sven.eckelmann@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]