On Mon, Jul 06, 2009 at 11:51:39PM +0100, Ed W wrote: > Hi > >>- hostname is no longer virtualised - whichever vserver is booted > >>last sets the hostname for the host and all vservers > >Too old utils, upgrade to util-vserver-0.30.216+. > Upgraded to 0.30.216_pre2841, but now it segfaults when I try to start > a vserver... (actually when I do nearly anything) any messages in dmesg maybe? > Note, I now switched to using a non hardened kernel also. I have > 2.6.29.5 with matching VS patch (on intel core2 hardware with 64bit > kernel). Toolchain is still gcc3.4 hardened though (gentoo) hmm, so an older gcc, but with 'gentoo hardened' patches? or was that a typo? > eg > > #vserver dnsmasq start > ..snip.. > * Starting > vixie-cron... > [ ok ] > * Starting local... > /usr/sbin/chbind: line 135: 14948 Segmentation fault > "${create_cmd[@]}" "${chain_cmd[@]}" -- "$@" > > ...snip... > Failed to start vserver 'dnsmasq' > Segmentation fault > and using the /etc/init.d/vservers.default script under gentoo I get: > > /etc/init.d/vservers.default restart > * Caching service > dependencies... > [ ok ] > * Stopping vservers of type > 'default'... > [ ok ] > * Starting vservers of type 'default'... > /bin/sh: line 1: 12477 Segmentation fault /usr/sbin/vserver > --defaulttty --sync "dnsmasq" start > make: *** [.dnsmasq.stamp] Error 139 > /bin/sh: line 1: 12487 Segmentation fault /usr/sbin/vserver > --defaulttty --sync "fs" start > make: *** [.fs.stamp] Error 139 > Switched back to 0.30.215 for the time being > >>- "vserver xyz enter" frequently segfaults - using util-vserver 0.30.215 > >Got core dumps or similar? > I'm struggling to get a useful one. In gdb I just see some hints it > might be from `login, so I assumed it meant /bin/login and rebuilt both > util-vserver and shadow with debug symbols. Because I run hardened I > also also set LDFLAGS="-nopie". what does `vserver-info - SYSINFO` give? > Then I run it up in gdb and ask it for a backtrace against /bin/login, > but just get > gdb /bin/login --core /vservers/images/www2/core > ...snip... > warning: core file may not match specified executable file. > Core was generated by > `login > '. > Program terminated with signal 11, Segmentation fault. > [New process 26874] > #0 0x00000000004014b8 in ?? () > (gdb) thread apply all bt full > Thread 1 (process 26874): > #0 0x00000000004014b8 in ?? () > No symbol table info available. > #1 0x0f0000000fc0c748 in ?? () > No symbol table info available. > #2 0x0000000000000000 in ?? () > No symbol table info available. > How can I check which app it's actually a coredump for? How can I test > I have proper debug symbols on that app? objdump -s -j note0 core.dump should give some clues ... HTH, Herbert > >Try showattr. Note that with recent utils and a recent kernel, you don't > >actually need the barrier anymore. > Aha, showattr is giving me the answer I expected. Super > > Thanks for any thoughts on the problems above? > > Ed W > >