Problems w/ Conga/HttpCommand and Upgrade to Bullseye

[tomgarwin]

I have a raspberry PI 3B+ that has been happily running headless using Dyalog for years -- including since release of 18.2. It acts as the mediator between various other computers that perform smart home function and has several Conga servers and clients and many many uses of HttpCommand. It has 4 thread with each looped. For reasons of caution (I am not sure that all the other computers are as careful at separating conversations as Conga) I use :hold and tokens to separate HttpCommands and multiple uses of a short-lived conga server. With the threaded execution I also do a lot of error trapping and then I use ⎕DM occasionally to apprise me of any odd errors that crop up. This all was working fine but recently I noticed that the following error was being produced with high frequency:

DOMAIN ERROR HttpCmd[504] {0:: ⋄ ⎕NDELETE ⍵}tmpFile

I think but can't be sure that this started after updating the Dyalog packages under Buster. I believe I was originally on the version of Conga from March 2022 and this error started somewhere around 4.x. I have upgraded HttpCommand to the most recent version and am using current Conga including connecting HttpCommand to a Conga root but the above error persists.

I stupidly upgraded to Bullseye without keeping a full backup. One of my requirements is that the APL program come back up after a power failure so I have used a SystemD service to start Dyalog and the appropriate workspace. On upgrading to Bullseye the SystemD service stopped working but somehow changing the "after" target from multi-user to default.target made it start. However the workspace would seem to start and than operate fitfully when connected to Ride. (it would stop in all 4 threads and sometimes it would come to life again if I executed something from the live session. The workspace worked properly on a Windows PC. I removed and re-installed 18.2 after upgrading to Bullseye with no change. I finally discovered that if started using APL with the same command from a SSH terminal session as opposed the the SystemD service it would work properly even with Ride listening in. But it won't restart properly after a power down.

Any suggestions would be appreciated! Below are the files for the SystemD Dyalog.Service and the Runapl2019 file that has been used (eiher by SystemdD or via SSH) to start Dyalog APL.

/usr/local/bin/runapl2019

#!/bin/bash

echo "Launching Dyalog from /usr/local/bin/runapl2019
RIDE_INIT="SERVE:*:4502" /usr/bin/dyalog /home/pi/ws/piboot.dws +s -ride -q


/etc/systemd/system/dyalog.service:

[Unit]
Description=Dyalog APL Ride Startup
###After=multi-user.target
After=default.target

[Service]
Type=simple
User=pi
Group=pi
WorkingDirectory=~
StandardError=null
ExecStart=/usr/local/bin/runapl2019
Restart=always

[Install]
### WantedBy=multi-user.target
WantedBy=default.target

[tomgarwin]

Is it possible that when I use Ride 4.4 from a PC to attach to the interpreter on the PC that it's starting another instance of APL with the launch workspace and so I end up (sometimes, at least) having two instance of the same code? It may be that this could cause conflict with communications or via the conga libraries? Using ps -aux I did find multiple processes and also confirmed at least once that an instance I started from a terminal window had a different workspace start time from the instance that I found when I attached via Ride 3 minutes later. I had assumed that attaching with Ride would connect with the already running workspace, not automatically open and run the quad-LX code in a new instance.

Also based on the 18.2 Unix documentation I wonder if some of the Command line parameters that I used (based on advice years ago from Dyalog) are no longer having the desired effect.

It does appear that the problems I am having have more to do with SystemD than the boot process because booting up and then starting the dyalog.system process and attaching by Ride 4.4 also produces crippled execution. (SI shows all threads just hanging in various waits or other statements subject to breaks in execution)

[Vince|Dyalog]

Hi Tom,
1) I thought you could modify the ⎕NDELETE line to try to get more information about the domain error like this:

:Trap 0
⎕NDELETE tmpFile
:Else
#.out←{⎕ML←1 ⋄ ⎕IO←1 ⋄ ⎕DMX.(⍪{⍵(⍎⍵)}¨⎕NL-2)}1
2 ⎕NQ'.' 'dumpws' '/tmp/trappederror.cor'
:EndTrap

This dumpws method generates an aplcore-like file but does not terminate the process. We would be able to copy #.out from the file.

2) RIDE would not have dyalog start a workspace unless it is in the settings. Please write an email to me at Dyalog Support and let me know how you start RIDE and Dyalog on the PC.

3) Our command line parameters are listed in our Dyalog for Windows Installation and Configuration Guide, but I think it applies to Dyalog on other platforms as well.

https://help.dyalog.com/18.2/#UserGuide ... 257C_____6

I think the -ride option is not used anymore.

-s Disable the Session. This option is ignored in Windows
versions.

+s Force the display of the Session when it would otherwise
not be shown.

-q Don't quit APL on error (used when piping input into
APL).

+q Quit APL on error. In earlier versions of Dyalog, quitting
on error saved a workspace with the reserved name
CONTINUE; this behaviour can be re-enabled using
2704⌶.

Regards,

Vince