From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
/opt/informix/bin/oninit will create two shared memory segments and a semaphore
and then exit with error "1" after updating glibc-2.2.93-5 to glibc-2.3.2-4.80.

Perhaps it would be prudent in the future to not foist an obviously untested
glibc version on an unsuspecting crowd.  Is there any valid reason why the RPC
security fix couldn't have been backported to glibc-2.2.93 in order to update
RHL8.0?  How long are we going to have to wait with down databases until Red Hat
figures out what's broken in glibc-2.3.2-4.80?

Are we expected to roll back to RHL7.3 and hope that Red Hat gets the problem
resolved before product end-of-life?

Version-Release number of selected component (if applicable):
glibc-2.3.2-4.80

How reproducible:
Always

Steps to Reproduce:
1. 'onmode -ky' on a stock RHL8.0 with a functional IDS database
2. 'up2date -u' to apply the "RPC security fix"
3. 'oninit' will no longer start the database (aka "dead in the water")
    

Additional info: