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
best,
Herbert
> >> [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.
> >
Received on Mon Jan 31 21:38:15 2011