fd after crash

it appears that when our program crashes and is restarted, the fd’s
returned from a socket are not starting back over at 1. It continues to
grow and is going past FD_SETSIZE. I would have expected the new process
to start with a new pool of fd’s.

Joseph Witherspoon <jspoon@us.ibm.com> wrote:

it appears that when our program crashes and is restarted, the fd’s
returned from a socket are not starting back over at 1. It continues to
grow and is going past FD_SETSIZE. I would have expected the new process
to start with a new pool of fd’s.

Actually, fds start being numbered at 0, and the renumbering does restart
each time a program is created.

So, how is this program started? Is it inheriting more fds each time,
because a parent is holding those fds open, and passing them to the
child?

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

Joseph,

You are using HAM to restart??

Bill

“Joseph Witherspoon” <jspoon@us.ibm.com> wrote in message
news:d31563$rd4$1@inn.qnx.com

it appears that when our program crashes and is restarted, the fd’s
returned from a socket are not starting back over at 1. It continues to
grow and is going past FD_SETSIZE. I would have expected the new process
to start with a new pool of fd’s.

I guess not since I do not know what HAM is… We have a script that
invokes the daemon in the background with “&”. And since we cannot have
multiple instances, the first check made is to look and see if more than
one process is running with our name and exit if there is. So, I do not
see how anything can still be running from the previous invocation that
crashed.

William Halchin wrote:

Joseph,

You are using HAM to restart??

Bill

“Joseph Witherspoon” <> jspoon@us.ibm.com> > wrote in message
news:d31563$rd4$> 1@inn.qnx.com> …
it appears that when our program crashes and is restarted, the fd’s
returned from a socket are not starting back over at 1. It continues to
grow and is going past FD_SETSIZE. I would have expected the new process
to start with a new pool of fd’s.

QNX’s High Availability Manager that provides HA. The reason I asked is I
wasn’t sure if some state information is persistent across restarts by HAM
but David Gibbs cleared that up.

Bill

“Joseph Witherspoon” <jspoon@us.ibm.com> wrote in message
news:d31d8r$44b$1@inn.qnx.com

I guess not since I do not know what HAM is… We have a script that
invokes the daemon in the background with “&”. And since we cannot have
multiple instances, the first check made is to look and see if more than
one process is running with our name and exit if there is. So, I do not
see how anything can still be running from the previous invocation that
crashed.

William Halchin wrote:

Joseph,

You are using HAM to restart??

Bill

“Joseph Witherspoon” <> jspoon@us.ibm.com> > wrote in message
news:d31563$rd4$> 1@inn.qnx.com> …
it appears that when our program crashes and is restarted, the fd’s
returned from a socket are not starting back over at 1. It continues
to
grow and is going past FD_SETSIZE. I would have expected the new
process
to start with a new pool of fd’s.




\

Joseph Witherspoon <jspoon@us.ibm.com> wrote:

I guess not since I do not know what HAM is… We have a script that
invokes the daemon in the background with “&”. And since we cannot have
multiple instances, the first check made is to look and see if more than
one process is running with our name and exit if there is. So, I do not
see how anything can still be running from the previous invocation that
crashed.

Try using either “sin fd” from the command line, or the IDE’s
Connection Information view to look at what fds it has open, and
where they are open to. This may give some idea of where you are
getting extra fds.

The OS will give you any and all fds you inherit from your parent,
and then start creating new ones from there. If you’re running
into high numbers, you’re either creating fds you don’t realize,
or you’re inheriting ones you don’t expect to inherit.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

Joseph Witherspoon wrote:

I guess not since I do not know what HAM is… We have a script that
invokes the daemon in the background with “&”. And since we cannot have
multiple instances, the first check made is to look and see if more than
one process is running with our name and exit if there is. So, I do not
see how anything can still be running from the previous invocation that
crashed.

William Halchin wrote:

Is your script opening some connection to the process you’re
starting? Your script may be accumulating opens.

Are your dead processes going into “zombie” state, rather than
being flushed out of the system?

If you’re launching processes across the network, there are
some known problems with zombies. Dead processes become children
of io-net, which doesn’t reap its zombies properly.

John Nagle