Bug 1393948

Summary:	VirtIO logging causing critical error on rsyslogd
Product:	[Fedora] Fedora	Reporter:	Jiri Konecny <jkonecny>
Component:	rsyslog	Assignee:	Jiří Vymazal <jvymazal>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jkonecny, jlieskov, jvymazal, lkundrak, mah.darade, rsroka
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-02-02 08:53:05 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:

Description Jiri Konecny 2016-11-10 16:57:14 UTC

Description of problem:
Running virt-install with virtio logging mechanism turned on causing rsyslogd to raise critical error:


16:30:52,916 CRIT systemd-coredump:Process 1336 (rsyslogd) of user 0 dumped core.

Stack trace of thread 1336:
#0  0x00007f66df771dff afterRun (imuxsock.so)
#1  0x000055def56a2933 thrdDestruct (rsyslogd)
#2  0x000055def567fec8 llDestroyElt (rsyslogd)
#3  0x000055def567ff38 llDestroy (rsyslogd)
#4  0x000055def56a2980 thrdTerminateAll (rsyslogd)
#5  0x000055def566e7d4 main (rsyslogd)
#6  0x00007f66dfdaf451 __libc_start_main (libc.so.6)
#7  0x000055def566ea6a _start (rsyslogd)

Stack trace of thread 1352:
#0  0x00007f66e0fa029d read (libpthread.so.0)
#1  0x00007f66dde6b71f readklog (imklog.so)
#2  0x00007f66dde6ba49 klogLogKMsg (imklog.so)
#3  0x00007f66dde6ac94 runInput (imklog.so)
#4  0x000055def56a2830 thrdStarter (rsyslogd)
#5  0x00007f66e0f9672a start_thread (libpthread.so.0)
#6  0x00007f66dfe9648f __clone (libc.so.6)

Stack trace of thread 1351:
#0  0x00007f66dfe8aecd poll (libc.so.6)
#1  0x00007f66df56b6e3 runInput (imjournal.so)
#2  0x000055def56a2830 thrdStarter (rsyslogd)
#3  0x00007f66e0f9672a start_thread (libpthread.so.0)
#4  0x00007f66dfe9648f __clone (libc.so.6)

Stack trace of thread 1353:
#0  0x00007f66dfe8ce23 __select (libc.so.6)
#1  0x000055def5683943 srSleep (rsyslogd)
#2  0x00007f66ddc656bd runInput (imfile.so)
#3  0x000055def56a2830 thrdStarter (rsyslogd)
#4  0x00007f66e0f9672a start_thread (libpthread.so.0)
#5  0x00007f66dfe9648f __clone (libc.so.6)

Stack trace of thread 1355:
#0  0x00007f66e0f9c7cf pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x000055def56919fb wtiWorker (rsyslogd)
#2  0x000055def5690a10 wtpWorker (rsyslogd)
#3  0x00007f66e0f9672a start_thread (libpthread.so.0)
#4  0x00007f66dfe9648f __clone (libc.so.6)


Version-Release number of selected component (if applicable):
8.21.0-1.fc26

How reproducible:
Always

Steps to Reproduce:
1. Run virt-install with option
--channel 'tcp,host=127.0.0.1:41257,mode=connect,target_type=virtio,name=org.fedoraproject.anaconda.log.0'


Actual results:
Critical error is logged

Expected results:
Should work without error

Additional info:
Whole command I'm using for virt-install:

sudo virt-install -n LiveOS-de3b8e49-d8ad-4d2a-a92f-2389e00c0865 -r 1024 --noreboot --noautoconsole --graphics vnc --initrd-inject /<dir>/kickstart-tests/hostname.ks --disk 'path=/var/tmp/kstest-hostname.hnkCGZFs/disk-a.img,cache=unsafe' --disk 'path=/var/tmp/kstest-hostname.hnkCGZFs/boot.iso,device=cdrom,readonly=on,shareable=on' --extra-args 'ks=file:/hostname.ks vnc debug=1 inst.debug stage2=hd:CDLABEL=Fedora-23-x86_64' --location /var/tmp/kstest-hostname.hnkCGZFs/lorax.imgutils.2j1ooas_ --channel 'tcp,host=127.0.0.1:41257,mode=connect,target_type=virtio,name=org.fedoraproject.anaconda.log.0'

Comment 1 Jiří Vymazal 2017-01-02 10:13:10 UTC

could you please provide description of needed environment to reproduce this?

Comment 2 Jiri Konecny 2017-01-04 12:41:17 UTC

Hi Jirka,

We are using this for running our installation tests and this is a blocker for these tests now. I wanted to create simple reproducer but it's not an easy task to set-up everything so I instead created a tar file with scripts which can be used to reproduce this and with README in it.

I have it but I don't have functional rawhide boot.iso for testing so it's useless. I will give this to you immediately when functional boot.iso arrive.

Comment 3 Jiri Konecny 2017-02-02 08:53:05 UTC

Rawhide is again usable and it looks like something else fixed this issue. I can't reproduce it anymore. I'm closing this bug now.

Thank you for looking on this.

Jirka