suche 36x36
  • Admin-Scout-small-Banner
           

    CURSOR Admin-Scout

    get the ultimate tool for Informix

    pfeil  
Latest versionsfixlist
14.10.xC10 FixList
12.10.xC16.X5 FixList
11.70.xC9.XB FixList
11.50.xC9.X2 FixList
11.10.xC3.W5 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

Informix - Problem description

Problem IT38143 Status: Closed

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

product:
INFORMIX SERVER / 5725A3900 / E10 - 
Problem 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.
Problem Summary:
Local Fix:
Solution
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
24.08.2021
05.10.2022
06.10.2022
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
Informix EditionsInformix Editions
Informix Editions
DocumentationDocumentation
Documentation
IBM NewsletterIBM Newsletter
IBM Newsletter
Current BugsCurrent Bugs
Current Bugs
Bug ResearchBug Research
Bug Research
Bug FixlistsBug Fixlists
Bug Fixlists
Release NotesRelease Notes
Release Notes
Machine NotesMachine Notes
Machine Notes
Release NewsRelease News
Release News
Product LifecycleProduct Lifecycle
Lifecycle
Media DownloadMedia Download
Media Download