Herbert Poetzl <[EMAIL PROTECTED]> 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
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.
> (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.
Enrico
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
