A.P. Lawrence

EAGAIN error

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From - Sat Sep 18 07:29:00 1999
Xref: world comp.unix.sco.misc:105540
Newsgroups: comp.unix.sco.misc
Path: world!newsfeed.mathworks.com!outfeed1.news.cais.net!info.usuhs.mil!uky.edu!xenitec!news
From: Bela Lubkin <belal@sco.COM>
Subject: Re: Fork failing, but WHY??
Resent-From: mmdf@xenitec.on.ca
Submit-To: scomsc@xenitec.on.ca
Cc: cegis@compuserve.com
Organization: work for SCO, speak for myself
Date: Fri, 17 Sep 1999 20:37:46 GMT Message-ID: <199909171337.aa28614@rubidium.pdev.caldera.com> References: <7rtv3s$jke$1@nnrp1.deja.com>
Sender: news@xenitec.on.ca (xenitec.on.ca News Administrator)
Precedence: list
Lines: 223
X-Mozilla-Status: 8011

Carl Sopchak wrote:

> I need some help trying to figure out why a client's program is crashing with
> a EAGAIN (11) error returned from fork(S).
> 
> Here's the environment (basically the same for the two machines described
> below):  Clean install of OSR 5.0.5 with RS505A, UDK Compatibility and
> OSS497B installed, at least 128Mb ram, at least 512Mb swap.  Same stune file.
>  All testing / sleuthing on the client machine was done on a Saturday, with
> no other users.
> 
> Here's the scenario:  I wrote a program using a 4GL called Speedware, which
> shells to the OS to create a temporary file (with touch), run a section of
> code that uses that file, and upon return, shells out again to remove the
> temporary file.

I'm not familiar with Speedware.  But the fact that you've installed the
UDK runtime sets off a possible alarm: are the Speedware binaries you're
running UnixWare binaries?  I've done some kernel analysis below.  I
didn't look into the UDK shim libraries.  It is possible that the UDK
libc's fork() function does more than just call the underlying
OpenServer fork(); it might do other things which could also return
EAGAIN; or it might in fact set errno = EAGAIN itself, under certain
conditions.  (I'm not saying this is *likely*, just that I haven't
investigated it, making a hole in my analysis below.)

> On my development system, I can run this procedure an "infinate" number of
> times successfully.  On my client's system, things start failing quickly. 
> Namely, upon the first time running it, the first fork succeeds, creating the
> temporary file.  Upon returning, however, the second fork fails, leaving the
> temporary file behind.     If the logic is re-run, the first fork fails, so the
> program crashes (with "file not found") because it does not find the
> temporary file.

If I hadn't seen the rest of the description, I would think to myself:
"aha -- the process that contains the Speedware execution environment
has grown tremendously between forks #1 and #2; so much so that by
attempt #2, it cannot be contained twice in memory".  fork() does *not*
actually duplicate much of the process.  However, it sets all of the
process's writable pages to copy-on-write.  This invokes kernel memory
accounting which worries that those pages might *actually* get copied;
thus, fork() will fail if the system couldn't contain two complete
copies of the process.

Unix and Linux Support

So one thing to do is examine the size of the process at both points in
time.  Put sleep(1000) calls in to give yourself time to poke around
(you can prod the process back to life with `kill -ALRM <pid>`).
`ps -o vsz -p <pid>` gives a decent approximation of process size.

> I turned on auditing, which basically told me that the fork(s) was failing
> with EAGAIN (11, no more processes).  Nothing else seemed strange in the
> audit report.

"no more processes" is an archaic translation of EAGAIN.  The current
one is "resource temporarily unavailable".

