Reports 1-1 of 1 Clear search Modify search
DGS (General)
takahiro.yamamoto - 21:42 Friday 06 March 2026 (36519) Print this report
Migrating scripts from k1script1 to k1script0.
In klog#36430, the new script server with the latest OS was prepared as k1script0.
So I started to migrate scripts on k1script1 running as the old OS to k1script0.

Today, EPICS DAQ systems (CC-10, GM-10 and Cryocon) were moved to k1script0.
They works fine without any code modification.

There were still more than 20 processes on k1script1.
So they will also be moved one-by-one.
Comments to this report:
takahiro.yamamoto - 17:37 Wednesday 01 April 2026 (36689) Print this report
All remaining cron-scripts were moved to k1script0.

Note
Though operation test of following scripts on k1script0 were done, following scripts are currently commented out because these scripts hang up due to run-time errors that are caused by unreachable servers to get information.
  1. /opt/rtcds/userapps/release/pem/common/scripts/weewx_sync.sh for Atotsu
  2. /opt/rtcds/userapps/release/pem/k1/scripts/snow/K1PEM_SNOW_DAQ.py
1. is related to klog#36587. This script is working well for Mozumi Weather Station, so after recovering Atotsu Weather Station server will be restored. I couldn't find the current situation about 2. Anyway, RaspberryPi for Mozumi snow monitor is now unreachable via Ethernet and Atotsu snow monitor seems to be unreachable from RaspberryPi via Serial. These situation makes a runtime error of this script due to incomplete data files.

