Bug 985209 - [LXC] Failed to send signals to processes in the guest
[LXC] Failed to send signals to processes in the guest
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.0
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Berrange
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-17 02:18 EDT by Alex Jia
Modified: 2013-08-09 05:48 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-09 05:48:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alex Jia 2013-07-17 02:18:00 EDT
Description of problem:
Can't successfully send signals to processes 1 in the LXC guest, and Got a timeout scheduled error "virEventPollCalculateTimeout:361 : Timeout at 1374041383550 due in 3680 ms" in libvirtd.log.

Version-Release number of selected component (if applicable):
# rpm -q libvirt libvirt-sandbox kernel
libvirt-1.1.0-1.el7.x86_64
libvirt-sandbox-0.2.1-1.el7.x86_64
kernel-3.10.0-0.rc7.64.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. virt-sandbox -c lxc:///  /bin/sh
2. virsh -c lxc:// list
3. virsh -c lxc:// send-process-signal sandbox 1 11 
4. echo $?

Actual results:
The step 3 is successfully executed and return value is 0, but the process 1 is running in the guest.

Expected results:
fix it.

Additional info:
1.
# virt-sandbox -c lxc:///  /bin/sh
sh-4.2# ps auwf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.4  1.0 166284  5744 pts/0    Ss+  13:31   0:00 /usr/libexec/libvirt-sandbox-init-common
root         3  0.0  0.3  11764  1628 pts/2    Ss   13:31   0:00 /bin/sh
root         4  0.0  0.1   9208   992 pts/2    R+   13:31   0:00  \_ ps auwf

2.
# virsh -c lxc:// list
 Id    Name                           State
----------------------------------------------------
 12494 sandbox                        running

3.
# virsh -c lxc:// send-process-signal sandbox 1 11

4.
# echo $?
0

Go to step 1 terminal
sh-4.2# ps auwf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  1.0 166284  5744 pts/0    Ss+  13:31   0:00 /usr/libexec/libvirt-sandbox-init-common
root         3  0.0  0.3  11764  1668 pts/2    Ss   13:31   0:00 /bin/sh
root         5  0.0  0.1   9208   992 pts/2    R+   14:10   0:00  \_ ps auwf



<libvirtd log slice>

2013-07-17 06:09:39.870+0000: 11516: debug : virDomainSendProcessSignal:9600 : dom=0x7f246c030f30, (VM: name=sandbox, uuid=538df6be-25c3-4534-9844-830129feddd5), pid=1, signum=11 flags=0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollMakePollFDs:393 : Prepare n=9 w=25, f=19 e=1 d=0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollMakePollFDs:393 : Prepare n=10 w=26, f=26 e=1 d=0
2013-07-17 06:09:39.870+0000: 11516: debug : virObjectRef:297 : OBJECT_REF: obj=0x7f248e6ee9a0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollMakePollFDs:393 : Prepare n=11 w=27, f=22 e=1 d=0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollMakePollFDs:393 : Prepare n=12 w=28, f=23 e=1 d=0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollMakePollFDs:393 : Prepare n=13 w=36, f=33 e=1 d=0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollMakePollFDs:393 : Prepare n=14 w=38, f=24 e=1 d=0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollMakePollFDs:393 : Prepare n=15 w=42, f=30 e=1 d=0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollCalculateTimeout:332 : Calculate expiry of 7 timers
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollCalculateTimeout:340 : Got a timeout scheduled for 1374041383550
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollCalculateTimeout:340 : Got a timeout scheduled for 1374041384020
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollCalculateTimeout:340 : Got a timeout scheduled for 1374041384870
2013-07-17 06:09:39.870+0000: 11516: debug : virObjectUnref:260 : OBJECT_UNREF: obj=0x7f248e6ee9a0
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollCalculateTimeout:353 : Schedule timeout then=1374041383550 now=1374041379870
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollCalculateTimeout:361 : Timeout at 1374041383550 due in 3680 ms
2013-07-17 06:09:39.870+0000: 11514: debug : virEventPollRunOnce:629 : EVENT_POLL_RUN: nhandles=15 timeout=3680
2013-07-17 06:09:39.870+0000: 11516: debug : virDomainFree:2322 : dom=0x7f246c030f30, (VM: name=sandbox, uuid=538df6be-25c3-4534-9844-830129feddd5)

