Le Wednesday 25 June 2008 20:25:23 Sylvain Sauvage, vous avez écrit :
> 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 ?
Non malheureusement.
> 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 ?
En dehors du chroot, celà fonctionne parfaitement, je l'ai même mis en place
en production et aucun problème.
Je l'ai même testé dans un environnement chroot constuit via de debootstap et
il fonctionne aussi parfaitement.
Bonjour à tous,
Je reviens pour donner des nouvelles sur l'environnement chroot du "storage
daemon" Bacula car j'ai un peu avancé et donc le problème était quelques
librairies prisent en compte via des mauvais chemins.
Une fois celle-ci remise au bon endroit, tout va beaucoup mieux au niveau du
segfault mais reste une petite problématique.
Mon bacula ne me sort aucune erreur mais normalement dés que je le lance je
devrais le voir apparaître parmis les processus de mon environnement non
chrooté, hors là rien, aucune trace.
Par contre, avec le chroot via deboostrap, quand je lance mon bacula, je vois
bien le processus associé:
sshd 12532 0.0 0.6 22572 1732 ? Ssl 18:11
0:00 /usr/sbin/bacula-sd -c /etc/bacula/bacula-sd.conf -u bacula -g tape
Au passage, je ne comprends pas trop pourquoi, à la fin du strace, j'ai ceci:
open("/dev/null", O_RDONLY|O_LARGEFILE) = 3
close(3) = 0
stat64("/var/lib/bacula", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7beca28) = 12498
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
exit_group(0) = ?
Process 12497 detached
Merci,
--
Cordialement.
Kader HAJI
Attachment:
signature.asc
Description: This is a digitally signed message part.