Bug#570382: more datapoints on vserver start failure

2010-03-11 Thread Dan Gardner
On Thu, Mar 11, 2010 at 10:17:40PM +0100, Tomas Pospisek wrote:
 So once again I had to upgrade kernels and I noticed:
 
 * that only my -686 kernel based machines failed to start the vservers
   (guests) correctly. The amd64 machine started them without problems. I
   see that florian.duf...@inria.fr also has an 686 machine. I'm Cc:ing Dan
   to see whether that's also the case for him.

Yes, also the case for me. I haven't tried an amd64 vserver kernel.

 * on one of the machines the *first* of the vserver actually did start
   all others not and on the other machine all vservers did not start
   correctly. So it's not either all vservers fail to start or none. Might
   a ressource pressure problem?

I found the same thing - it wasn't reproducible 100% of the time.

 * stopping and starting the vservers one after the other fixed the
   problem, the vservers started correctly

Again, my findings were similar. The problem only seemed to exhibit
itself using /etc/init.d/vserver start - starting vservers with
vserver foo start would always work.

-dan



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100311233100.gb28...@hercules.pureserver.info



Bug#570382: after upgrade: vlogin: openpty(): No such file or directory

2010-02-18 Thread Dan Gardner
I experienced similar behaviour, however I saw different results when
using vserver foo start and when using /etc/init.d/util-vserver
start, with only the latter exhibiting the problem. The problem appears
to be caused by secure-mount segfaulting (as you can see in your logs)
when mounting /dev/pts. Changing the vserver's fstab file to include the
options rw,noexec,nosuid for the devpts entry seems to fix the
problem. Here's the entry from my fstab in case it helps anybody:

none/dev/ptsdevpts  rw,noexec,nosuid,gid=5,mode=620 0 0 



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100218145733.ga20...@hercules.pureserver.info



Bug#570382: after upgrade: vlogin: openpty(): No such file or directory]

2010-02-18 Thread Dan Gardner
Unfortunately it seems my fix does not work. The problem is not
consistently reproducible, hence my belief I had fixed it.

I tried backporting the util-vserver package from squeeze
(0.30.216-pre2864-1) and had exactly the same problem.

The problem appears to be caused by failure of old_mmap() in
secure-mount. Here is the strace output of a failed secure-mount:

execve(/usr/lib/util-vserver/secure-mount,
[/usr/lib/util-vserver/secure-mou..., -a, --chroot, --fstab,
/etc/vservers/XXX/fstab, --rootfs, no], [/* 31 vars */]) = 0
open(., O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 3
open(/, O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 4
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
open(/etc/vservers/XXX/fstab, O_RDONLY|O_LARGEFILE) = 5
_llseek(5, 0, [393], SEEK_END)  = 0
_llseek(5, 0, [0], SEEK_SET)= 0
read(5, none\t/proc\t\tproc\tdefaults\t\t0 0\nno..., 394) = 393
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0xb28408086038) = 0x40001000
chdir(/)  = 0
fchdir(3)   = 0
chroot(.) = 0
chdir(/proc)  = 0
open(., O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 6
fchdir(4)   = 0
chroot(.) = 0
fchdir(6)   = 0
close(6)= 0
mount(none, ., proc, MS_NODEV, ) = 0
fchdir(3)   = 0
chroot(.) = 0
open(/etc/mtab, O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0644) = 6
fcntl(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=0}) = 0
write(6, none..., 4)  = 4
write(6,  ..., 1) = 1
write(6, /proc..., 5) = 5
write(6,  ..., 1) = 1
write(6, proc..., 4)  = 4
write(6,  ..., 1) = 1
write(6, defaults..., 8)  = 8
write(6,  0 0\n..., 5)= 5
close(6)= 0
fchdir(4)   = 0
chroot(.) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0xb28408086038) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

I have also tried using ulimit to turn off any potential limits which
might be causing this but without success.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100218172405.ga6...@hercules.pureserver.info