Bug 1409432 - client "rhn_check" actions result in spamy system event history logs (Updated system release from XX to XX)
Summary: client "rhn_check" actions result in spamy system event history logs (Updated...
Keywords:
Status: CLOSED DUPLICATE of bug 1397308
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 2.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Tomáš Kašpárek
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space27
TreeView+ depends on / blocked
 
Reported: 2017-01-01 21:41 UTC by Fermulator
Modified: 2017-09-28 18:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-14 15:13:00 UTC
Embargoed:


Attachments (Terms of Use)

Description Fermulator 2017-01-01 21:41:49 UTC
Description of problem:
is it normal in the "events system history", to see a "Updated system release from XX to XX", every time the client runs "rhn_check"? -- my clients are configured with an hourly cron to check for Spacewalk actions, and each time, on the hour, there's a bit of a "spamy log" in the system event history like this:
     (n/a)   Updated system release from 24 to 24    Sun Jan 01 16:00:57 EST 2017


Version-Release number of selected component (if applicable):


How reproducible:
100% (in my setup)

Steps to Reproduce:
1. Have a client run "rhn_client" N times
2. Visit "https://<spacewalk-fqdn>/rhn/systems/details/history/History.do?sid=1000010000&" for the appropriate client, and observe the "spam"


Actual results:

Here's the client cron:
{{{
$ pwd
/etc/cron.hourly

$ ll
total 8
-rwxr-xr-x 1 root root 349 Aug 23 09:51 0anacron
-rwxr-xr-x 1 root root 181 Jan  1 16:38 17rhn-check

$ cat 17rhn-check 
#!/bin/sh
# To ensure timely client responses to administrator requests from Spacewalk

# Sometimes rhn_check never exits
/usr/bin/killall rhn_check

# Perform
/usr/sbin/rhn_check


}}}

Here's what the server shows:
https://<spacewalk-fqdn>/rhn/systems/details/history/History.do?sid=1000010000&
{{{
 System History
The following history events have been noted for this system.
(snip)
1 - 25 of 55
items per page
Type 	Status 	Summary 	Time
	(n/a) 	Updated system release from 24 to 24 	Sun Jan 01 16:29:23 EST 2017
	(n/a) 	Updated system release from 24 to 24 	Sun Jan 01 16:00:57 EST 2017
	(n/a) 	Updated system release from 24 to 24 	Sun Jan 01 15:00:57 EST 2017
	(n/a) 	Updated system release from 24 to 24 	Sun Jan 01 14:46:09 EST 2017
	(n/a) 	Updated system release from 24 to 24 	Sun Jan 01 14:00:57 EST 2017
	(n/a) 	Updated system release from 24 to 24 	Sun Jan 01 13:00:57 EST 2017
	(n/a) 	Updated system release from 24 to 24 	Sun Jan 01 12:00:57 EST 2017
	(n/a) 	Updated system release from 24 to 24 	Sun Jan 01 11:00:57 EST 2017 
}}}

http://pastebin.com/u9BGbbf5

Expected results:
TBD;

(personally);
 A) these logs feel "spamy" - there was really no change in the "system release" for this client, "24 to 24", so why log it?
 B) does it make sense to log something different for each rhn_check? (not sure)

Additional info:

Server-side version info:
{{{
$ cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core) 

$ uname -a
Linux <spacewalk-hostname> 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -qa | grep spacewalk
spacewalk-backend-usix-2.6.74-1.el7.noarch
spacewalk-backend-server-2.6.74-1.el7.noarch
spacewalk-backend-iss-2.6.74-1.el7.noarch
spacewalk-java-postgresql-2.6.48-1.el7.noarch
spacewalk-backend-xmlrpc-2.6.74-1.el7.noarch
spacewalk-branding-2.5.3-1.el7.noarch
spacewalk-config-2.6.5-1.el7.noarch
spacewalk-setup-postgresql-2.6.2-1.el7.noarch
spacewalk-jpp-workaround-2.3.5-1.el7.noarch
spacewalk-backend-2.6.74-1.el7.noarch
spacewalk-backend-xml-export-libs-2.6.74-1.el7.noarch
spacewalk-backend-config-files-tool-2.6.74-1.el7.noarch
spacewalk-backend-package-push-server-2.6.74-1.el7.noarch
spacewalk-base-minimal-2.6.6-1.el7.noarch
spacewalk-backend-tools-2.6.74-1.el7.noarch
spacewalk-setup-2.6.2-1.el7.noarch
spacewalk-taskomatic-2.6.48-1.el7.noarch
spacewalk-postgresql-2.6.1-1.el7.noarch
spacewalk-backend-sql-postgresql-2.6.74-1.el7.noarch
spacewalk-doc-indexes-2.5.2-1.el7.noarch
spacewalk-repo-2.6-0.el7.noarch
spacewalk-backend-libs-2.6.74-1.el7.noarch
spacewalk-backend-config-files-common-2.6.74-1.el7.noarch
spacewalk-backend-iss-export-2.6.74-1.el7.noarch
spacewalk-backend-applet-2.6.74-1.el7.noarch
spacewalk-admin-2.6.1-1.el7.noarch
spacewalk-setup-jabberd-2.3.2-1.el7.noarch
spacewalk-java-2.6.48-1.el7.noarch
spacewalk-common-2.6.1-1.el7.noarch
spacewalk-certs-tools-2.5.3-1.el7.noarch
spacewalk-search-2.6.1-1.el7.noarch
spacewalk-java-lib-2.6.48-1.el7.noarch
spacewalk-backend-app-2.6.74-1.el7.noarch
spacewalk-java-config-2.6.48-1.el7.noarch
spacewalk-base-2.6.6-1.el7.noarch
spacewalk-html-2.6.6-1.el7.noarch
rhn-org-httpd-ssl-key-pair-wtl-spacewalk-1-1.0-1.noarch
spacewalk-backend-sql-2.6.74-1.el7.noarch
spacewalk-backend-config-files-2.6.74-1.el7.noarch
spacewalk-base-minimal-config-2.6.6-1.el7.noarch
spacewalk-schema-2.6.16-1.el7.noarch
spacewalk-selinux-2.3.2-1.el7.noarch
}}}

Comment 1 Ondrej Gajdusek 2017-06-14 15:13:00 UTC
Closing as duplicate of bug 1397308, steps to reproduce this bug and results are the same. The resolution will be mentioned in BZ#1397308.

*** This bug has been marked as a duplicate of bug 1397308 ***

Comment 2 Eric Herget 2017-09-28 18:09:09 UTC
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.


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