OpenStack Backup/Restore and DR (Freezer)

Freezer Tar Error Handling Not Working Correctly

Bug #1591347 reported by Deklan Dieterly
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Backup/Restore and DR (Freezer)
Fix Released
Undecided
Unassigned
OpenStack Backup/Restore and DR (Freezer) newton-2 "n2"
Mitaka
New
Undecided
Unassigned

Bug Description

Freezer Tar error handling does not work correctly. The code is checking for the string 'error' in the stderr of the Tar subprocess. The string 'error' does not exist when an error is encountered in the Tar subprocess. The result is that the error checking code never invokes the error handling code when a Tar error occurs.

In addition, the error handling code does a sys.exit(1). This only shutdown the current Tar thread while the write thread is still active. The result is that the process hangs and never shuts down. sys.exit(1) needs to be changed to os._exit(1). This terminates all threads and the entire process.

Deklan Dieterly (deklan)
Changed in freezer:
status: New → In Progress
Revision history for this message
Deklan Dieterly (deklan) wrote :

Review: https://review.openstack.org/#/c/327914/

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to freezer (master)

Reviewed: https://review.openstack.org/327914
Committed: https://git.openstack.org/cgit/openstack/freezer/commit/?id=75f2c9db3589e729ac2a522961cc12799eea87db
Submitter: Jenkins
Branch: master

commit 75f2c9db3589e729ac2a522961cc12799eea87db
Author: Deklan Dieterly <email address hidden>
Date: Mon Jun 13 07:42:34 2016 -0600

    Fix gnu tar error handling

    Make gnu tar backup and restore error handling work correctly.
    Check stderr from gnu tar subprocess for any non-empty string.
    Current implementation checks for 'error' string in stderr,
    and fails to catch and log errors.

    Change sys.exit(1) to os._exit(1) when handling gnu tar error
    so that all threads terminate. Currently the process will
    hang because all threads are not terminated when a gnu tar
    error occurs. os_exit(1) will terminate all threads
    and the entire process when a gnu tar error occurs.

    Change-Id: Icf265ade8d5e4c9b55aee50faa40334d89d664f1
    Closes-Bug: #1591347

Changed in freezer:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to freezer (stable/mitaka)

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/329937

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to freezer (stable/mitaka)

Reviewed: https://review.openstack.org/329937
Committed: https://git.openstack.org/cgit/openstack/freezer/commit/?id=dccffed8b5d2b3010f390d5f30f0916015d5e82b
Submitter: Jenkins
Branch: stable/mitaka

commit dccffed8b5d2b3010f390d5f30f0916015d5e82b
Author: Deklan Dieterly <email address hidden>
Date: Mon Jun 13 07:42:34 2016 -0600

    Fix gnu tar error handling

    Make gnu tar backup and restore error handling work correctly.
    Check stderr from gnu tar subprocess for any non-empty string.
    Current implementation checks for 'error' string in stderr,
    and fails to catch and log errors.

    Change sys.exit(1) to os._exit(1) when handling gnu tar error
    so that all threads terminate. Currently the process will
    hang because all threads are not terminated when a gnu tar
    error occurs. os_exit(1) will terminate all threads
    and the entire process when a gnu tar error occurs.

    Change-Id: Icf265ade8d5e4c9b55aee50faa40334d89d664f1
    Closes-Bug: #1591347
    (cherry picked from commit 75f2c9db3589e729ac2a522961cc12799eea87db)

tags: added: in-stable-mitaka
Pierre-Arthur MATHIEU (pi3rra)
Changed in freezer:
milestone: none → newton-2
Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/freezer 3.0.0.0b2

This issue was fixed in the openstack/freezer 3.0.0.0b2 development milestone.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.