/kagra/bin/SYS/weather.py had also made run-time errors due to the issue of Atotsu Weather Station (klog#36587). Because of a lack of error handling, a process for Mozumi Weather Station had also hung up since last February though Mozumi Weather Station itself is alive. So I added an error handling code to that script to operate in normal for alive Weather Station even if a part of Weather Station is down.

Remaining task
Some Supervisor-scripts including EPICS IOCs still remain on k1script1. They will be moved on the next maintenance day.
takahiro.yamamoto - 2:42 Tuesday 07 April 2026 (36706) Print this report
All EPICS IOCs were also moved to k1script0.
Now all resident scripts and services were migrated.
I will start to migrate on-demand scripts tomorrow.

IOCs built as standard ones
cam_ioc, das0_ioc, and weather_ioc running on k1script1 as Debian10 system had been built as a standard IOC under the EPICS-3.14.5 environment without any special configuration. Linked shared objects by these applications didn't depends on detailed library versions and they was able to be launched on k1script0 as Debian13 only with LD_LIBRARY_PATH for EPICS-3.14.5. It's a troublesome to be required LD_LIBRARY_PATH to launch them every time. So I rewrote RUNPATH injected in the ELF binary files by
> patchelf --set-rpath /kagra/apps/epics-3.14.12.3_long-deb13/base-3.14.12.3/lib/linux-x86_64 /path/to/AppName
They can be now launched without LD_LIBRARY_PATH and ELF binaries for Debian10 is archived as target/AppDir/bin/linux-x86_64/AppName-deb10.

IOCs built including special dbd definition with support module
cryocon_ioc, sys_ioc, and vac_ioc had been built with a special dbd definition with support module under the EPICS-3.14.5 environment. Because support module depends on shared object that version is not available on Debina13 system. So rewriting RUNPATH doesn't work well for this case. But these IOC didn't use a function of special dbd at all. So I rebuilt them as a starndar IOC under the EPICS-3.14.5 environment. An old build for Debian10 is archived as target/archive/IOC/AppDir-deb10

IOCs built under different EPICS version environment
cryhx_ioc had been built as a standard IOC under the environment of different EPICS version from /kagra/apps/epics-***. It seemed to be built with EPICS installed in the system region from Debian10 basic repository because of (probably) forgetting to load /kagra/apps/etc/epics-user-env***.sh before executing a build command. Anyway, it doesn't have a compatibility with an environment of Debian13 at all. So I started over from the configure step, not just the build. An old configured application for Debian10 is archived as target/archive/IOC/k1cryhx.
takahiro.yamamoto - 3:11 Thursday 09 April 2026 (36726) Print this report
I started to migrate on-demand scripts.

Pico, Stepper, and temperature control scripts were migrated from k1script1 to k1script0.

Though traverser script was worked also on k1script0, it's launched from MEDM screen with hard-coded server name. So all MEDM screens must be also updated. Because it's so hard to do remotely, I'll do it next week.

Rebooter script doesn't work on k1script0 because it depends on the telnetlib package which was obsoleted from Python3.13 whic h is one of the system packge of Debian13. So I replaced a function defined in the telnetlib package as a function defined by the socket packages. I haven't tested this new code with connecting rebooter devices yet. It will also be done in next week. In addition, MEDM screens for rebooter on which the server information is hard-coded must be also updated.

HWP script also has a server connection settings with hard-coded manner. So it must be rewritten as the new script server information. Rewritten code was already prepared and will be tested next week.

Once these tests are complete, we plan to proceed with the actual deployment. These are remaining tasks of the migration work for k1script.
takahiro.yamamoto - 2:29 Wednesday 15 April 2026 (36747) Print this report
Migration of all on-demand scripts were completed to k1script0.
Now, we can stop k1script1 which is old server.
OS upgrade of k1script1 will be done tomorrow.

All systems and services are now summarized on JGW Wiki.

Please keep this page up to date whenever you add a new service or system.
This will reduce the effort required for future server updates.
In fact, with this update, identifying services for which we had no information was more challenging than ensuring compatibility with the new OS.

-----
Traverser script
I had already confirmed that traverser script (/opt/rtcds/userapps/release/cds/common/scripts/epics-motor-control/traverser/traverser_start.py) was worked well on the new server. But server connection and environmental variables were hard-coded on shell command block of MEDM screen files. So migration required to modify several MEDM screens. So I prepared a wrapper script (/opt/rtcds/userapps/release/cds/common/scripts/epics-motor-control/traverser/medm_traverser_start.sh) in which necessary information is set. Thanks to this implementation, we won't need to find related MEDM screens and to update them in future OS upgrade.

Rebooter script
In Python3.13, telnetlib which is used in the rebooter script (/opt/rtcds/userapps/release/cds/common/scripts/epics-motor-control/picomotor/pico_power_control.py) is completely deprecated. So I rewrote a function derived from telnetlib as one derived from socket package. Due to differences in escape sequences and control codes, it has been modified quite a bit. And also, a wrapper script (/opt/rtcds/userapps/release/cds/common/scripts/epics-motor-control/picomotor/medm_pico_power_control.sh) is also prepared to avoid hard-coding of various parameters on MEDM screens. I needed to modify hundreds of shell command blocks to migrate from k1script1 to k1script0 in this time. Identifying and fixing related MEDMs was the most tough task of the migration work of script server.

HWP script
I had prepared an HWP script to avoid hard-coding in the previous version, but I realized that it was difficult to avoid hard-coding due to bad implementation of the callback function. (And while it probably hasn’t caused any practical problems yet, the sudores configuration on the RaspPi is likely set up incorrectly.) So, I rewrote the hard-coded `k1script1` to `k1script0`. To eliminate hard-coding entirely, HWP script must be redesigned drastically.

Phytron script
Though I couldn't find any information about Phytron script (/opt/rtcds/userapps/release/cds/common/scripts/epics-motor-control/phytron/phytron_start.py), I happened to discover that this script was running on k1script1. Implementation of this script is quite similar to traverser script. So I prepared a wrapper script (/opt/rtcds/userapps/release/cds/common/scripts/epics-motor-control/phytron/medm_phytron_start.sh) to avoid hard-coding on the shell command block of MEDM screens.
Search Help
×

Warning

×