Hej Ralph,
I can see one (possible) problem here:
static void req_server (void *pParm)
{
rsrv_iface_config *conf = pParm;
SOCKET IOC_sock;
taskwdInsert ( epicsThreadGetIdSelf (), NULL, NULL );
IOC_sock = conf->tcp;
/* listen and accept new connections */
if ( listen ( IOC_sock, 20 ) < 0 ) {
char sockErrBuf[64];
epicsSocketConvertErrnoToString (
sockErrBuf, sizeof ( sockErrBuf ) );
errlogPrintf ( "CAS: Listen error: %s\n",
sockErrBuf );
epicsSocketDestroy (IOC_sock);
epicsThreadSuspendSelf ();
}
We should be able to print out errno,
to see what is going on and why listen fails.
(could be EAGAIN ??) We need to find out...
On 06/02/20 13:16, Ralph Lange via Core-talk wrote:
Dear Core-talkers,
We have been seeing an IOC lately that occasionally seems to boot fine,
does not print the usual "cas warning: Configured TCP port was
unavailable. [...]" messages for not being the first one on the host,
but then emits a
CAS: Listen error: Address already in use
Thread CAS-TCP (0x3337a20) suspended
and becomes CA unresponsive.
We recently changed our IOC startup to be systemd controlled and are
starting all IOCs in parallel.
Question: Is there a vulnerability for a race condition where two IOCs
are under the impression of being able to use the original CA port, but
one of them eventually fails to listen()?
Cheers,
~Ralph
- Replies:
- Re: Weird CAS hangup on IOC Ralph Lange via Core-talk
- References:
- Weird CAS hangup on IOC Ralph Lange via Core-talk
- Navigate by Date:
- Prev:
Weird CAS hangup on IOC Ralph Lange via Core-talk
- Next:
Re: Weird CAS hangup on IOC Ralph Lange via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Weird CAS hangup on IOC Ralph Lange via Core-talk
- Next:
Re: Weird CAS hangup on IOC Ralph Lange via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|