Looping and executing ls in a bash script, Resource Temporarily Unavilable?

Question

I have a process that takes hours at a time sometimes to complete, and instead of running ls to see if an associated file gets deleted to mark the completion of the task, I have a script that simply runs ls foldernames over and over with a 5 second sleep in between.

It works for its purpose (don't ask why I don't have a better notification system this was just an adhoc temporary solution). However, if the script runs for a long period of time (an hour?), instead of outputing the directory contents, it displays the following error:

./loop.sh: fork: retry: Resource temporarily unavailable
./loop.sh: fork: retry: Resource temporarily unavailable
./loop.sh: fork: retry: Resource temporarily unavailable

Why does this happen? Did the script have any negative consequences on the server?

Thanks!

Answer 1

fork() is the system call that creates a new process¹.  Whenever you run a command, you create a process.  When you run a pipeline like date | od -ab, you create two processes.  But normally you don’t get your shell prompt back (or, as applicable, go on to the next line in a script) until the process(es) you created have terminated and disappeared.

However, when you run a command in the background (e.g., with command &), you can go on to do other things without waiting for the process(es) you created to terminate.  This can be a very powerful capability, but it makes it easy to create a lot of processes.  And there are limits beyond which you’ll get “Resource temporarily unavailable”.

Are you sure that your monitoring script is causing the problem (or is it just suffering from the symptoms)?  What is this “process [that you have] that takes hours at a time sometimes to complete”?  Could it be causing the problem?  Is it a compiled binary executable, or is it also a script?  If it’s a binary, do you have the source code?

Here are some things you can try to isolate the issue:

• Start the “hours at a time” process.  Wait an hour (use an alarm clock, or an hourglass, if that helps) and then start the monitoring script.  Does it fail very soon?  If so, the problem is probably in the “hours at a time” process.  Does it run for an hour (this would be the second hour of execution of the “hours at a time” process) and then fail?  If so, the problem is probably in the monitoring script.
• Change the sleep from 5 to 30.  Does it still fail after one hour?  If so, the problem is probably in the “hours at a time” process.  Does it manage to last six hours?  If so, the problem is probably in the monitoring script.
• Look at your script and see if any commands have &.  Are there any wait commands?  If the “hours at a time” process is a script, do the same for it.  If it’s a compiled program, and you have the source, look through it for calls to fork(), vfork(), spawn() and system() (and wait()), and see if you can figure out what’s happening.
• As a last resort, edit your question to include all the relevant details (including the results of the above tests), and then maybe somebody can give you a specific answer.

To answer your last question: yes, running out of any resource is bad for the system.
________
¹ Or, at least, fork() is one of the system calls that create new processes.

---

P.S. Your question title suggests that you suspect that ls is responsible, but the error messages don’t say so.  The error could just as likely be coming from the sleep — or, to be more accurate, the error messages are probably alternating: one from ls, one from sleep, one from ls, one from sleep, etc.