Just for fun. Try the same transaction w/o swap using rpm, please.

[root@phoenix fc6]# swapoff -a ; free
             total       used       free     shared    buffers     cached
Mem:           248        231         16          0         17        122
-/+ buffers/cache:         91        156
Swap:            0          0          0
Total:         248        231         16
[root@phoenix fc6]# ls
openoffice.org-calc-2.0.4-5.3.i386.rpm          
openoffice.org-impress-2.0.4-5.3.i386.rpm
openoffice.org-core-2.0.4-5.3.i386.rpm          
openoffice.org-math-2.0.4-5.3.i386.rpm
openoffice.org-draw-2.0.4-5.3.i386.rpm          
openoffice.org-writer-2.0.4-5.3.i386.rpm
openoffice.org-graphicfilter-2.0.4-5.3.i386.rpm 
openoffice.org-xsltfilter-2.0.4-5.3.i386.rpm
[root@phoenix fc6]# rpm -ivh *
Preparing...                ########################################### [100%]
   1:openoffice.org-core    ########################################### [ 13%]
   2:openoffice.org-calc    ########################################### [ 25%]
   3:openoffice.org-draw    ########################################### [ 38%]
   4:openoffice.org-graphicf########################################### [ 50%]
   5:openoffice.org-impress ########################################### [ 63%]
   6:openoffice.org-math    ########################################### [ 75%]
   7:openoffice.org-writer  ########################################### [ 88%]
   8:openoffice.org-xsltfilt########################################### [100%]
[root@phoenix fc6]#

Could you attach a debugger or strace to the yum process and see where it is
exiting. I think I know, but I'd like to be sure.

Created attachment 155477 [details]
Strace per Seth's request

After I ran this test, I realized that this was slightly different from the case
above: it pulled in OOo-core as a dependency. I doubt that will affect the point
of the test.

It failed as follows:

[root@phoenix ~]# strace -o strace.txt yum -y install openoffice.org-draw
openoffice.org-writer openoffice.org-impress openoffice.org-xsltfilter
openoffice.org-graphicfilter openoffice.org-math openoffice.org-calc 
Loading "fedorakmod" plugin
Loading "presto" plugin
Setting up Install Process
Setting up repositories
Setting up Presto
Reading Presto metadata in from local files
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for openoffice.org-draw to pack into transaction set.
openoffice.org-draw-2.0.4 100% |=========================|  62 kB    00:00     

...

Transaction Summary
=============================================================================
Install      8 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         

Total download size: 103 M
Downloading Packages:
(1/8): openoffice.org-dra 100% |=========================| 1.1 MB    00:00     
(2/8): openoffice.org-wri 100% |=========================| 3.0 MB    00:00     
(3/8): openoffice.org-imp 100% |=========================| 1.6 MB    00:00     
(4/8): openoffice.org-xsl 100% |=========================|  96 kB    00:00     
(5/8): openoffice.org-cor 100% |=========================|  88 MB    00:16     
(6/8): openoffice.org-gra 100% |=========================| 205 kB    00:00     
(7/8): openoffice.org-mat 100% |=========================| 1.3 MB    00:00     
(8/8): openoffice.org-cal 100% |=========================| 7.7 MB    00:00     
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: openoffice.org-core          ######################### [1/8] 
[root@phoenix ~]# 


The trace file is 163 MB; I assume you don't need all of that. I have grabbed
the last 2048 lines, compressed them and attached them (comment 4). I will
preserve the whole trace in case you want more.

rt_sigaction(SIGCHLD, {0xa272f0, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0
pipe([31, 32])                          = 0
rt_sigprocmask(SIG_SETMASK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7f55708) = -1 ENOMEM (Cannot allocate memory)
close(31)                               = 0
close(32)                               = 0


ENOMEM That looks like our winner. It's just running out of memory during the
transaction. rpm grabs the signal and doesn't let us exit gracefully.

not sure what else there is to it.

How about: 

* Give the user an error message?

* Return a suitable non-zero value so that calling apps can diagnose the problem
(e.g. Anaconda)?

If this is the problem I have been hitting with installations on my firewall (67
MB of physical memory), it would be nice to know that it is a memory issue. I'm
sure I'm not the only person hitting this.

If rpm is not returning the correct return value, methinks that's an RPM bug.
Anyone care to file a report?

There's no signal delivery in the snippet in comment #6. There are SIGCHLD events later
that are reaping processes correctly. Nothing whatsoever is prohibiting "us from exiting
gracefully."

The code that is returning ENOMEM is before the pipe(2) call is a fork(), nothing more.
ENOMEM indicates that your system has insufficient resources to run a program and install
openoffice using yum.

A large part of that reason is the memory required to run yum, another part of the
problem is that openoffice is huge. The third part of the problem is that you are
attempting this on a machine with insufficient memory.

Running yum in 67MB of memory will be *ahem* exciting. Installing openoffice on
a machine with 67MB is likely impossible with yum or anaconda.

User pnasrat's account has been closed

Reassigning to owner after bugzilla made a mess, sorry about the noise...

rpm 4.4.2.1 (already released as FC6 update) and later give error messages about
fork failures (ENOMEM or otherwise). Not much else can be done here I'm afraid,
it could just as well die through OOM-killer in a lowmem situation without
having any chance to react...