RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 916666 - Displayed 'Next System Check-In' is inaccurate
Summary: Displayed 'Next System Check-In' is inaccurate
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: beta
: 7.0
Assignee: William Poteat
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: rhsm-rhel70
TreeView+ depends on / blocked
 
Reported: 2013-02-28 16:02 UTC by J.C. Molet
Modified: 2014-06-18 00:24 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 11:49:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
rhsmcertd and next system check (567.71 KB, image/png)
2014-01-28 15:13 UTC, Sharath Dwaral 		no flags Details
View All

Description J.C. Molet 2013-02-28 16:02:15 UTC 
Description of problem:
The 'Next System Check-in' time is innacurate in the Help > About window.

Version-Release number of selected component (if applicable):
subscription-manager-1.8.3-1.git.14.a306b0c.el6.x86_64
subscription-manager-gui-1.8.3-1.git.14.a306b0c.el6.x86_64
python-rhsm-1.8.5-1.git.0.c3e0d11.el6.x86_64


How reproducible:
always

Steps to Reproduce:
Part A)
1. Restart rhsmcertd: service rhsmcertd restart
2. Wait about 3 minutes for the cert check to occur
3. Check the timestamp of the last "Cert Check" in /var/log/rhsm/rhsmcertd.log (note: this should be the same time that the top of the facts window in the gui shows)
4. Add to this timestamp the interval certCheckInterval in /etc/rhsm/rhsm.conf
5. Compare that time to the time shown in Help > About
  
Part B)
1. Turn off rhsmcertd: service rhsmcertd stop
2. Check the time in Help > About

Actual results:
Part A) The calculated next check in is calculated using the time found in /var/run/rhsm/update .  This time seems to represent whenever the rhsmcertd started and not when the last attempted Cert Check happened.  This causes the check time to be several minutes off.

Part B) The time is still calculated as above.

Expected results:
Part A) The time displayed should be the time of the last actual Cert Check + certCheckInterval.

Part B) Since rhsmcerd is off the update may or may not ever happen.  In this case the Next System Check-in should be N/A or Unknown.

Additional info:
Comment 2 Adrian Likins 2013-11-05 15:12:15 UTC 
For part A:

  - The time in the facts dialog is the timestamp of the facts cache, that should
    only get updated if the local facts have changed from what was last sent
    to the server. So it can drift from the time of the last checkin (and/or not
    equals last_checkin+cert_interval 

  - the value or the next checkin time from /var/run/rhsm/update incorrectly only
    gets set once. (To the time the first scheduled checkin after the inital_delay check in). So currently it's basically always wrong.
Comment 3 Carter Kozak 2013-11-07 13:24:23 UTC 
commit 0c7c9179a45440de3bcb4722210756229225b49d
Author: William Poteat <wpoteat>
Date:   Tue Nov 5 08:26:18 2013 -0500

    916666: Displayed 'Next System Check-In' is inaccuarate
    
    GUI now does not show next checkin time when rhsmcertd is not running
    update file is now updated each time the frequency is reached so that the checkin
    time in the about pane is correct.
Comment 4 William Poteat 2013-11-07 14:18:55 UTC 
The initial next time is set at startup. that time will reflect when the timed, repeating, cert-refresh will occur.

The initial cert refresh is a one off. It runs 2 minutes after the service starts because it waits for the service to fully initialize. It is not reflected in the about screens reporting.
Comment 5 William Poteat 2013-11-07 14:25:59 UTC 
master commmit 0c7c9179a45440de3bcb4722210756229225b49d
Comment 7 Sharath Dwaral 2013-11-13 15:16:00 UTC 
Version:

# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.8.31-1
subscription-manager: 1.10.6-1.el7
python-rhsm: 1.10.6-1.el7

Scenario 1: Restart rhsmcertd server, wait for 3 mins, verify rhsmcertd.log to have performed [cert-check], in GUI->Help->About verify "Next-System-Check" is four hours (certCheckInterval= 240 from conf file) from when [cert-check] was last performed.

VERIFIED

Scenario 2: Change the "certCheckInterval" in conf file to a low value for example 4mins and restart rhsmcertd. Verify rhsmcertd.log file to have performed [cert-check], in GUI->Help->About verify Next-System-Check is 4mins from when [cert-check] was last performed. Wait for 4mins and verify whether [cert-check] was performed again and also whether "Next-System-Check" was updated appropriately.

VERIFIED

Scenario 3: stop rhsmcertd server. in GUI->Help->About verify Next-System-Check is Unknown/Blank.

FAILED

In this scenario after executing 'service rhsmcertd stop' rhsmcertd.log is updated accordingly to 'shutting down rhsmcertd server'.  'service rhsmcertd status' displays inactive/dead. But on the GUI the "Next-System-Check" does not get updated.


Moving back to ASSIGNED
Comment 8 William Poteat 2014-01-02 13:52:33 UTC 
master commit 5cfb3a01f848071f1dcda87634517613fe6e35f7

correctly updates about panel based on rhsmcertd status
Comment 9 Sharath Dwaral 2014-01-28 15:13:15 UTC 
Created attachment 856660 [details]
rhsmcertd and next system check

Version

# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.9.2-1
subscription-manager: 1.10.11-1.el7
python-rhsm: 1.10.11-1.el7

Verification:

See attachment for GUI Verification

Scenario 1:

Tue Jan 28 09:38:22 2014 [INFO] Waiting 120 second(s) [2.0 minute(s)] before running updates.
Tue Jan 28 09:40:29 2014 [INFO] (Auto-attach) Certificates updated.
Tue Jan 28 09:40:31 2014 [INFO] (Cert Check) Certificates updated.

     >>>>    VERIFIED    <<<<

Scenario 2:

# cat /etc/rhsm/rhsm.conf | grep "certCheckInterval" -B1
# Interval to run cert check (in minutes):
certCheckInterval = 4

Tue Jan 28 09:47:08 2014 [INFO] Waiting 120 second(s) [2.0 minute(s)] before running updates.
Tue Jan 28 09:49:10 2014 [INFO] (Auto-attach) Certificates updated.
Tue Jan 28 09:49:12 2014 [INFO] (Cert Check) Certificates updated.
Tue Jan 28 09:51:10 2014 [INFO] (Cert Check) Certificates updated.

Tue Jan 28 09:55:09 2014 [INFO] (Cert Check) Certificates updated.

    >>>>    VERIFIED    <<<<

Scenario 3:

Tue Jan 28 10:00:26 2014 [INFO] rhsmcertd is shutting down...


    >>>>    VERIFIED    <<<<
Comment 11 Ludek Smid 2014-06-13 11:49:17 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.