Tue, 1 Feb 2011 00:33:01 +0100 On Mon, Jan 31, 2011 at 10:38 PM, Herbert Poetzl <herbert@13thfloor.at> wrote: > On Mon, Jan 31, 2011 at 10:16:24PM +0100, Petar Hitij wrote: >> Hello Herbert, > >> Thanks for a quick reply. > >> On Mon, Jan 31, 2011 at 7:41 PM, Herbert Poetzl <herbert@13thfloor.at> wrote: >> > On Mon, Jan 31, 2011 at 06:38:56PM +0100, Petar Hitij wrote: >> >> Hello everybody, > >> >> I have the following problem: > >> >> 1. host system: Debian squeeze >> >> uname -na >> >> Linux vitez0 2.6.32-5-vserver-amd64 #1 SMP Wed Jan 12 >> >> 05:05:13 UTC 2011 x86 64 GNU/Linux > >> >> 2. guest system was rsync-ed from old server, it contains >> >> RedHat 9 32bit instance > >> > is it configured as 32bit guest? >> > i.e. is the personality set correctly? > >> It wasn't, I fixed it and the segfault is still there. There are 3 >> other 32 bit guests on this host without the problem (Debian lenny). > >> >> 3. guest starts ok (mysql, apache, postfix...), ps command >> >> (and top) segfaults when it looks into /proc/meminfo. > >> > segfaults are usually (not always) a problem in >> > the userspace code, where a point is dereferenced >> > which points into forbidden space ... > >> >> I have tried to limit memory - cflags VIRTMEM - rlimits/rss >> >> 200000, it didn't help. I cannot list processes in a vserver. > >> >> Best regards >> >> Petar Hitij > >> >> guest >> >> ============ > >> >> open("/proc/meminfo", O RDONLY) = 5 >> >> lseek(5, 0, SEEK SET) = 0 >> >> read(5, "MemTotal: 800000 kB\nMemF"..., 1023) = 1023 >> >> --- SIGSEGV (Segmentation fault) @ 0 (0) --- >> >> +++ killed by SIGSEGV +++ > >> > that looks like a bug in ps/top but of course, it >> > could be a bunch of other things as well, try to >> > install a debug version (or build it from source >> > with debug info) and examine with gdb ... > >> The old host is 32bit, I could try 32bit kernel on >> new host to work around the problem. >> If that works it will by me some time to fix it >> properly. > > I wouldn't place to much hope in that, it's rather > unlikely to fix this if userspace (most likely libproc) > is too old to handle the new kernel interface ... > > IMHO the better approach would be to update libproc > to a more recent version (maybe even compile one from > a newer release) ... > > but without more debug information, it's just guessing I compiled the newest version of procps (ps, top, libproc) on the guest, and installed it. That solved the problem. Best regards Petar Hitij >> >> [root@nfp-si /]# cat /etc/redhat-release >> >> Red Hat Linux release 9 (Shrike) >> > >> >> [root@nfp-si /]# ls >> >> bin boot dev etc home initrd lib lost+found misc mnt opt >> >> poweroff proc root sbin suitespot tmp usr var >> > >> >> [root@nfp-si /]# cd /proc >> > >> >> [root@nfp-si proc]# df >> >> Filesystem 1K-blocks Used Available Use% Mounted on >> >> /dev/hdv1 58831036 44385408 11457188 80% / >> > >> >> [root@nfp-si proc]# mount >> >> /dev/hdv1 on / type ufs (defaults) >> >> none on /proc type proc (defaults) >> >> none on /dev/pts type devpts (gid=5,mode=620) >> > >> >> [root@nfp-si proc]# cat /proc/meminfo >> >> MemTotal: 800000 kB >> >> MemFree: 156044 kB >> >> Buffers: 451044 kB >> >> Cached: 0 kB >> >> SwapCached: 0 kB >> >> Active: 1062608 kB >> >> Inactive: 14134812 kB >> >> Active(anon): 199536 kB >> >> Inactive(anon): 9772 kB >> >> Active(file): 863072 kB >> >> Inactive(file): 14125040 kB >> >> Unevictable: 0 kB >> >> Mlocked: 0 kB >> >> SwapTotal: 0 kB >> >> SwapFree: 0 kB >> >> Dirty: 4 kB >> >> Writeback: 0 kB >> >> AnonPages: 208188 kB >> >> Mapped: 19864 kB >> >> Shmem: 1200 kB >> >> Slab: 666744 kB >> >> SReclaimable: 637332 kB >> >> SUnreclaim: 29412 kB >> >> KernelStack: 2896 kB >> >> PageTables: 4652 kB >> >> NFS Unstable: 0 kB >> >> Bounce: 0 kB >> >> WritebackTmp: 0 kB >> >> CommitLimit: 13111820 kB >> >> Committed AS: 798836 kB >> >> VmallocTotal: 34359738367 kB >> >> VmallocUsed: 111536 kB >> >> VmallocChunk: 34350727048 kB >> >> HardwareCorrupted: 0 kB >> >> HugePages Total: 0 >> >> HugePages Free: 0 >> >> HugePages Rsvd: 0 >> >> HugePages Surp: 0 >> >> Hugepagesize: 2048 kB >> >> DirectMap4k: 6384 kB >> >> DirectMap2M: 2080768 kB >> >> DirectMap1G: 14680064 kB >> > >> > looks fine to me, although the values might be >> > too large for a 32bit system ... >> > >> >> Host >> >> =============== >> >> >> >> vitez0:~# vserver-info >> >> Versions: >> >> Kernel: 2.6.32-5-vserver-amd64 >> >> VS-API: 0x00020305 >> >> util-vserver: 0.30.215; Jun 18 2010, 13:35:17 >> > >> > this should be definitely updated, as it is not >> > able to create safe guests (i.e. the isolation >> > will be incomplete and it should be trivial to >> > hurt the host and/or escape the guest) >> > >> Thank you, will plan for a update. >> >> Best regards >> Petar >> >> > HTH, >> > Herbert >> > >> >> Features: >> >> CC: gcc, gcc (Debian 4.4.4-5) 4.4.4 >> >> CXX: g++, g++ (Debian 4.4.4-5) 4.4.4 >> >> CPPFLAGS: '' >> >> CFLAGS: '-Wall -g -O2 -std=c99 -Wall -pedantic -W >> >> -funit-at-a-time' >> >> CXXFLAGS: '-g -O2 -ansi -Wall -pedantic -W >> >> -fmessage-length=0 -funit-at-a-time' >> >> build/host: x86 64-pc-linux-gnu/x86 64-pc-linux-gnu >> >> Use dietlibc: yes >> >> Build C++ programs: yes >> >> Build C99 programs: yes >> >> Available APIs: v13,net,v21,v22,v23,netv2 >> >> ext2fs Source: e2fsprogs >> >> syscall(2) invocation: alternative >> >> vserver(2) syscall#: 236/glibc >> >> crypto api: nss >> >> python bindings: no >> >> use library versioning: yes >> >> >> >> Paths: >> >> prefix: /usr >> >> sysconf-Directory: /etc >> >> cfg-Directory: /etc/vservers >> >> initrd-Directory: $(sysconfdir)/init.d >> >> pkgstate-Directory: /var/run/vservers >> >> vserver-Rootdir: /var/lib/vservers >> >> >> >> >> >> Assumed 'SYSINFO' as no other option given; try '--help' for more information. >> > >