epics-modules / iocstats Goto Github PK

We are seeing somewhat unusual outputs from this PV, in that it seems to be showing the latest file loaded with iocshLoad, not the actual startup script.

With EPICS 7.0.3.1[1] (I don't know when TZ was introduced.), TIMEZONE was renamed to TZ. So the iocAdminSoft substitutions [2] file should be updated according to them if one would like to use iocStats vanilla substitutions. The additional changes may be necessary in [3-8].

[1] https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/src/env/envDefs.h#L66
[2] https://github.com/epics-modules/iocStats/blob/master/iocAdmin/Db/iocAdminSoft.substitutions#L30
[3] https://github.com/epics-modules/iocStats/blob/master/iocAdmin/Db/iocAdminRTEMS.substitutions#L40
[4] https://github.com/epics-modules/iocStats/blob/master/iocAdmin/Db/iocAdminVxWorks.substitutions#L40
[5] https://github.com/epics-modules/iocStats/blob/master/op/ui/autoconvert/ioc_stats_epics_env.ui#L485
[6] op/adl/ioc_stats_epics_env.adl
[7] op/opi/ioc_stats_epics_env.opi
[8] iocAdmin/srcDisplay/ioc_stats_epics_env.edl

Several of the records in ioc.template have somewhat confusing units, see https://github.com/epics-modules/iocStats/blob/master/iocAdmin/Db/ioc.template#L213 for example:

record(ao, "$(IOCNAME):CA_UPD_TIME") {
    field(DESC, "CA Check Update Period")
    field(DTYP, "IOC stats")
    field(OUT,  "@ca_scan_rate")
    field(EGU,  "sec")
    field(DRVH, "60")
    field(DRVL, "1")
    field(HOPR, "60")
    field(VAL,  "15")
    field(PINI, "YES")
}

Note that the description is a period with units that are in seconds, but the source of the data is @ca_scan_rate (from https://github.com/epics-modules/iocStats/blob/master/devIocStats/devIocStatsAnalog.c#L238). A rate is usually in inverse seconds, so the name of that should probably be change (as it is clear that seconds is the correct unit)

As noted in this thread: https://epics.anl.gov/tech-talk/2022/msg01942.php some of the parts of the devIocStats documentation are out of date, for example the README says that one should use "cpuScanRate" while the actual code requires "cpu_scan_rate".

Is there any plan for release version of this module?

Running a cross-build of the windows-x64-mingw target on RHEL-7 against Base-3.14.12.6 I get the following build failure:

/usr/bin/x86_64-w64-mingw32-gcc -c              -D_MINGW     -O3   -Wall      -m64    -D_DLL   -MMD -I. -I../O.Common -I. -I../os/WIN32 -I../os/default -I.. -I../../include/os/WIN32 -I../../include    -I/home/phoebus/ANJ/epics/modules/soft/sncseq/include -I/home/phoebus/ANJ/epics/base/3-14-dev/include/os/WIN32 -I/home/phoebus/ANJ/epics/base/3-14-dev/include        ../os/WIN32/osdCpuUtilization.c 
../os/WIN32/osdCpuUtilization.c:38:0: warning: ignoring #pragma comment  [-Wunknown-pragmas]
 #pragma comment (lib, "Advapi32.lib")
 ^
../os/WIN32/osdCpuUtilization.c: In function 'devIocStatsInitCpuUtilization':
../os/WIN32/osdCpuUtilization.c:121:5: warning: implicit declaration of function 'GetMaximumProcessorCount' [-Wimplicit-function-declaration]
     pval->noOfCpus = GetMaximumProcessorCount(ALL_PROCESSOR_GROUPS);
     ^
../os/WIN32/osdCpuUtilization.c:121:47: error: 'ALL_PROCESSOR_GROUPS' undeclared (first use in this function)
     pval->noOfCpus = GetMaximumProcessorCount(ALL_PROCESSOR_GROUPS);
                                               ^
../os/WIN32/osdCpuUtilization.c:121:47: note: each undeclared identifier is reported only once for each function it appears in
/home/phoebus/ANJ/epics/base/3-14-dev/configure/RULES_BUILD:211: recipe for target 'osdCpuUtilization.o' failed
make[2]: *** [osdCpuUtilization.o] Error 1

Is it possible to remove : in template files ? For example

• from

record(mbbo, "$(IOCNAME):ACCESS")

• to

record(mbbo, "$(IOCNAME)ACCESS")

Without it, users have more freedom to select PV name according to site-specific naming convention.

Some time ago (over a year!), J. Lewis Muir requested an option be added to the iocStats databases to prevent records that perform invasive actions (like reboot or load a new access security file) from being loaded. There are several ways to implement this but one way that seemed the least amount of work and the least changes to existing startup files is one recommended by Lewis - add a new macro that would be used like this:

$(RO_$(RO=NO),RO_YES=#,RO_NO=)record(sub, "$(IOC,undefined):SYSRESET")
$(RO_$(RO=NO),RO_YES=#,RO_NO=){
$(RO_$(RO=NO),RO_YES=#,RO_NO=)    alias("$(IOC,undefined):SysReset")
$(RO_$(RO=NO),RO_YES=#,RO_NO=)    field(DESC, "IOC Restart" )
$(RO_$(RO=NO),RO_YES=#,RO_NO=)    field(SNAM, "rebootProc")
$(RO_$(RO=NO),RO_YES=#,RO_NO=)    field(BRSV,"INVALID")
$(RO_$(RO=NO),RO_YES=#,RO_NO=)    field(L,"1")
$(RO_$(RO=NO),RO_YES=#,RO_NO=)}
==============

And set RO (Read Only) to YES to remove the record instance:

=== st.cmd ===
dbLoadRecords("$(DEVIOCSTATS)/db/iocAdminVxWorks.db","IOC=17lab,RO=YES")
==============

Or invert the sense of the macro to RW (Read Write), and I can set it to
NO.

(ANJ edited to format suggested changes better)

There are quite a few CA related records and functionalities, but none for PVA. This shoudl be fixed.

Hi,

I have added the networks statistics, not connected CA links, not connected PVs in the seq program to the latest version of the
iocStats which is currently in my private repository (https://github.com/mirek23/iocStats.git).

My intention would be to share these code with others in the community so could you please merge it with the epics_modules/iocStats
or grant me a permission as such that I could do it myself.

Best Regards
Mirek

Using master branch fa12cb2

commit fa12cb2172e3477debd1372f57e68d2ae21f7c1b (HEAD -> master, origin/master, origin/HEAD)
Merge: e320eb5 48a3f0f
Author: Simon Rose <[email protected]>
Date:   Tue May 30 09:23:10 2023 +0200
    Merge pull request #52 from epics-modules/add_vx_works    
    Add iocAdminVxWorks.db rule

In my ioc startup, I am pulling ADCore
commonPlugins.cmd:dbLoadRecords("$(DEVIOCSTATS)/db/iocAdminSoft.db", "IOC=$(PREFIX)")

recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::TIMEZONE
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVA_ADDR_LIST
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVA_AUTO_ADDR
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVA_BEACON_PERIOD
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVA_BROADCAST_PORT
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVA_CONN_TMO
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVA_DEBUG
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVA_SERVER_PORT
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVAS_AUTO_BEACON_ADDR_LIST
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVAS_BEACON_ADDR_LIST
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVAS_BEACON_PERIOD
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVAS_BROADCAST_PORT
recGblRecordError: devStringinEpics (init_record) INP field is not an EPICS env var Illegal field value PV: TPX3-TEST::PVAS_SERVER_PORT

The PV: TPX3-TEST::TIMEZONE, solution is discussed by Mark Rivers in
https://epics.anl.gov/tech-talk/2023/msg00802.php

I am not sure how to fix the other issues.

The SLAC documentation page that the README points to states that Stephanie Allison is the developer and maintainer of the module, however she is retired and no longer maintaining it.

Is there a current lead maintainer that the documentation can be pointed to?

iocStats is unaware of the new EPICS_BASE. files in the synApps configure directory that allow one to build for Windows and Linux using the same source tree:

  https://github.com/EPICS-synApps/configure

I would like to improve the formatting of the medm files in iocStats. To do that I would like to look at the edm files as an example of how they should look. However, I can't find any edm files in iocStats/op. Are they somewhere else?

The free memory returned is not correct on linux. Problem: file system cache and buffers are counted as "free", but the system might not be able to free them on demand. Example: Any file residing in /dev/shm is counted as free memory.

reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

In osdMemUsage.c, summing of of items shoudl be replaced by the value of MemAvailable

When user includes an iocStats .dbd file more than once in an EPICS app, software incorrectly performs another initialization. Software must be changed to perform initialization just once.

Add a chime function to iocStats which logs a timestamp to the IOC's screenlog at a configurable interval.

The *Main.cpp programs in the test directories are based on very old templates that lack the call to epicsExit(0) after the iocsh(NULL) returns. This prevents epicsAtExit() from working on some platforms, e.g. Windows.

Loading this record in EPICS 7.0.6:

record(stringin, "ST99:Mot:IOC_STSim:TIMEZONE") {
field(DESC, "EPICS_TIMEZONE")
field(DTYP, "IOC epics var")
field(INP, "@EPICS_TIMEZONE")
field(PINI, "YES")
}

results in this error:

Illegal field value PV: ST99:Mot:IOC_STSim:TIMEZONE devStringinEnvVar (init_record) Illegal INP parm field

The above record is what's defined as a result of using iocAdminSoft.db, because that's built with iocEnvVar.template using these macros:

file iocEnvVar.template
{
pattern { IOCNAME, ENVNAME , ENVVAR , ENVTYPE}
{ "$(IOC)" , TIMEZONE , EPICS_TIMEZONE , epics }
}

However, EPICS_TIMEZONE has been replaced with EPICS_TZ in 3.15.7.

So ideally we update iocStats to use EPICS_TZ instead of EPICS_TIMEZONE, but then it only works on 3.15.7 and above.

This isn't actually a big problem because anyone can use iocEnvVar.template directly themselves and use the correct name for whichever EPICS base version they are using, but perhaps we need a comment or something in iocStats iocAdminSoft.substitutions to highlight the issue?

Switching to EPICS_TZ in base 7.0.6 works fine. This record:

record(stringin, "ST99:Mot:IOC_STSim:TIMEZONE") {
field(DESC, "EPICS_TIMEZONE")
field(DTYP, "IOC epics var")
field(INP, "@EPICS_TZ")
field(PINI, "YES")
}

results in:

caget ST99:Mot:IOC_STSim:TIMEZONE
ST99:Mot:IOC_STSim:TIMEZONE CST6CDT,M3.2.0/2,M11.1.0/2

We currently keep three records to keep track of the startup script location and the aplication directory, which split the full path into parts (and not necessarily enough for that even...).

Do we need to keep these old record types?

Originally reported as https://bugs.launchpad.net/epics-base/+bug/1694966

It isn't safe to call casStatsFetch() until RSRV has initialized successfully. If iocInit fails between the point where the timer which calls casStatsFetch() is started (device support init() ), and rsrv_init(), then the IOC process will crash when casStatsFetch() is called from the timer thread.

At a minimum, iocStats should not start this timer until after RSRV has started, if not later. I'd suggest an initHook with initHookAfterCaServerRunning or initHookAfterIocRunning.

An EPICS module's configure/RELEASE file gets interpreted both by GNUmake and by the convertRelease.pl script in Base, but the latter completely ignores the ifeq and endif lines that currently appear in this file in iocStats (the assignments between those two lines will always be interpreted by the Perl code). That may not matter in this particular case, but someone who doesn't understand the intricacies might see it here and try to do something more complex in their RELEASE files, which could cause head-scratching, wailing and/or gnashing of teeth. I am therefor requesting that this conditional be removed from here lest it set a bad example.

There is a typo (a comment is closed twice) in devIocStats/os/Darwin/devIocStatsOSD.h that breaks builds on OS X:

 *  2016-02-25  Jeong Han Lee (ESS)
 *     Replaced _SC_NPROCESSORS_CONF with _SC_NPROCESSORS_ONLN
 */
 */