Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1010205 - binary gzip content gets displayed as reposync log
Summary: binary gzip content gets displayed as reposync log
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server
Version: 560
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Michael Mráka
QA Contact: Martin Korbel
Depends On:
Blocks: sat560-triage
TreeView+ depends on / blocked
Reported: 2013-09-20 08:48 UTC by Martin Korbel
Modified: 2014-01-20 16:41 UTC (History)
4 users (show)

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.
Clone Of:
Last Closed: 2014-01-20 09:22:48 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 645435 None None None Never
Red Hat Product Errata RHBA-2014:0042 normal SHIPPED_LIVE Red Hat Satellite server bug fix update 2014-01-20 14:22:18 UTC

Internal Links: 645435

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:

Steps to Reproduce:
1. make new repository
   label: fedora-19-x86_64
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.

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