> Checking the messages(M) man page, it says that EAGAIN is caused by (a) the
> process table being full (but this is dynamically allocated in OSR 5.0.5, and
> I have proven that the table will grow on my client's machine, so it seems
> unlikely that this is the problem); (b) swap is fill (but sar and other swap
> reporting programs tell me that it isn't even being used (512Mb free of
> 512Mb)); (c) EXEC failed due to insufficient number of pages available to
> load executable (but I'm not exec(S)-ing...); or (d) a lock failed on a file
> or record that was already locked (which I suppose is a possibility, but how
> do I find out?     And why wouldn't this be the case on my machine?).

You can get EAGAIN from locking system calls, meaning "you can't lock
that now, someone else has it [resource temporarily unavailable], but
feel free to try again later".  Doesn't apply to fork().

> I have tried uping some of the kernel tunable parameters.  I changed MAXUP (#
> processes per user id) from 100 to 200, and the client machine crashes in
> exactly the same spot.     (I would expect that if this was the problem then I'd
> be able to run the program a few more times before a crash, if it crashed at
> all.)  I changed NOFILES (number of open files per process) from 110 to 220
> to 2500, and again, the program crashed in the exact same spot.  (lsof shows
> a maximum of about 75 files for any given process for the user at any given
> time when running silmultaneously with a test run that causes the crash.)
> 
> I have made sure that the two systems are running the same version of
> Speedware, and that all of Speedware's configuration files are the same.
> 
> I have downloaded my client's database to my machine, and was able to run the
> process without any crashes.  I copied my test database to my client's
> machine, and it crashes every time.  This leads me to believe the problem is
> not data related.
> 
> There are no messages displayed on the system console, or in
> /usr/adm/messages, or /usr/adm/syslog, when this problem arises.
> 
> The client wasn't having this problem initially with the system.  It seemed
> to start after I was on site one Saturday.  Unfortunately, they didn't tell
> me this for several weeks, and my notes are sketchy as to anything out of the
> ordinary that I did. (My memory is out of the question! :->)  I may have
> installed OSS497B that day.  So, I tried to uninstall OSS497B, but that
> didn't help.  (I have since re-installed it.)
> 
> The fork(S) man page didn't seem to shed any light on the subject.
> 
> It was suggested to me that there might be something different in the
> environment, such as PATH and permissions.  But if that were the case,
> wouldn't the first fork fail the first time it was executed?  (I don't
> believe the Speedware program should not be changing the environment while
> it's running.)

Suppose Speedware had an environment variable
EAT_THIS_MUCH_MEMORY_AFTER_FIRST_FORK...  Setting it to 400MB, only on
the client system, would cause the behavior you're seeing.  Ok, not very
likely.  But suppose it has a bug that makes it sensitive to some other
environmental difference, and leads to the same behavior.

Use `lsof` to get a look at the shared objects linked into each process.
Confirm that they're the same on both systems.

> I ran Verify System (thorough), and nothing of note showed up.
> 
> I just ordered SarCheck, so maybe that will help (but I need to wait for it
> to be shipped to me).  I'm going to try using the Skunkware version later
> today...
> 
> If anyone has any suggestions, or needs additional information, or just wants
> to console me (:->), please post.
> 
> The only thing left that I can think of is to re-install the OS, but that may
> take quite a long time.  (I'll probably try an "in place upgrade" first, so I
> don't have to reconfigure everything if it works.  Otherwise, I guess I'll
> try a clean install <UGH!>.)

Reinstalling the OS to fix mysterious problems is a Windows solution.

=============================================================================

As far as I can determine from current OpenServer 5.0.5 source, fork()
can return EAGAIN in the following cases:

  - in various special cases having to do with virtual 8086 processes
    (Merge or VP/ix), which I will not try to enumerate

  * in many ways which print kernel warnings on the console, which I
    will not try to enumerate; the warnings make them obvious; generally
    having to do with lack of memory

  * if creating the process would exceed MAXUP (maximum processes per
    user ID -- run `sysdef | grep MAXUP`)

  * if there is no memory to grow a page table

  * if the kernel is unlicensed and this process would exceed the limit
    for processes on an unlicensed kernel

  - if one of its regions would represent the 61440th simultaneous
    in-core mapping of a file

  - if one of its regions has the "grow down" flag but isn't the stack

  - if the stack region doesn't have the "grow down" flag

  - if one of its regions starts or ends above virtual address BFFFFFFF

  - if one of its regions has end address < start address

  - if two of its regions overlap

I've marked with "*" the cases which seem at all likely.

Make sure you've checked syslog for any kernel warnings (but you already
have).  Check MAXUP against how many processes the test user is running
(`ps -u user`) (but you already have).  Check available memory with
`sar -r 1 1`: on 5.0.5 this displays availrmem and availsmem, which are
really the critical variables.

The only probable candidate is the unlicensed kernel limit.  You can
test this by e.g. running:

  sleep 1000 &

over and over; if you can generate 100 of those, your kernel is properly
licensed.  (You could use the license manager etc., but the question
isn't "does the license manager think we have a valid license", it is
"does the *kernel* think so?".)

All of the region stuff is extremely improbable.  But you could try to
check it anyway, just to be sure.  Change the 4GL program so that the
two things it calls are shell scripts which start by doing a long sleep,
giving you some time to fiddle around in a debugger.  During the sleep,
capture region information for the process.  In `crash`, run "preg #pid"
on both the parent and child (the first time through); and on the parent
only, the 2nd time, since there is no child (fork failed!).  If you want
to get fancy, you can also capture information about the regions
themselves.  The "preg" command shows you which regions the process has
mapped in, e.g.:

  > preg #4084
  SLOT    PREG REG#      REGVA  TYPE FLAGS
    74       0  600  0x8046000 stack rd wr cm
             1  643  0x8048000  text rd ex cm
             2  746  0x8062000  data rd wr cm
             3  611 0x80001000 lbtxt rd ex pr
             4  763 0x80051000 lbdat rd wr ex pr

You can carry the REG# information into the "reg" command:

  > reg 600 643 746 611 763
  REGION TABLE SIZE = 853
  Region-list:

  
  SLOT  PGSZ VALID  SMEM NONE SOFF  REF SWP NSW FORW BACK INOX TYPE FLAGS
   600     2     2     2    0   70    1   0   0  746 ract   -  priv nosh stack
   643    26    17     0    0   72    1   0   0  766  746  763 stxt nosh nosmem
   746   124   103    95    0   98    1   0   0  643  600  763 priv nosh
   611    80    61     0    0    1    1   0   0  730  763   24 map  nosh nosmem
   763    10    10     9    0   81    1   0   0  611    5   24 map  nosh

Then you can crosscheck; e.g. this process's pregion #3 maps region #611
starting at process virtual address 80001000.  We see that region #611
is 80 pages long.  80 * 4K is 0x50000, so the region spans virtual
addresses 80001000-80050FFF.  Pregion #4 starts at 80051000: no overlap,
and the regions butt up against each other, which seems like a probable
arrangement.

Good luck...

>Bela<

Lone-Tar Backup and Disaster Recovery
for Linux and Unix

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Forget the expense of flying to New England. Forget hotel and meals costs.
Installation and light training Boston and New England

/Bofcusm/99.html copyright 1997-2004 Bela Lubkin All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here