Auval trouble on a Big Sur machine through ssh

Platform Specific
1

Hi everyone,

Sorry if it’s not the right place to post this, I don’t think the issue is related to Juce but I thought maybe other audio developers might have encountered this and could help…

There’s a bit of history on this stackexchange post : audio - Auval and Auvaltool not working through SSH - Ask Different

Basically, auval finds plugins when run in local, but fails when run through SSH (our main case when using jenkins to manage all the build chain of a plugin). The workaround in the accepted answer worked for a moment, but after updating the machines to Big Sur, even this fails. The response we get from auval when trying to validate a plugin is this one :

ERROR: Cannot get Component's Name strings
ERROR: Error from retrieving Component Version: -50

* * FAIL
--------------------------------------------------
TESTING OPEN TIMES:
FATAL ERROR: didn't find the component

Of course the component exists and the same command directly on the machine works. We also tried the killall -9 AudioComponentRegistrar but it does not solve the problem. The Auval version is 1.8.0

And what is even weirder is that on my machine, which is on Monterey, I have Auval 1.10.0 and it does work. I still need to use the local server workaround if I connect through ssh but it works. I tried using my Auval/Auvaltool binary on the Big Sur machine but the problem is the same.

I don’t really know what I can try further to make it work… Did anybody encounter this? And if it’s the case did you manage to solve it?

2

This problem looks familiar. I had trouble to use auval in iTerm2 / zsh when it also only found apple AUs and failed even when using -v ...

I could imagine that the shell you use in ssh also suffers from that problem:

I don’t know if it is related…

Maybe try a different shell or use ssh in terminal rather than iTerm?

3

Hi, as commented on the original answer on stackexchange, we later moved to a different approach.
Instead of calling up the python-server, we are now connecting our jenkins nodes via the webstart method (“Launch agent by connecting it to the master”).
Using launchctl on the node this basically calls up the master using a secret. Using this method we managed to directly call all auval commands without going through the server.
For this to work you’ll need to place the agent.jar somewhere on the node and execute it, passing the secret and the url of the node to the master. We placed the follwing plist in ~/Library/LaunchAgents/.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-/Apple/DTD PLIST 1.0/EN" "http:/www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>YOUR_DAEMON_NAME</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/java</string>
        <string>-jar</string>
        <string>PATH_TO_AGENT_JAR</string>
        <string>-jnlpUrl</string>
        <string>JENKINS_NODE_URL</string>
        <string>-workDir</string>
        <string>WORKING_DIRECTORY</string>
        <string>-secret</string>
        <string>JENKINS_NODE_SECRET</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>SessionCreate</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
    <key>UserName</key>
    <string>JENKINS_NODE_USERNAME</string>
    <key>StandardOutPath</key>
    <string>PATH_TO_LOGFILE</string>
    <key>StandardErrorPath</key>
    <string>PATH_TO_LOGFILE</string>
</dict>
</plist>
1 Like
4

Hey @daniel, it’s been a while, thanks a lot for your answer :slight_smile: Unfortunately we already investigated this and we don’t use iTerm, it was not related to that.

Thanks @vallant, you’re a true hero on this one, first the server workaround, now this, thanks a lot for your help, we’ll owe you a drink (or more) if we meet at the ADC. I’ll confirm when we test the solution but it makes total sense so I’m pretty optimistic :slight_smile:

Cheers!

5

Glad that i could help! :slight_smile: