Bug 1494389
Summary: | rhn_check does not handle reboot coming from outside well | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Tomáš Kašpárek <tkasparek> |
Component: | rhn-client-tools | Assignee: | Tomáš Kašpárek <tkasparek> |
Status: | CLOSED ERRATA | QA Contact: | Red Hat Satellite QA List <satqe-list> |
Severity: | unspecified | Docs Contact: | Filip Hanzelka <fhanzelk> |
Priority: | unspecified | ||
Version: | 7.4 | CC: | jdostal, jhutar, mcorr, tkasparek, tlestach |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | rhn-client-tools-2.0.2-19-el7 | Doc Type: | Release Note |
Doc Text: |
"rhn_check" now correctly reports system reboots to Satellite
Previously, if a system reboot of a Satellite client occurred during a "rhn_check" run, "rhn_check" did not report its termination to Satellite. Consequently, the status of "rhn_check" in Satellite did not update.
With this update, this incorrect behavior is fixed and "rhn_check" now handles system reboots and reports the correct status to Satellite.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2018-04-10 12:17:18 UTC | Type: | Bug |
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: | |||
Bug Blocks: | 1467342, 1491451, 1498813 |
Description
Tomáš Kašpárek
2017-09-22 07:34:19 UTC
revert of old commits regarding reboot loop: spacewalk.git(master): 9ac3f5e5f59942f796f55a54de825a1a9e538ecd spacewalk.git(master): a2f80a2e37122eab360905c08799130cbf8ca8ab spacewalk.git(master): 5c57677a2d3279508a699b7bd4048411295f06c5 spacewalk.git(master): ddb5fa44c02d9cb913f5e2b38514bb6ed8d34f20 spacewalk.git(master): 850abcc8677cf7ad8095f159f71383cdc8076e43 actual fix: spacewalk.git(master): 6f939e091079a543c91aa0108a7acb16f0658f09 >> rpm -q rhn-client-tools
rhn-client-tools-2.0.2-20.el7.noarch
I received following traceback (procedure by description). It doesn't look as correct message.
[Fri Dec 8 06:12:49 2017] up2date D: do_call script.run(129369, {'username': 'root', 'groupname': 'root', 'now': '2017-12-08 06:12:49', 'timeout': 600, 'script': '#!/bin/sh\n# Add your shell script below\n\nsleep 200\n'}){'cache_only': None}
[Fri Dec 8 06:13:30 2017] up2date
Traceback (most recent call last):
File "/usr/sbin/rhn_check", line 374, in __run_action
(status, message, data) = CheckCli.__do_call(method, params, kwargs)
File "/usr/sbin/rhn_check", line 367, in __do_call
retval = method(*params, **kwargs)
File "/usr/share/rhn/actions/script.py", line 260, in run
input_fds, output_fds, error_fds = select.select([pipe_read], [], [], select_wait)
File "/usr/share/rhn/actions/script.py", line 58, in handle
raise SystemExit(SYSEXIT_CODE)
<type 'exceptions.SystemExit'>: 3
>> getenforce Permissive >> rhn_check -vv ... WebUI: Client execution returned "Fatal error in Python code occurred [[6]]" (code -1) >> tail /var/log/up2date (status, message, data) = CheckCli.__do_call(method, params, kwargs) File "/usr/sbin/rhn_check", line 367, in __do_call retval = method(*params, **kwargs) File "/usr/share/rhn/actions/script.py", line 260, in run input_fds, output_fds, error_fds = select.select([pipe_read], [], [], select_wait) File "/usr/share/rhn/actions/script.py", line 58, in handle raise SystemExit(SYSEXIT_CODE) <type 'exceptions.SystemExit'>: 3 >> rpm -q rhn-client-tools rhn-client-tools-2.0.2-21.el7.noarch I expect msg: "Script executed. Termination signal occurred during execution" Verified with new version of rhncfg-* and rhn-client-tools-2.0.2-21.el7.noarch signal SIGKILL - D: Sending back response(255, "Previous run of action didn't completed sucessfully, aborting.", {}) signal SIGTERM - D: Sending back response(255, 'Termination signal occurred during execution.', {}) 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. https://access.redhat.com/errata/RHBA-2018:0759 |