Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1903574

Summary: `pcp atopsar` ignores `-e` option (end time)
Product: Red Hat Enterprise Linux 7 Reporter: Paulo Andrade <pandrade>
Component: pcpAssignee: pcp-maint <pcp-maint>
Status: CLOSED WONTFIX QA Contact: Jan Kurik <jkurik>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.9CC: agerstmayr, dvolkov, jkurik, mgoodwin, nathans, pandrade, patrickm, peter.vreman
Target Milestone: rcKeywords: Bugfix, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1851838 Environment:
Last Closed: 2020-12-03 23:21:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1851838    
Bug Blocks:    

Description Paulo Andrade 2020-12-02 12:16:51 UTC 
+++ This bug was initially created as a clone of Bug #1851838 +++

Description of problem:
`pcp atopsar` ignores `-e` option that specifies the ending   time for the output

Version-Release number of selected component (if applicable):
Reproduced on pcp-5.0.2-5.el8.x86_64

How reproducible:

pcp atopsar -s -R 60 -r y -b 23:00 -e 23:20

        2020/06/22

-------------------------- analysis date: 2020/06/21 --------------------------

23:00:20  pagescan/s   swapin/s  swapout/s        commitspc  commitlim   _swap_
23:10:10        0.00       0.00       0.00            1082M      5326M
23:20:10        0.00       0.00       0.00            1082M      5326M
23:30:10        0.00       0.00       0.00            1082M      5326M
23:40:10        0.00       0.00       0.00            1082M      5326M
^C (the output does not stop at 23:30, but continues...)

pcp atopsar ignores both options:
          -e  finish showing data after specified time
          --finish TIME end of the time window


Expected results:
pcp atopsar should end the output as specified in `-e` or `--finish` options

--- Additional comment from Nathan Scott on 2020-07-21 03:06:27 UTC ---

This is resolved upstream and will be in pcp-5.2.0

commit 0b861b081760904632c6854247b254174d6fd551
Author: Nathan Scott <nathans>
Date:   Tue Jul 21 13:05:00 2020 +1000

    pcp-atop: fix logic around the end of an optional time window
    
    Regression test qa/1820 is updated to exercise this.
    
    Resolves Red Hat BZ #1851838.


------

  Can the patch be backported to rhel-7.9z pcp-4.3.2?
  At a first glance, it appears a patch backport is mostly trivial.

  Reasoning is:

"""
When you are troubleshooting then you must have reliable tooling and not something that is failing without any resaon and then stopping the troubleshooting the production issue and get distracted on tooling.
Therefor I expect that the following fixes to be made availanble in RHEL7.x
- No Segfault
- Correct begin-end timestamp handling like in BZ1851838
- Error message if the time range is not in the file, provide enough feedback to the user to mention what time range is inlcuded in the file.

This is really Basic functionality of metrics analyzing that i as troubleshooter must rely on to work and therefor I expect this to be in RHEL7 zstream 
"""
Comment 1 Nathan Scott 2020-12-02 22:07:15 UTC 
Hi Paulo,

These are the requirements for zstream inclusion:
https://source.redhat.com/groups/public/extended-update-support/extended_update_support_wiki/consolidated_zstream_process_for_rhel_76#jive_content_id_Scope_of_inclusion

From your description above I'm not sure these are going to be met (especially point #1 there which mandates "business impacting issue that causes production outage").


I'm not sure about the workflow you use, but I should mention that PCP archives can be analysed using any version of PCP (and always best with the latest version - backwards compatibility is always preserved).  For your analysis needs you might be able to do your production system analysis using a machine with the upstream PCP builds for RHEL-7 installed (https://bintray.com/pcp/el7), which always include the latest fixes and optimizations.  Or perhaps using a Fedora machine for post-incident analysis which naturally tracks upstream PCP much more closely than RHEL.

As a developer, I appreciate it immensely when folk like yourself use the most recent PCP release because this directly contributes to the quality of what ends up in RHEL being consumed by customers - we find and fix bugs like this one much more quickly.  Taking either of my suggested paths above would see you with this fix installed locally today, as well as running with other new features that wont be seen in RHEL for months / years (or ever, in the case of RHEL7 now).  For example pcp-atop recently acquired process accounting support from our friends at Fujitsu.  Our colleague agerstmayr is also working on pcp-atop support for per-process networking stats for an upcoming release.

cheers.
Comment 2 Peter Vreman 2020-12-03 08:25:42 UTC 
Nathan,

It is how you look at production outage, in this case the outage duration might be impacted:

If analyzing/troubleshooting tooling is not working a business production outage can take longer to analyze befor you have a clue what has wrong and you can repair to start the production processes again.


Peter
Comment 3 Nathan Scott 2020-12-03 23:21:18 UTC 
Hi Peter,

I understand where you are coming from, but the zstream wording is very clear - the issue must *cause* a production outage in order for RHEL6 or RHEL7 consideration at this stage of their lifecycle.

Naturally this fix will be included in the next available RHEL8.x release.

cheers.