About this list Date view Thread view Subject view Author view Attachment view

From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Sat 29 Jan 2005 - 04:47:51 GMT


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

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_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sat 29 Jan 2005 - 04:49:30 GMT by hypermail 2.1.3