Bug 1010205 - binary gzip content gets displayed as reposync log
binary gzip content gets displayed as reposync log
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Michael Mráka
Martin Korbel
: Regression
Depends On:
Blocks: sat560-triage
  Show dependency treegraph
Reported: 2013-09-20 04:48 EDT by Martin Korbel
Modified: 2014-01-20 11:41 EST (History)
4 users (show)

See Also:
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:
Last Closed: 2014-01-20 04:22:48 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Martin Korbel 2013-09-20 04:48:03 EDT
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
   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 11:08:50 EST
spacewalk.git: 5226d5c49b68bb205e23c68dbfb53645f61e0442
Comment 4 Martin Korbel 2014-01-13 08:21:10 EST
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 04:22:48 EST
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.