Subject: Re: [vserver] kill -9 1 doesn't work?
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Tue, 4 Sep 2012 16:18:29 +0200

On Tue, Sep 04, 2012 at 08:39:25AM +0200, Wilhelm wrote:
> Am 03.09.2012 21:28, schrieb Herbert Poetzl:
>> On Fri, Aug 31, 2012 at 09:19:52AM +0200, Wilhelm wrote:
>>> Hi all,

>>> as a last resort to stop upstart-based vserver it tries to
>>> modifiy sendsigs to issue a

>>> kill -9 1

>>> But this doesn't work from inside a vserver.
>>> From host a vkill ... is ok.
>>> Looks like the syscall is somehow redirected.

>> kernel, patch and util-vserver version?

> root@kmux-host:~# vserver-info
> Versions:
>                    Kernel: 3.4.5-030405-kmux-pae

still leaves the patch version unclear, probably one of
vs2.3.3.4, vs2.3.3.5, vs2.3.3.6 or vs2.3.3.7, where my
bet would be on vs2.3.3.5

what is the kmux and pae extension?

>                    VS-API: 0x00020308
>                       VCI: 0x0000000013001f01
>              util-vserver: 0.30.216-pre3004; Aug 30 2012, 14:00:04

> Features:
>                        CC: gcc, gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
>                  CPPFLAGS: ''
>                    CFLAGS: '-g -O2 -std=c99 -Wall -pedantic -W 
> -funit-at-a-time'
>                build/host: i686-pc-linux-gnu/i686-pc-linux-gnu
>              Use dietlibc: yes
>        Build C++ programs:
>        Build C99 programs: yes
>            Available APIs: v13,net,v21,v22,v23,netv2
>             ext2fs Source: e2fsprogs
>     syscall(2) invocation: alternative
>       vserver(2) syscall#: 273/glibc
>                crypto api: nss
>           python bindings: yes
>    use library versioning: yes

> Paths:
>                    prefix: /usr
>         sysconf-Directory: /etc
>             cfg-Directory: /etc/vservers
>          initrd-Directory: $(sysconfdir)/init.d
>        pkgstate-Directory: ${prefix}/var/run/vservers
>           vserver-Rootdir: /vservers


> Assumed 'SYSINFO' as no other option given; try '--help' for more 
> information.
> root@kmux-host:~#

>> and what config has the guest regarding init?

> plain

okay, will do some tests with the latest kernels
in this regard, but I assume the guest is behaving
like the host would, because the init process is
protected against such signals (on host and guest)

best,
Herbert

>>> Any hints to enable this?

>> really depends on the kernel implementation,
>> but usually you need to override checks in
>> kill_something_info()

>> HTH,
>> Herbert

>>> --
>>> Wilhelm


> -- 
> Wilhelm