Re: Chroot debian / Bacula-sd
Haji Kader, mercredi 25 juin 2008, 13:51:29 CEST
>[…]
> strace /usr/sbin/bacula-sd
>
> execve("/usr/sbin/bacula-sd", ["/usr/sbin/bacula-sd"], [/* 17 vars */]) = 0
>[…]
> futex(0xbfe20030, 0x81 /* FUTEX_??? */, 1) = -1 ENOSYS (Function not implemented)
Hmm, un appel qui échoue.
0x81 n’est pas une valeur « connue » (API accessible, la page
de man ou futex.h) pour un futex, mais c’est une valeur
habituelle dans un strace. Et, d’habitude, ça passe.
Je ne sais pas ce que ce signifie le fait que ça coince ici…
> rt_sigaction(SIGRTMIN, {0xb7e792c0, [], SA_SIGINFO}, NULL, 8) = 0
> rt_sigaction(SIGRT_1, {0xb7e79340, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
Quelques détournements de signaux…
> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
Demande la taille de la pile.
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 26836 detached
Et pouf, un SIGSEGV. Ça peut venir du déréférencement d’un
pointeur invalide (nul) ou d’un débordement de pile…
Donc, à part le futex qui échoue, ce qui n’a peut-être rien à
voir, pas vraiment d’indication du pourquoi ça segfaulte.
Bon, strace n’affiche que les appels système, ça ne dit pas ce
qu’il se passe entre le getrlimit et le segfault. (Le getrlimit
se faisant sur la taille de la pile, c’est peut-être une
récursion infinie, mais le système n’a pas besoin de faire un
getrlimit pour segfaulter dans ce cas-là, donc ça n’a peut-être
rien à voir.)
En tout cas, on ne voit pas de tentative d’ouverture de
fichier qui échouerait. En fait, il n’y en a pas en dehors des
bibliothèques. Donc ça n’est pas un fichier qui manque.
Il n’y a pas un log ?
Il faudrait utiliser gdb, mais les binaires debian sont
strip-és ; donc pas d’info de déboguage ; donc faudrait
recompiler…
Bon, je suppose que ça fonctionne en dehors du chroot, hein ?
Tu as essayé dchroot ou schroot ?
--
Sylvain Sauvage
Reply to: