Bug 1812785 - virtlogd does timeout quit even when running guest exist
Summary: virtlogd does timeout quit even when running guest exist
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libvirt
Version: 9.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: yanqzhan@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-12 07:41 UTC by yanqzhan@redhat.com
Modified: 2021-09-12 07:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-09-12 07:26:58 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
virtlogd.log (6.02 KB, application/gzip)
2020-03-12 07:47 UTC, yanqzhan@redhat.com
no flags Details

Description yanqzhan@redhat.com 2020-03-12 07:41:29 UTC
Description of problem:
virtlogd does timeout quit even when running guest exist

Version-Release number of selected component (if applicable):
libvirt-daemon-6.0.0-10.module+el8.2.0+5984+dce93708.x86_64
qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Set timeout args for virtlogd by /etc/sysconfig/virtlogd, e.g.30s:
VIRTLOGD_ARGS="--timeout=30"

2. Restart virtlogd and timewait
# systemctl restart virtlogd

# ps -fC virtlogd
UID          PID    PPID  C STIME TTY          TIME CMD
root       30814       1  0 03:15 ?        00:00:00 /usr/sbin/virtlogd --timeout=30

3.start a guest
# virsh start ovmf_uefi 
Domain ovmf_uefi started

# lsof /var/log/libvirt/qemu/ovmf_uefi.log 
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
virtlogd 30814 root   17w   REG  253,0    24058 50565188 /var/log/libvirt/qemu/ovmf_uefi.log

4. Check virtlogd status until timeout
# ps -fC virtlogd
UID          PID    PPID  C STIME TTY          TIME CMD

# virsh list --all
 Id   Name                    State
----------------------------------------
 1    ovmf_uefi               running

# lsof /var/log/libvirt/qemu/ovmf_uefi.log
(nothing output)

Actual results:
virtlogd does timeout quit even when running guest exist

Expected results:
virtlogd should not quit if any guest is running.

Additional info:
The default timeout for session mode(120s) works well: no quit if any guest is running, timeout quit after destroy guest.

Comment 1 yanqzhan@redhat.com 2020-03-12 07:47:26 UTC
Created attachment 1669572 [details]
virtlogd.log

Comment 2 Jaroslav Suchanek 2020-05-06 20:45:18 UTC
Well from man page:
       -t, --timeout SECONDS

       Automatically shutdown after SECONDS have elapsed with no active console log.

And from the log:
2020-03-12 07:15:54.203+0000: 30814: debug : virEventPollCalculateTimeout:354 : Schedule timeout then=1583997384203 now=1583997354203
2020-03-12 07:15:54.203+0000: 30814: debug : virEventPollCalculateTimeout:364 : Timeout at 1583997384203 due in 30000 ms
2020-03-12 07:15:54.203+0000: 30814: info : virEventPollRunOnce:635 : EVENT_POLL_RUN: nhandles=5 timeout=30000
2020-03-12 07:16:24.234+0000: 30814: debug : virEventPollRunOnce:651 : Poll got 0 event(s)
2020-03-12 07:16:24.234+0000: 30814: debug : virEventPollDispatchTimeouts:427 : Dispatch 2
2020-03-12 07:16:24.234+0000: 30814: info : virEventPollDispatchTimeouts:450 : EVENT_POLL_DISPATCH_TIMEOUT: timer=1
2020-03-12 07:16:24.234+0000: 30814: debug : virNetDaemonAutoShutdownTimer:744 : Automatic shutdown triggered

So it looks to me, that it works as expected. Daniel, can you please confirm? Thanks.

Comment 3 Daniel Berrangé 2020-05-07 09:06:04 UTC
This is a known bug - the handling of --timeout is broken for virtlogd running privileged.  We don't enable --timeout out of the box so it shouldn't affect users normally, but it none the less needs fixing.

Comment 6 John Ferlan 2021-09-08 13:31:35 UTC
Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Comment 7 RHEL Program Management 2021-09-12 07:26:58 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


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