IBM Support

IT38143: ONTAPE RESTORE CAN HANG OR FAIL WITH EPIPE ERRNO 32 WHEN USING RESTORE_FILTER

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as duplicate of another APAR.

Error description

  • This problem was reported running IDS 14.10.FC6 on linux x86_64.
    
    The customer reported that ontape -r was failing with EPIPE when
    the RESTORE_FILTER
    was being used.
    
    The problem was reported for any combo of BACKUP_FILTER and
    RESTORE_FILTER in the customerâ ™s
    environment, for instance, the ontape -r failed for both value
    sets below:
    
        BACKUP_FILTER   /bin/gzip
        RESTORE_FILTER  /bin/gzip -d
    
        BACKUP_FILTER   /bin/compress
        RESTORE_FILTER  /bin/uncompress
    
    When the problem occurs the ontape -r restores is able to pull
    the chunk and dbspace data from the
    backup device, but before asking if the user would like to
    ⠜Continue restore? (y/n)⠝, the process fails
    with an EPIPE error like:⠨⠨
    
    Write failed on parent's output pipe. errno = 32.
    Physical restore failed - function close archive tape failed
    code 255 errno 0
    
    This was observed on RHEL 8.
    
    Interestingly enough, the problem does not persist across all
    platforms running RHEL 8 as our initial
    attempts to reproduce the failure were unsuccessful and the
    restore process was success using
    the RESTORE_FILTER.
    
    Also, adding a little complexity to the defect, on a linux
    machine runningn RHEL 7.4, it was observed
    in my testing that the ontape process could hang indefinitely
    after printing out dbspace and chunk
    info but before asking if the user would like to â œContinue
    restore (y/n)⠝
    
    In the hang case, you can see the TAPEIO process that is forked
    from the ontape -r process waits
    indefinitely in the following stack, gathered from pstack.⠨⠨
    
    #0  0x00007feef429a690 in __write_nocancel () at
    ../sysdeps/unix/syscall-template.S:81
    #1  0x000000000068fa74 in write_to_filter ()
    #2  0x000000000049cdb5 in read_filter_from_dev ()
    #3  0x000000000068e258 in create_filter ()
    #4  0x000000000049d099 in start_restore_filter ()
    #5  0x00000000004ad1d9 in first_read_phys_tape ()
    #6  0x00000000004a79ad in do_cold_phys_restore ()
    #7  0x000000000049c47e in main ()
    
    Not using BACKUP_FILTER and RESTORE_FILTER could be a
    workaround, but it you are in a situation
    where you need to restore from an archive that used a
    BACKUP_FILTER, the workaround is useless
    as you have to use RESTORE_FILTER.
    

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

  • This APAR is a duplicate of IT36381
    

APAR Information

  • APAR number

    IT38143

  • Reported component name

    INFORMIX SERVER

  • Reported component ID

    5725A3900

  • Reported release

    E10

  • Status

    CLOSED DUB

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2021-08-24

  • Closed date

    2022-10-05

  • Last modified date

    2022-10-06

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SSGU8G","label":"Informix Servers"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"E10"}]

Document Information

Modified date:
07 October 2022