On Tue, Dec 21, 2010 at 03:13:24PM +0800, Jeff Jansen wrote: > On Monday 20,December,2010 02:36 PM, Herbert Poetzl wrote: > > first, I'd update to 2.6.36.x with the latest patch and the > > most recent util-vserver, because that's where all the > > updates and fixes go, and check that the 'issue' still > > exists there ... > I compiled "linux-2.6.36.2" patched with > "patch-2.6.36.2-vs2.3.0.36.38.2.diff", and > "util-vserver-0.30.216-pre2926". I still see the same issue when I run > a lucid guest using the new kernel and util-vserver. > Versions: > Kernel: 2.6.36.2-vs2.3.0.36.38.2 > VS-API: 0x00020307 > VCI: 0x0000000013110f91 > util-vserver: 0.30.216-pre2926; Dec 21 2010, 09:46:13 > When I try to start the ssh server (which has an "expect fork" in the > "/etc/init/ssh.conf" file), it fails with the following error in the logs: > Dec 21 10:47:41 LUCID init: Failed to spawn ssh main process: unable to > set trace: Operation not permitted > "strace -f -p 1" in the guest shows > [pid 13635] ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not > permitted) this is actually quite interesting because: - strace uses sys_ptrace() so the ptrace itself seems to be fine (i.e. I presume your guest has CAP_SYS_PTRACE) - upstart? fails to use sys_ptrace() with EPERM (i.e. permission denied) checking the code gives the following reasons for that: - credentials wrong (uid/gid) - CAP_SYS_PTRACE missing - different xid (this is Linux-VServer specific) - security framework check as I presume that upstart is running in the same guest context I can almost certainly rule out the xid check, which makes me wonder what actually causes your EPERM ... if you are interested in tracking this down, please pay a visit to the IRC channel (#vserver @ irc.oftc.net) where we can debug this in detail (you need a test system and a kernel build tree to test with :) > If I go into "/etc/init/ssh.conf" and comment out the "expect fork" line > and then change 'exec sshd' to 'exec sshd -d' (so sshd won't fork), then > SSH starts and stops correctly using upstart. I presume this simply disables the ptrace completely, note that I'm not convinced that ptracing services is a good idea in the first place, mainly because of performance implications best, Herbert > Jeff Jansen