Hi again, I have been looking trought different debian versions, and that "# define CLONE_NEWNS 0x00020000" is present on sid (unstable), but not in "woody", the stable version wich is the one that servers are running. So i was wondering if i include that define for files /usr/include/linux/sched.h and /usr/include/bits/sched.h on debian woody that seems to use the same addresses on sid for the present defines, could cause any worse to further compilations or something, i dont think so, but please let me know, because as i said im not a skilled c coder. Thanks, Jaime. On Thu, 30 Sep 2004 17:44:29 +0200, Jaime Peñalba <jpenalbae@xxxxxxxxx> wrote: > > > On Thu, 30 Sep 2004 17:02:22 +0200, christophe.varoqui@xxxxxxx > <christophe.varoqui@xxxxxxx> wrote: > > Selon Jaime Peñalba <jpenalbae@xxxxxxxxx>: > > > > > Im having some problems compiling multipathd from your latest > > > releases, concretely when call "__clone(child, child_stack, > > > CLONE_NEWNS, NULL)" is used, wich doesnt come with libc includes: > > > > > > make[1]: Leaving directory > > > `/root/soft/multipath-tools-0.2.9/multipathd/libsysfs' > > > gcc-3.3 -pipe -g -Wall -Wunused -Wstrict-prototypes -DDEBUG=1 > > > -DFLOATING_STACKS -Di386 -c -o main.o main.c > > > main.c: In function `get_devmaps': > > > main.c:237: warning: long unsigned int format, different type arg (arg 4) > > > main.c:237: warning: long unsigned int format, different type arg (arg 5) > > > main.c: In function `main': > > > main.c:927: warning: implicit declaration of function `__clone' > > > main.c:927: error: `CLONE_NEWNS' undeclared (first use in this function) > > > main.c:927: error: (Each undeclared identifier is reported only once > > > main.c:927: error: for each function it appears in.) > > > make: *** [main.o] Error 1 > > > > > please try to locate the CLONE_NEWNS define in the /usr/include/ dir of your > > specific distribution and feed back. (what's the distrib anyway ?) > > > > Im using debian woody, with some unofficial packages... > > pop1:/usr# grep -R " CLONE_NEWNS" * > pop1:/usr# > > it is defined on kernel headers, but not on my libc... > > pop1:~/kernel/linux# grep -R " CLONE_NEWNS" * > fs/namespace.c: if (!(flags & CLONE_NEWNS)) > include/linux/sched.h:#define CLONE_NEWNS 0x00020000 /* New > namespace group? */ > > What can i do? If i include kernel headers errors are even worse... > > > > So im using 0.2.5 version. There is any fix for this? im not very well > > > c coder, so i tryed to change the pid varible assignament on 0.2.8 > > > version from "pid = sys_clone(CLONE_NEWNS, 0);" to "pid = fork();" > > > that compiled for me on 0.2.5 but when i started modified multipathd > > > 0.2.8 daemon it removed mysteriously my /bin and /usr/bin, so i came > > > back to 0.2.5. There is any workarround about this? im interested on > > > new releases... > > > > > that is expected behaviour. > > I switched from fork() to clone() to use the private namespace stuff. > > Going back to fork will over-mount /bin, /sbin and /tmp ... > > > > > Also i would like to know how i can change the spread policy by > > > default, im using HP HSV100 arrays, wich must use "group_by_tur" > > > defined on multipathd.conf and seems to be using "multibus" > > > > > have a look at /etc/multipath.conf > > I dropped samples in the source package > > Thanks a lot, i will look for it. > > > > > Anyway, multibus is fine with HSV controlers : even in multibus, failing paths > > (ghosts paths too) will be isolated in a secondary path group. > > > So, failover will work well using multibus? i mean if one fibre > comtroller is removed, it will use only one, and when the other > controller is added again multibus would work again using both > controllers? sorry, i cannot make too many tests because the hardware > isnt our, and im not there to unplug the fibre wire. > > Thanks, > Jaime. >