Bug 1812785

Summary: virtlogd does timeout quit even when running guest exist
Product: Red Hat Enterprise Linux 9 Reporter: Yanqiu Zhang <yanqzhan>
Component: libvirtAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED WONTFIX QA Contact: Yanqiu Zhang <yanqzhan>
Severity: low Docs Contact:
Priority: low    
Version: 9.0CC: berrange, chhu, dyuan, fjin, jsuchane, lmen, virt-maint, xuzhang, yanqzhan
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-09-12 07:26:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
virtlogd.log none

Description Yanqiu Zhang 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 Yanqiu Zhang 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.