Cannot run program in background?

Howdy all!
I have an application that creates and interacts with sockets and some low-level devices. I currently pass it a config file so it knows what kind of environment it runs in. What I would like to do is run one instance of this application for each device all at the same time, something like:
# program configfile1 &
# program configfile2 &
etc., so they're all running at the same time.

However whenever I do that, none of the sockets are created and it seems the program does nothing. There's no user interaction here, although it speaks to the serial port. If I wait and hit enter at the prompt, I get:

Stopped [45] program

where 45 is its pid.

I think I can do something like this in the main(...) of my application:

Code:

---

  if ((pid = vfork()) < 0)
  {
      perror("Error in vfork()");
      return;
  } //end if vfork error

  //child
  else if (pid == 0)
  {
      //we are the child
      sigignore(SIGINT);                                //ignore keyboard interrupts
      close(STDIN_FILENO);                                //close stdin
      printf("[%d]  %ld\n", numOfBackgrounds, getpid());  //print ACK


    .... put all the rest of my code here........



      } //end if

    }
  else //parent
  {
  if (!background)
        waitpid(pid, NULL, 0);  //wait for child since we're foreground
  }

---

and this will do what I want.

However I am still curious as to why a non-user-interactive program won't create sockets when executed in the background?
This is on RH 8.0 using the bash shell.

Thanks. :)
Curious.

Yes, I read the FAQ, but it didn't answer my question. On my system 'man setsid' yields the description 'run a program in a new session' and that's it, no further explanation. I was asking why '&' doesn't work as expected and thought someone here might have some insight. Thanks.

Well, first off I have no doubt I'm doing something wrong, I'm new to both sockets programming and serial device programming under Linux.

My application creates 3 sockets and controls a serial device through a serial port. However I found that under Linux (maybe all Unixes?) I have to "reset" the stdin/stdout terminal settings just to get things to function properly. I don't know why this must be done, maybe I'm doing it incorrectly, but this is what I'm doing when I open my serial device:

Code:

---

/* set my serial port settings above (raw mode).....*/

tcgetattr(1,&port->ser_old_stdout_tio);        // we gotta do this - there is a Linux bug
tcsetattr(1,TCSANOW,&port->ser_newtio); // make stdout settings like modem settings
tcgetattr(0,&port->ser_oldstdtio); // get stdin settings for restoration ...
tcgetattr(0,&port->ser_newstdtio); // ... and use them as a basis for changes
tcsetattr(0,TCSANOW,&port->ser_newstdtio); // set the new attributes immediately

---

Now, in the foreground everything works fine, at least so far as I can tell, my app's been running for 96 hours nonstop without a hitch, doing everything it's supposed to.

When I try the suggested code in the FAQ, the terminal settings get reset to the serial port settings and remain that way. Thus, if I execute,
# program
my terminal settings are all messed-up (correct for the serial device I'm controlling, but ugly for the user). Typing 'reset' fixes it, but that's not very nice.

I thought by running my child in its own session it would be terminalless(?), so I removed the above bit of code when opening my serial port. However then (just as if it were running in the fg), my serial device doesn't work any longer.

The mystery to me is the very first thing I ever do
in my code is fork off my child. It's behaving as if the child is controlling the same terminal as its parent was, which (I think) would explain everything I'm seeing. I could understand this if setsid failed, but it doesn't (never executes the code under "if setsid returned -1...").

On page 245 of "Advanced Programming in the UNIX Environment" it states:
3. The process [that called setsid] has no controlling terminal....If the process had a controlling terminal before calling setsid, that association is broken.

So I'm a little confused as to why my child seems to be controlling its parent's terminal. :( I could understand if the serial settings were executed by the parent before it died, so it died before resetting the port settings, but they're not, my parent returns(1) before it ever gets a chance to mess with the serial port settings.

Since the only way I can get serial ports to work under Linux is to reset stdin/stdout, does this mean I can never run my application in the background without putting-up with those raw shell terminal settings?

Thanks as always for any help.

Apparently I needed to create two children. There seems to be some possibility that the child WILL inherit a controlling terminal even if you call setsid(), so by creating a second child and letting the first die, seems to remove this possibility. Also, I can force all the inherited stream associations to disassociate from my second child by simply closing stdin, stdout and stderr.