Why Strace Shows Eagain (Resource Temporarily Unavailable)

Why STRACE shows EAGAIN (Resource temporarily unavailable)

poll woke up with revents = POLLOUT, which means that the socket is ready to write, not ready to read. The code is apparently not checking this flag, and trying to read anyway.

This might be intentional. Even though poll didn't say the socket is ready to read, it might have become ready while it was writing. So it calls ready just in case something has shown up. If not, it will go back into poll to wait again. This allows it to process incoming data more quickly, since it can get it in one call rather than two.

What can cause a “Resource temporarily unavailable” on sock send() command

"Resource temporarily unavailable" is the error message corresponding to EAGAIN, which means that the operation would have blocked but nonblocking operation was requested. For send(), that could be due to any of:

• explicitly marking the file descriptor as nonblocking with fcntl(); or
• passing the MSG_DONTWAIT flag to send(); or
• setting a send timeout with the SO_SNDTIMEO socket option.

Resource temporarily unavailable futex while strace'ing sqoop command

I wrote a short strace cheat sheet that explains how to use strace and about the calls to futex that you may want to look at.

The futex system call is used for implementing synchronization primitives like mutex, semaphores, reader-writer locks, etc. There is nothing wrong with the output you posted above; it indicates that you are likely tracing the main thread of the program which is waiting for a lock to be released.

I would recommend re-running your strace command with -f to trace child processes. Even if your application does not explicitly create additional threads, it is possible that the Java Virtual Machine will create additional threads internally.

Reading socket: EAGAIN: Resource temporarily unavailable

EAGAIN does not mean you're disconnected, it just means "there's nothing to read now; try again later".

You could either unset O_NONBLOCK with fcntl(2) (making read wait until there's something available), or just wait on the socket with something like select(2) before calling read.

EDIT: Now that you've added more code, I can see that you're setting SO_RCVTIMEO for the socket. This can cause a blocking read to return EAGAIN (so if you don't want that to happen, simply leave SO_RCVTIMEO alone).

timer_create() : -1 EAGAIN (Resource temporarily unavailable)

You've guessed correctly, you do have a maximum number of timers:

   The kernel preallocates a "queued real-time signal" for each
   timer created using timer_create().  Consequently, the number
   of timers is limited by the RLIMIT_SIGPENDING resource limit
   (see setrlimit(2)).

The timer_create(3posix) manpage is a bit more blunt about it:

   The timer_create() function shall fail if:

   EAGAIN The system lacks sufficient signal queuing resources
          to honor the request.

   EAGAIN The calling process has already created all of the
          timers it is allowed by this implementation.

While you could raise the setrlimit(2) limit on pending signals (ulimit -i in bash(1)), be aware that this allocates real kernel memory -- which is an extremely limited resource.

I suggest modifying your application to delete or re-use old timers.

Identifying file causing hang from strace

You can find which file uses this file descriptor by calling strace -o log -eopen,read yourprogram. Then search in the log file the call to read of interest. From this line (and not from the first line of the file), search upwards the first occurrence of this file descriptor (returned by a call to open).

For example here, the file descriptor returned by open is 3:

open("/etc/ld.so.cache", O_RDONLY)      = 3

---

Related Topics