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.
>> >
>
Received on Mon Jan 31 23:33:14 2011