Am 04.09.2012 16:18, schrieb Herbert Poetzl: > 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? that is the aufs (another union filesystem) patchset and physical address 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) yes, that's true for upstart here. But I tried to kill with SIGKILL which can't be ignored or catched. Killing the guest upstart from the host side is possible (vkill ...) but not a kill -9 1 from inside the guest. So my guess is that in guests the kill -9 1 is not delivered to the upstart-process due to some "filter". Thanks for investigating that. > > 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 -- Wilhelm