Bug 1010205

Summary:	binary gzip content gets displayed as reposync log
Product:	Red Hat Satellite 5	Reporter:	Martin Korbel <mkorbel>
Component:	Server	Assignee:	Michael Mráka <mmraka>
Status:	CLOSED ERRATA	QA Contact:	Martin Korbel <mkorbel>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	560	CC:	cperry, mzazrivec, tlestach, xdmoon
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	spacewalk-java-2.0.2-56 spacewalk-backend-2.0.3-20	Doc Type:	Bug Fix
Doc Text:	Consequence: After reposync logs were logrotated, Webui displayed binary gzipped log content on the WebUI, Result: WebUI displays only text files, when displaying reposync logs.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-01-20 09:22:48 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:
Bug Depends On:
Bug Blocks:	924189

Description Martin Korbel 2013-09-20 08:48:03 UTC

Description of problem:
This bug bz645435 makes problem with link "This channel has never been synced to external repositories" in "Channels" > "Software Channel Management" > detail of a custom channel, when the logrotate makes gzip file from log file in /var/log/rhn/reposync/.
Log file is non-ascii file (it is the broken gzip file).

I think, the root of this problem is it, that the satellite takes the last log file from /var/log/rhn/reposync/, what matches with channel name. When the timestamp was in the name of the log file, all were correct. The bug bz645435 removes timestamp from the log name and alse it setups logrotate (it makes gz file).

When I have removed the gzip archiv of the log file, the link shown correct log file.

Other questions arise here:
1. If logrotate erases the log file, the satellite will show empty log. Is it correct behavior?
2. If the satellite syncs very often, the last log will be on the tail of log file / page. I think before bz645435, the last log was on the first.


Version-Release number of selected component (if applicable):
spacewalk-backend-2.0.3-2 and newer

How reproducible:
100%

Steps to Reproduce:
1. make new repository
   label: fedora-19-x86_64
   url: http://download.eng.brq.redhat.com/pub/fedora/linux/releases/19/Everything/x86_64/os/
2. make new custom channel and add repo fedora-19-x86_64 into it
3. sync the channel (it takes long time).
4. check the log file using WebUI (log is OK)
5. run logrotate manually
> logrotate -fv /etc/logrotate.d/spacewalk-backend-tools
6. check the log file using WebUI (log is non-ascii).


Actual results:
log is non-ascii

Expected results:
log is ascii

Additional info:

Comment 1 Tomas Lestach 2013-11-28 16:08:50 UTC

spacewalk.git: 5226d5c49b68bb205e23c68dbfb53645f61e0442

Comment 4 Martin Korbel 2014-01-13 13:21:10 UTC

VERIFIED on spacewalk-java-2.0.2-56.el6sat and spacewalk-backend-2.0.3-20.el6sat
REPRODUCED on spacewalk-java-2.0.2-50.el6sat and spacewalk-backend-2.0.3-18.el6sat

The problem with non-ascii content is fixed. WebUI displays last  (readable) log file and if this file is empty after logrotate, WebUI displays pre-last  (readable) log file.  All older log files are compressed.

Comment 6 errata-xmlrpc 2014-01-20 09:22:48 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0042.html