</libvirtd log slice>
Comment 2 Daniel Berrange 2013-08-08 08:24:24 EDT
(In reply to Alex Jia from comment #0)
> Description of problem:
> Can't successfully send signals to processes 1 in the LXC guest, and Got a
> timeout scheduled error "virEventPollCalculateTimeout:361 : Timeout at
> 1374041383550 due in 3680 ms" in libvirtd.log.
> 
> Version-Release number of selected component (if applicable):
> # rpm -q libvirt libvirt-sandbox kernel
> libvirt-1.1.0-1.el7.x86_64
> libvirt-sandbox-0.2.1-1.el7.x86_64
> kernel-3.10.0-0.rc7.64.el7.x86_64
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. virt-sandbox -c lxc:///  /bin/sh
> 2. virsh -c lxc:// list
> 3. virsh -c lxc:// send-process-signal sandbox 1 11 
> 4. echo $?
> 
> Actual results:
> The step 3 is successfully executed and return value is 0, but the process 1
> is running in the guest.

That doesn't imply that libvirt isn't working. It simply means that the process is ignoring the signal you're sending


If you want to test this - you need to use 'strace' to attach to the PID 1 inside the container and watch to see if it receives the signal, and/or use 'KILL' as the signal which it cannot ignore

# ps -axuwf
root       938  0.0  0.0 190760  3280 ?        Ssl  13:23   0:00 /usr/libexec/libvirt_lxc --name sandbox --console 22 --console 23 --security=selinux --handshake 26 --background
root       944  0.5  0.0 175756  4836 pts/0    Ss+  13:23   0:00  \_ /usr/libexec/libvirt-sandbox-init-common
root       950  0.0  0.0  11768  1352 pts/2    Ss+  13:23   0:00      \_ /bin/sh

# strace -p 944
Process 944 attached
restart_syscall(<... resuming interrupted call ...>) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_USER, si_pid=0, si_uid=0} ---
restart_syscall(<... resuming interrupted call ...>
+++ killed by SIGKILL +++
Comment 3 Alex Jia 2013-08-09 01:32:50 EDT
(In reply to Daniel Berrange from comment #2)
> If you want to test this - you need to use 'strace' to attach to the PID 1
> inside the container and watch to see if it receives the signal, and/or use

Daniel, I use 'strace' to attach to the PID 1 inside the container then run 'virsh -c lxc:// send-process-signal sandbox 1 11' on the host, I haven't see any signal is received by 'strace' in the container.

 
> # ps -axuwf
> root       938  0.0  0.0 190760  3280 ?        Ssl  13:23   0:00
> /usr/libexec/libvirt_lxc --name sandbox --console 22 --console 23
> --security=selinux --handshake 26 --background
> root       944  0.5  0.0 175756  4836 pts/0    Ss+  13:23   0:00  \_
> /usr/libexec/libvirt-sandbox-init-common
> root       950  0.0  0.0  11768  1352 pts/2    Ss+  13:23   0:00      \_
> /bin/sh
> 
> # strace -p 944
> Process 944 attached
> restart_syscall(<... resuming interrupted call ...>) = ?
> ERESTART_RESTARTBLOCK (Interrupted by signal)
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_USER, si_pid=0, si_uid=0} ---
> restart_syscall(<... resuming interrupted call ...>
> +++ killed by SIGKILL +++

The above steps work well for me, it means I should use 'strace' to attach '/usr/libexec/libvirt-sandbox-init-common' process on the host rather than attaching PID 1 inside the container? or a signal is received by '/usr/libexec/libvirt-sandbox-init-common' process firstly then forward it to
PID 1 inside the container? thanks.
Comment 4 Daniel Berrange 2013-08-09 05:18:32 EDT
(In reply to Alex Jia from comment #3)
> (In reply to Daniel Berrange from comment #2)
> > If you want to test this - you need to use 'strace' to attach to the PID 1
> > inside the container and watch to see if it receives the signal, and/or use
> 
> Daniel, I use 'strace' to attach to the PID 1 inside the container then run
> 'virsh -c lxc:// send-process-signal sandbox 1 11' on the host, I haven't
> see any signal is received by 'strace' in the container.

I dont think you can be using PID 1 or you would see the signal being received.

> The above steps work well for me, it means I should use 'strace' to attach
> '/usr/libexec/libvirt-sandbox-init-common' process on the host rather than
> attaching PID 1 inside the container? or a signal is received by
> '/usr/libexec/libvirt-sandbox-init-common' process firstly then forward it to
> PID 1 inside the container? thanks.

libvirt-sandbox-init-common *IS* PID 1.
Comment 5 Alex Jia 2013-08-09 05:48:14 EDT
(In reply to Daniel Berrange from comment #4)
> > The above steps work well for me, it means I should use 'strace' to attach
> > '/usr/libexec/libvirt-sandbox-init-common' process on the host rather than
> > attaching PID 1 inside the container? or a signal is received by
> > '/usr/libexec/libvirt-sandbox-init-common' process firstly then forward it to
> > PID 1 inside the container? thanks.
> 
> libvirt-sandbox-init-common *IS* PID 1.

Oh, yes, thanks. I will close the bug as NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.