1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Shutting down channel access clients |
From: | Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov> |
To: | tech-talk at aps.anl.gov |
Date: | Thu, 18 May 2023 10:29:52 -0500 |
(forgot to CC tech-talk). Hi Marco,
I can think of 3 methods, depending on exactly what you're looking to do: 1. You can temporarily stop CA puts to an individual record by setting its DISP field to a non-zero value, DISP = Disable Put. When DISP is non-zero the server will only accept puts to the DISP field (so you can set it remotely and still re-enable puts again). This requires no preparation, but is per-record; the user may get an indication that puts are disabled when they try to modify a record field, internally this raises a S_db_putDisabled error which should get forwarded to the client but it might ignore. 2. You can temporarily stop CA writes to a group or records (or to all records) on a live IOC by loading an Access Security Configuration File that disables writes to that group (membership of which is controlled by the ASG field). The security rule can be controlled by a value obtained through CA, so you can easily turn write access off and on. If you're not used to access security this may involve some learning and experimentation to get working though; it requires a fair bit of preparation, but the user does get an indication from CA that they aren't permitted to write to the record fields when writes are disabled. 3. If you're able to reboot the IOC, you can set the environment variable EPICS_IOC_IGNORE_SERVERS to "rsrv" any time before iocInit or in the environment where the IOC is run, which will prevent the IOC's CA server from being started at all. This requires no preparation, applies to the whole IOC, and needs a reboot to enable/disable it; users won't know that the IOC is running at all when the server is being ignored. Of course the same rules will apply to any other IOCs that link to the one you're working on. Using access security though you can set a different set of rules for the user and/or host that those IOCs are running as/on. HTH, - Andrew On 5/18/23 9:50 AM, Marco A. Barra
Montevechi Filho via Tech-talk wrote:
-- Complexity is free, it's Simplicity that takes work. |