Followed the instruction on this elog to restart the rsync server daemon

controls@nodus|etc> sudo systemctl start rsyncd.service
controls@nodus|etc> sudo systemctl enable rsyncd.service
controls@nodus|etc> sudo systemctl status rsyncd.service
● rsyncd.service - fast remote file copy program daemon
   Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2023-06-21 21:00:44 PDT; 13s ago
 Main PID: 13146 (rsync)
   CGroup: /system.slice/rsyncd.service
           └─13146 /usr/bin/rsync --daemon --no-detach

Jun 21 21:00:44 nodus.martian systemd[1]: Started fast remote file copy program daemon.
Jun 21 21:00:44 nodus.martian systemd[1]: Starting fast remote file copy program dae.....
Hint: Some lines were ellipsized, use -l to show in full.

if systemctl was handling it, how come it died? Or did someone kill it on purpose? I wish we had a tool like Monit or Nagios running to tell us about these things.

I pulled out the YEND acromag chassis to check how a connection is made. I unplugged it and then opened it without removing any front panel connections, and then I proceeded to wire the XEND acromag chassis at the electronics bench. After the work was done, I pushed it back but I couldn't restart modbusIOC, even after running daemon-reload on c1auxey1. The ETMY watchdogs are down for now, as are the vertex and XEND ones. I tried restarting c1auxey1 but this didn't help, so maybe something was wrong when mounting the NFS? I will continue this restoration tomorrow and then replicate this at the XEND.

UPDATE Tue Oct 3 10:13:17 2023

I fixed this issue by ensuring the nfs mount was working. To do this, from c1auxey1 I ran:

and then I restarted the modbusIOC.service. Finally, I damped ETMY.

UPDATE Tue Oct 3 16:17:54 2023

[JC, Paco]

The ETMX acromag chassis wiring is complete (Attachment #1) including the optoisolator bit. JC is completing the front panel arrangement and labels and we should be good to go. I moved a binary output chassis from near the vertex rack to the XEND rack and plan to install it along with the acromag chassis to mirror the YEND rack. Finally, the next step is to correctly deploy the modbusIOC service and paying attention to recent changes, for example those in (40m/17702). Since the wiring is similar to YEND, maybe we can simply copy the db file contents.

# On Linux, "ezcastep" will interpret negative steps as command line arguments,
# because the GNU library interprets anything starting with a dash as a flag.
# There are two ways around this.  One is to set the environment variable
# POSIXLY_CORRECT and the other is to inject "--" as a command line argument
# before any dashed arguments you don't want interpreted as a flag.  The former
# is easiest to use here:

if (`uname` =~ m/Linux/) {
    # Add an environment variable for child processes
    $ENV{'POSIXLY_CORRECT'} = 1;
}

pushd /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86
setenv PATH ${PATH}:`pwd`
cd /cvs/cds/caltech/users/tf/build/labca_2_1/lib/linux-x86
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:`pwd`
popd

addpath /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86/labca
help labca
foo = lcaGet('C1:PSL-FSS_RCTRANSPD')