Re: github ci problem: CAS: forcing disconnect from 127.0.0.1:57020

[Torsten Bögershausen via Core-talk <core-talk at aps.anl.gov>]

Thanks for the fast answers.

After updating EPICS base I can reproduce the problem here.
It seems to be a caput to a stringout record, which kills the business.

/Torsten



On 2026-08-26 14:21, Ralph Lange wrote:
> Might be https://urldefense.us/v3/__https://github.com/epics-base/epics-base/issues/943__;!!G_uCfscf7eWS!dLQFzvsQDIpGuaC4kgl1vzoa9-2YJtg5xlFSM6s7IEHel6A8Jrfy8mylRb0C6_1h6JRvf_nECHW_lEdXOhU$  <https:// 
> github.com/epics-base/epics-base/issues/943>
> On Wed, 26 Aug 2026 at 14:17, Simon Rose via Core-talk <core- 
> talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>> wrote:
>     Hi Torsten -
>
>     Yes, I think I see the same thing. We actually saw it last week
>     during the training at ESS but blamed it on network issues.
>
>     This can  be replicated on the 7.0 branch of epics-base quite
>     easily: start an IOC and try (for example) to use caput to write to
>     any record. In the IOC shell I see
>
>     CAS: forcing disconnect from 172.18.22.141:59117
>     <https://urldefense.us/v3/__http://172.18.22.141:59117__;!!G_uCfscf7eWS!dLQFzvsQDIpGuaC4kgl1vzoa9-2YJtg5xlFSM6s7IEHel6A8Jrfy8mylRb0C6_1h6JRvf_nECHW_cuaEaUU$ >
>
>     And from the terminal trying to write to the IOC with caput I see
>
>     $ ./caput record_name 1
>     Old : record_name                    0
>     CA.Client.Exception...............................................
>          Warning: "Virtual circuit disconnect"
>          Context: "172.18.22.141:5064 <https://urldefense.us/v3/__http://172.18.22.141:5064__;!!G_uCfscf7eWS!dLQFzvsQDIpGuaC4kgl1vzoa9-2YJtg5xlFSM6s7IEHel6A8Jrfy8mylRb0C6_1h6JRvf_nECHW_4o7KAOY$ >"
>          Source File: ../cac.cpp line 1241
>          Current Time: Wed Aug 26 2026 14:15:06.470965000
>     ..................................................................
>     CA.Client.Exception...............................................
>          Warning: "Virtual circuit disconnect"
>          Context: "op=0, channel=record_name, type=DBR_TIME_DOUBLE,
>     count=1, ctx="172.18.22.141:5064 <https://urldefense.us/v3/__http://172.18.22.141:5064__;!!G_uCfscf7eWS!dLQFzvsQDIpGuaC4kgl1vzoa9-2YJtg5xlFSM6s7IEHel6A8Jrfy8mylRb0C6_1h6JRvf_nECHW_4o7KAOY$ >""
>          Source File: ../getCopy.cpp line 91
>          Current Time: Wed Aug 26 2026 14:15:06.471381000
>     ..................................................................
>     CA.Client.Exception...............................................
>          Warning: "Identical process variable names on multiple servers"
>          Context: "Channel: "record_name", Connecting to:
>     172.18.22.141:5064 <https://urldefense.us/v3/__http://172.18.22.141:5064__;!!G_uCfscf7eWS!dLQFzvsQDIpGuaC4kgl1vzoa9-2YJtg5xlFSM6s7IEHel6A8Jrfy8mylRb0C6_1h6JRvf_nECHW_4o7KAOY$ >, Ignored:
>     192.168.205.1:5064 <https://urldefense.us/v3/__http://192.168.205.1:5064__;!!G_uCfscf7eWS!dLQFzvsQDIpGuaC4kgl1vzoa9-2YJtg5xlFSM6s7IEHel6A8Jrfy8mylRb0C6_1h6JRvf_nECHW_yS1ncxg$ >"
>          Source File: ../cac.cpp line 1324
>          Current Time: Wed Aug 26 2026 14:15:06.475347000
>     ..................................................................
>     Read operation timed out: PV data was not read.
>     New : record_name
>
>     Something is wrong here...
>
>     Cheers,
>     Simon
>
>     *From: *Core-talk <core-talk-bounces at aps.anl.gov <mailto:core-talk-
>     bounces at aps.anl.gov>> on behalf of Torsten Bögershausen via Core-
>     talk <core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>>
>     *Date: *Wednesday, 26 August 2026 at 13:59
>     *To: *core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov> <core-
>     talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>>
>     *Subject: *github ci problem: CAS: forcing disconnect from
>     127.0.0.1:57020 <https://urldefense.us/v3/__http://127.0.0.1:57020__;!!G_uCfscf7eWS!dLQFzvsQDIpGuaC4kgl1vzoa9-2YJtg5xlFSM6s7IEHel6A8Jrfy8mylRb0C6_1h6JRvf_nECHW_z7-VXaQ$ >
>
>
>     Hej EPICS-experts,
>
>     since some time (July 10 2026 or 2026-07-10) we have a failure
>     on one of our github runners.
>
>     If someone wants to look, here is a good run:
>     <https://urldefense.us/v3/__https://github.com/
>     EuropeanSpallationSource/m-epics-ethercatmc/actions/
>     runs/29092838578__;!!G_uCfscf7eWS!
>     Zp_A98G8tvAmH3xmEtRxKFl_0Ydm7Wz0MSRmQ1ZrULhuV4JUEssosb0rF6Cv3MthfRkOlH0LmK79aHPdMb8$ <https://urldefense.us/v3/__https://github.com/EuropeanSpallationSource/m-epics-ethercatmc/actions/runs/29092838578__;!!G_uCfscf7eWS!Zp_A98G8tvAmH3xmEtRxKFl_0Ydm7Wz0MSRmQ1ZrULhuV4JUEssosb0rF6Cv3MthfRkOlH0LmK79aHPdMb8$> >
>
>     One of the failing runs is here:
>     <https://urldefense.us/v3/__https://github.com/
>     EuropeanSpallationSource/m-epics-ethercatmc/actions/
>     runs/32959143825/job/98147389788__;!!G_uCfscf7eWS!
>     Zp_A98G8tvAmH3xmEtRxKFl_0Ydm7Wz0MSRmQ1ZrULhuV4JUEssosb0rF6Cv3MthfRkOlH0LmK79fn7GMoM$ <https://urldefense.us/v3/__https://github.com/EuropeanSpallationSource/m-epics-ethercatmc/actions/runs/32959143825/job/98147389788__;!!G_uCfscf7eWS!Zp_A98G8tvAmH3xmEtRxKFl_0Ydm7Wz0MSRmQ1ZrULhuV4JUEssosb0rF6Cv3MthfRkOlH0LmK79fn7GMoM$> >
>
>
>     Of course the tests run fine here on a local machine
>     (with probably sighly different versions)
>
>     So digging into the log file shows one problem:
>
>     Wed Aug 26 11:21:03 UTC 2026
>     + ./runTests.sh ca://IOC:m1 100_Record-HOMF.py
>     CAS: forcing disconnect from 127.0.0.1:48202 <https://urldefense.us/v3/__http://127.0.0.1:48202__;!!G_uCfscf7eWS!dLQFzvsQDIpGuaC4kgl1vzoa9-2YJtg5xlFSM6s7IEHel6A8Jrfy8mylRb0C6_1h6JRvf_nECHW_O0ABl6Q$ >
>     #... and later, PYT stands for the output of pytest:
>     PYT:2026-08-26 11:21:04 AxisCom get ca://IOC:m1.VAL ret=100.11
>     PYT:2026-08-26 11:21:04 AxisCom get ca://IOC:m1.DMOV
>     PYT:cannot connect to IOC:m1.DMOV
>     PYT:2026-08-26 11:21:09 AxisCom get ca://IOC:m1.DMOV ret=None
>
>     Before I try to set up a system with the hopefully exact versions as
>     on github:
>     Does a bell ring for anybody here ?
>     The commits in EPICS base show that some additional checks had been
>     introduced when processing channel access messages in rsrv
>     However, we are using pyepics inside the test cases, which uses
>     the libca from base, so things should work.
>     (And yes, Timo, we are using mostly pvacess for 99% of the tests)
>
>     Any ideas are welcome
>     Best Regards
>     /Torsten