dup2() Problems on 2.5.1

dup2() Problems on 2.5.1

Post by Sean Vicker » Fri, 10 Jan 1997 04:00:00



Hi Jim,


in comp.unix.solaris:

Quote:> We have run into an interesting problem under Solaris 2.5.1 using
> the dup2() system call.
>[...]

> new_socket_num = accept(old_socket_num,....)
> read(new_socket_num,...)
> fork(....)
> *** CHILD ***
> close(old_socket_num)
> close(0)
> close(1)
> close(2)
> dup2(new_socket_num,0)
> dup2(new_socket_num,1)
> dup2(new_socket_num,2)
>  ...
> execl(...)
> *** PARENT ***
> close(new_socket_num)

> The FIRST dup2() will fail, with an errno of EBADF (not a valid
> open file descriptor). How is this error message possible since we
> successfully performed a read() from the socket descriptor? We
> have restarted the process as well as rebooted the machine to no avail.

It's a bug.

Most likely the program, being a daemon, has closed standard input, output
and error, file descriptors 0, 1 and 2, early on.  The fd returned by
accept is most likely 0, 1 or 2, which gets closed in your sequence of
three close()s.  It's unnecessary to close a fd before using it as the
target fd in dup2().  So the only thing that remains is to close
new_socket_num, provided it is not 0-2, before the execl(); this is just
to be tidy.

So, the fixed code looks like:

    new_socket_num = accept(old_socket_num, ...)
    read(new_socket_num, ...)
    fork(...)

    *** CHILD ***
    close(old_socket_num)
    dup2(new_socket_num, 0)
    dup2(new_socket_num, 1)
    dup2(new_socket_num, 2)
    if (new_socket_num > 2)
        close(new_socket_num)
    ...
    execl(...)

    *** PARENT ***
    close(new_socket_num)

HTH,
Sean.
--

Systems Programmer   Information Services   Griffith University

 
 
 

dup2() Problems on 2.5.1

Post by Roger A. Faulkn » Fri, 10 Jan 1997 04:00:00



>Are there any tools to output a process' open file descriptors?

On SunOS 5.5 (Solaris 2.5) and later you have:

        /usr/proc/bin/pfiles

Man page:  proc(1)

Roger Faulkner


 
 
 

dup2() Problems on 2.5.1

Post by Ken Lerma » Fri, 10 Jan 1997 04:00:00



...

> new_socket_num = accept(old_socket_num,....)
> read(new_socket_num,...)
> fork(....)
> *** CHILD ***
> close(old_socket_num)
> close(0)
> close(1)
> close(2)

At the risk of sounding stupid, are you sure that the new_socket_num is
NOT 0, 1, or 2?

Quote:> dup2(new_socket_num,0)
> dup2(new_socket_num,1)
> dup2(new_socket_num,2)
>  ...
> execl(...)
> *** PARENT ***
> close(new_socket_num)

---------------------------------------------------------------------
---------------------------------------------------------------------

Ken

 
 
 

1. Problem redirecting input using dup2

Im trying to make a child process get its standard input from a file, but
its still always taking the input from the standard input.

the child process looks like this:

      if(filename!=NULL)
      {
         if(fd=open(filename, O_RDONLY)<0)
         {
            fprintf(stdout, "Error opening %s for reading\n", filename);
            exit(1);
         }
         if(dup2(fd,0)<0)
         {
            fprintf(stderr,"couldnt dup!");
            exit(1);
         }
      }
      if(execlp(command,arguments)!=0)
         printf("Error executing %s\n", user_command);
      exit(1);

and the test program being spawned:

   while (scanf("%s", buf) != EOF)
     printf("scanned: %s\n", buf);

Even adding close(0), close(fd) etc makes no difference.  Could please
someone point out the problem?

Thanks
Rex

2. DEC 2000 AXP with linux

3. problem w/ dup2() and pipes

4. Evolution (1.3.n) with X.509?

5. dup2/close problems

6. Mail accounting system

7. Problem with dup2() System Call

8. konq location bar (KDE3)

9. dup2 and reopeing stdin

10. ANSWER TO: getting stdout back after dup() dup2() and freopen()

11. dup2: bad file descriptor, please help

12. In what way is dup2() not MT-SAFE?

13. A question on dup2 and stdout ...