From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Sat 29 Jan 2005 - 15:19:05 GMT
On Sat, Jan 29, 2005 at 05:47:51AM +0100, Enrico Scholz wrote:
> Herbert Poetzl <herbert_at_13thfloor.at> writes:
>
> > after a decent debug session we now know that the vshelper reboot
> > functionality is broken with 0.30.196 on vs1.2.10 (I suspect on older
> > versions too) ...
> >
> > the culprit seems to be vserver-info, which, for whatever reason, is
> > not able to 'reverse' the xid (to a vserver name)
> >
> >
> > === linux-2.4.29-vs1.2.10
> >
> > [root@(none) /]$ vserver zope3 start
> > [root@(none) /]$ vserver-stat
> > CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME
> > 0 12 1.9M 278 0m05s33 0m11s13 0m54s65 root server
> > 2 5 7.5M 741 0m02s32 0m06s11 0m09s53
>
> What gives an 'strace vserver-info 2 ID'? When a name can be resolved,
> you should see lines like
>
> | access("/var/run/vservers.rev/2", F_OK) = 0
> | open("/var/run/vservers.rev/2/run", O_RDONLY) = 3
> | lseek(3, 0, SEEK_END) = 2
> | lseek(3, 0, SEEK_SET) = 0
> | read(3, "2\n", 3) = 2
execve("/usr/sbin/vserver-info", ["vserver-info", "2", "ID"], [/* 13 vars */]) = 0
vserver(VCMD_00,0[0], 63) = 65540
access("/var/lib/run/vservers.rev/2", F_OK) = -1 ENOENT (No such file or directory)
open("/var/lib/run/vservers", O_RDONLY|O_DIRECTORY) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30000000
getdents(3, /* 2 entries */, 4083) = 28
getdents(3, /* 0 entries */, 4083) = 0
close(3) = 0
munmap(0x30000000, 4096) = 0
_exit(1) = ?
hmm .. but there is
/var/run/vservers.rev/2
any idea how that can be different on 2.6/1.9?
(the tools are identical in both tests)
> Then, verify with 'vserver --debug zope3 start' that the chain-command
> contains
>
> | ... /usr/lib/util-vserver/save_ctxinfo /etc/vservers/zope3 ...
>
> and that '/etc/vservers/zope3/run.rev/2' is a symlink pointing back to
> '/etc/vservers/zope3'.
>
> When these things look sane, make sure that no 'vshelper' rebootet the
> vserver between 'vserver ... start' and 'vserver-stat'. You could
> e.g. enable vshelper logging and look for vshelper invocations.
>
>
> > === linux-2.6.11-rc2-vs1.9.4-rc4
> >
> > [root@(none) /]$ vserver zope3 start
> > [root@(none) /]$ vserver-stat
> > CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME
> > 0 11 1.9M 285 0m06s12 0m11s50 2m42s67 root server
> > 2 9 16M 1.7K 0m00s73 0m02s30 0m04s30 zope3
>
> Yes; the 'run.rev' mechanism exists for kernel 2.4 only. With kernel
> 2.6, the 'context' uname field is used to identify the vserver.
>
>
> > btw, this 'reverse' lookup is also causing big troubles with the ngnet
> > testing, as the tools are not able to handle/delegate a vshelper call
> > when the context is just starting up
>
> Sorry; vshelper was never indented for starting vservers.
no but it will have to cope with creating the vnet
devices right after the context creation, which calls
out as vshelper startup <xid> and with vnet destruction
when the context is shut down as vshelper shutdown <xid>
and it is a problem if neither the context specific nor
the .default hooks work in this case ...
> > (or just finished)
>
> mmh... I would wonder when existing reset-mechanisms exit after invoking
> reboot(2). When this happens, you would see a kernel panic about a killed
> init on each reboot.
>
> I think, that most init-implementations go into an endless sleep after
> calling reboot(2) so the context will be alive at 'vshelper' execution
> time.
yes, probably, but that is not valid for the shutdown
call, as it happens when the last process is terminated
best,
Herbert
PS: how is your thesis going?
> Enrico
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver