signal-cli-rest-api
signal-cli-rest-api copied to clipboard
bbernhard
Unable to link device via QR code
The problem
As of January 24, I am no longer able to perform QR code based device linking, from the android Signal client, which now reports that the QR code created by signal-cli-rest-api does not represent a valid signal linking URI. I'm guessing the issue arose on the 24th, because that was the release date of the signal android client v7.31.1 however, I can't say for sure, as my test server remained linked until the 28th (when I unlinked). I have since not been able to re-link. An image of the error as presented in the android signal client is attached. No errorts are logged on the signal-cli-rest-api side, beyond the informational QR code http request. I would expect this related to some slight restructuring of linking URLs on the signal side which would likely have to be addressed upstream, within https://github.com/AsamK/signal-cli but figured it would be worth noting here.
Are you using the latest released version?
- [x] Yes
Have you read the troubleshooting page?
- [x] Yes
What type of installation are you running?
signal-cli-rest-api Docker Container
In which mode are you using the docker container?
Normal Mode
What's the architecture of your host system?
arm64
Additional information
Worth noting that I tested both latest and latest-dev tagged images. Both exhibited this behavior.
Does it make a difference if you try another mode (e.g json-rpc)?
Just tried with Version 7.32.2 on my Android phone and it works there.
If not already done, please also try with bbernhard/signal-cli-rest-api:0.178-dev
@bbernhard Thanks for your quick followup. I've performed the tests you suggest. I was already using v0.178-dev v0.178-dev so updated my android signal client to 7.32.2 with the server in normal mode, with the same results. I then switched to json-rpc mode which yielded the following error at http://localhost:8080/v1/qrcodelink?device_name=hobart-signal-bot
{"error":"Couldn't create QR code: write tcp 127.0.0.1:44090-\u003e127.0.0.1:6001: write: broken pipe"}
UPDATED: somehow the above webpage error didn't make it into the initial message.
And the following docker console log:
Attaching to signal-cli-rest-api-admin
signal-cli-rest-api-admin | + set -e
signal-cli-rest-api-admin | + [ -z /home/.local/share/signal-cli ]
signal-cli-rest-api-admin | + usermod -u 1000 signal-api
signal-cli-rest-api-admin | + groupmod -o -g 1000 signal-api
signal-cli-rest-api-admin | usermod: no changes
signal-cli-rest-api-admin | + chown 1000:1000 -R /home/.local/share/signal-cli
signal-cli-rest-api-admin | + cat
signal-cli-rest-api-admin | + cap_prefix=-cap_
signal-cli-rest-api-admin | + cat /proc/sys/kernel/cap_last_cap
signal-cli-rest-api-admin | + seq -s ,-cap_ 0 40
signal-cli-rest-api-admin | + caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40
signal-cli-rest-api-admin | + [ json-rpc = json-rpc ]
signal-cli-rest-api-admin | + /usr/bin/jsonrpc2-helper
signal-cli-rest-api-admin | time="2025-02-07T14:53:10Z" level=info msg="Updated jsonrpc2.yml"
signal-cli-rest-api-admin | + [ -n ]
signal-cli-rest-api-admin | + service supervisor start
signal-cli-rest-api-admin | + supervisorctl start all
signal-cli-rest-api-admin | Starting supervisor: supervisord.
signal-cli-rest-api-admin | + hostname -I
signal-cli-rest-api-admin | + awk {print $1}
signal-cli-rest-api-admin | + export HOST_IP=172.22.0.2
signal-cli-rest-api-admin | + exec setpriv --reuid=1000 --regid=1000 --init-groups --inh-caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40 signal-cli-rest-api -signal-cli-config=/home/.local/share/signal-cli
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=info msg="Started Signal Messenger REST API"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # A fatal error has been detected by the Java Runtime Environment:\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # SIGILL (0x4) at pc=0x0000ffff6bc67c5c, pid=42, tid=53\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # JRE version: (21.0.5+11) (build )\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # Java VM: OpenJDK 64-Bit Server VM (21.0.5+11-Ubuntu-1ubuntu122.04, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # Problematic frame:\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # j java.lang.System.registerNatives()V+0 [email protected]\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # No core dump will be written. Core dumps have been disabled. To enable core dumping, try \"ulimit -c unlimited\" before starting Java again\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # An error report file with more information is saved as:\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # /tmp/hs_err_pid42.log\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: [0.013s][warning][os] Loading hsdis library failed\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # The crash happened outside the Java Virtual Machine in native code.\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: # See problematic frame for where to report the bug.\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T14:53:12Z" level=error msg="Couldn't read data for number <multi-account>: EOF. Is the number properly registered?"
signal-cli-rest-api-admin | [GIN] 2025/02/07 - 14:54:34 | 400 | 65.625µs | 192.168.65.1 | GET "/v1/qrcodelink?device_name=hobart-signal-bot"
signal-cli-rest-api-admin | time="2025-02-07T14:58:12Z" level=error msg="Couldn't read data for number <multi-account>: EOF. Is the number properly registered?"
signal-cli-rest-api-admin | time="2025-02-07T15:03:12Z" level=error msg="Couldn't read data for number <multi-account>: EOF. Is the number properly registered?"
signal-cli-rest-api-admin | time="2025-02-07T15:08:12Z" level=error msg="Couldn't read data for number <multi-account>: EOF. Is the number properly registered?"
Strange that the logs suggest that an attempt was made to register rather than link... or is that a fallback case of some kind? It's worth pointing on that I'm on an M4 Macbook Pro host, which I understood was an issue with native, but I didn't think would be an issue with json-rpc. With this in mind, I will endeavor to perform the same tests on an x86_64 docker host.
Strange that the logs suggest that an attempt was made to register rather than link... or is that a fallback case of some kind?
There is no fallback in place. But I do not see any registering attempt in the log file. 🤔
This line
signal-cli-rest-api-admin | [GIN] 2025/02/07 - 14:54:34 | 400 | 65.625µs | 192.168.65.1 | GET "/v1/qrcodelink?device_name=hobart-signal-bot"
indicates that you've called the qrcodelink endpoint to get the QR code, which is what you wanted to do.
But it looks like as if the JAVA VM is totally crashing. This thread here looks related: https://discuss.elastic.co/t/startup-failure-arch64-crashes-arm64-fedora-rocky9-centos9-macbook-m4-docker/371708/7. I guess there's a bug in OpenJDK right now
Strange that the logs suggest that an attempt was made to register rather than link... or is that a fallback case of some kind?
There is no fallback in place. But I do not see any registering attempt in the log file. 🤔
The log below is generated at container startup before visiting the webpage to generate and scan the qr code for linking. Theline that suggested to me there was some kind of fallback was the last line:
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Couldn't read data for number <multi-account>: EOF. Is the number properly registered?"
But it looks like as if the JAVA VM is totally crashing. This thread here looks related: https://discuss.elastic.co/t/startup-failure-arch64-crashes-arm64-fedora-rocky9-centos9-macbook-m4-docker/371708/7. I guess there's a bug in OpenJDK right now
I saw reference to this error when I was investigating signald as a connectivity option. I followed the documented solution, adding the two environment variables to my docker-compose file and got the same result (at startup, before the qr code http request):
signal-cli-rest-api-admin | + exec setpriv --reuid=1000 --regid=1000 --init-groups --inh-caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40 signal-cli-rest-api -signal-cli-config=/home/.local/share/signal-cli
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=info msg="Started Signal Messenger REST API"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # A fatal error has been detected by the Java Runtime Environment:\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # SIGILL (0x4) at pc=0x0000ffff6fc67c5c, pid=42, tid=53\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # JRE version: (21.0.5+11) (build )\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # Java VM: OpenJDK 64-Bit Server VM (21.0.5+11-Ubuntu-1ubuntu122.04, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # Problematic frame:\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # j java.lang.System.registerNatives()V+0 [email protected]\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # No core dump will be written. Core dumps have been disabled. To enable core dumping, try \"ulimit -c unlimited\" before starting Java again\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # An error report file with more information is saved as:\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # /tmp/hs_err_pid42.log\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: [0.012s][warning][os] Loading hsdis library failed\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # The crash happened outside the Java Virtual Machine in native code.\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: # See problematic frame for where to report the bug.\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Received unparsable message: #\n"
signal-cli-rest-api-admin | time="2025-02-07T18:06:35Z" level=error msg="Couldn't read data for number <multi-account>: EOF. Is the number properly registered?"
For completeness, I pulled the mentioned /tmp/hs_err_pid42.log file from the running container. I'm not a big java guy in recent years. Is there a a JRE version that doesn't exhibit the SVE issue? From what I can tell, in recent JRE releases, UseSVE=0 is ignored as apparently described here: OpenJDK bug
The log below is generated at container startup before visiting the webpage to generate and scan the qr code for linking. Theline that suggested to me there was some kind of fallback was the last line:
I guess the log output is a bit misleading in that case. Internally there is no real difference between a dedicated registered number and a linked account. So, I didn't differentiate in the log message between those two cases. It basically just means, there is no number registered/account linked.
Unfortunately, I do not have much experience with Java either. According to the bug tracker, it should be fixed with OpenJDK 21.0.7 - which, if I am not completely mistaken is not yet released.
Did you try the env variables also with the normal mode? The json-rpc mode is a bit special, as in json-rpc mode, signal-cli gets started by supervisorctland afair it doesn't necessarily use the system env variables.
Could you please switch back to normal mode and enable the debug mode (as described here: https://github.com/bbernhard/signal-cli-rest-api/blob/master/doc/DEBUG.md). This allows you to run the signal-cli commands directly in the container. Since the json-rpc mode and the normal mode uses the same Java application, I think you should see the crash also there. And as you are inside the docker container its also easier to play around with the env variables and see if that does have any impact.
For clarirty, in normal mode, the JSK was not crashing at startup, even without the SVE environment variables, but I went ahead with the test, recognizing it should probably it would in the best case fail elegantly, saying no number was registered or device linked, so it wouldn'ty matter what numbers I used in the send test. I used your example exactly as written, because essentially it wouldn't matter. The workflow is presumably what we want to see here. This is what we got:
signal-cli-rest-api-admin | [GIN] 2025/02/07 - 19:39:24 | 204 | 870.958µs | 192.168.65.1 | POST "/v1/configuration"
signal-cli-rest-api-admin | time="2025-02-07T19:41:33Z" level=debug msg="If you want to run this command manually, run the following steps on your host system:"
signal-cli-rest-api-admin | time="2025-02-07T19:41:33Z" level=debug msg="*) docker exec -it / /bin/bash"
signal-cli-rest-api-admin | time="2025-02-07T19:41:33Z" level=debug msg="*) su signal-api"
signal-cli-rest-api-admin | time="2025-02-07T19:41:33Z" level=debug msg="*) echo 'Hello World!' | signal-cli --config /home/.local/share/signal-cli -a +431212131491291 send --message-from-stdin +4354546464654 +4912812812121 --notify-self"
signal-cli-rest-api-admin | [GIN] 2025/02/07 - 19:41:33 | 400 | 26.78ms | 192.168.65.1 | POST "/v2/send"
signal-cli-rest-api-admin | time="2025-02-07T19:41:33Z" level=debug msg="signal-cli output (stdout): #\n# A fatal error has been detected by the Java Runtime Environment:\n#\n# SIGILL (0x4) at pc=0x0000ffff8bc67c5c, pid=148, tid=159\n#\n# JRE version: (21.0.5+11) (build )\n# Java VM: OpenJDK 64-Bit Server VM (21.0.5+11-Ubuntu-1ubuntu122.04, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)\n# Problematic frame:\n# j java.lang.System.registerNatives()V+0 [email protected]\n#\n# No core dump will be written. Core dumps have been disabled. To enable core dumping, try \"ulimit -c unlimited\" before starting Java again\n#\n# An error report file with more information is saved as:\n# /tmp/hs_err_pid148.log\n[0.012s][warning][os] Loading hsdis library failed\n#\n# The crash happened outside the Java Virtual Machine in native code.\n# See problematic frame for where to report the bug.\n#\n"
signal-cli-rest-api-admin | time="2025-02-07T19:41:33Z" level=debug msg="signal-cli output (stderr): "
That was the end of the log output, despite it showing that it might display something to stderr and copy it into the log. The command issued, and response follow:
% curl -X POST -H "Content-Type: application/json" -d '{"logging": {"level": "debug"}}' 'http://127.0.0.1:8080/v1/configuration'
% curl -X POST -H "Content-Type: application/json" -d '{"message": "Hello World!", "number": "+431212131491291", "recipients": ["+4354546464654", "+4912812812121"]}' 'http://127.0.0.1:8080/v2/send'
{"error":"#\n# A fatal error has been detected by the Java Runtime Environment:\n#\n# SIGILL (0x4) at pc=0x0000ffff8bc67c5c, pid=148, tid=159\n#\n# JRE version: (21.0.5+11) (build )\n# Java VM: OpenJDK 64-Bit Server VM (21.0.5+11-Ubuntu-1ubuntu122.04, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)\n# Problematic frame:\n# j java.lang.System.registerNatives()V+0 [email protected]\n#\n# No core dump will be written. Core dumps have been disabled. To enable core dumping, try \"ulimit -c unlimited\" before starting Java again\n#\n# An error report file with more information is saved as:\n# /tmp/hs_err_pid148.log\n[0.012s][warning][os] Loading hsdis library failed\n#\n# The crash happened outside the Java Virtual Machine in native code.\n# See problematic frame for where to report the bug.\n#\n"}%
All of this seems to suggest that this will run cleanly on x86_64. I may be able to find one later today to test. The OpenJDK ticket seems to suggest this issue is specific to the Mac M series implementation of ARM64, so I may try it on Nvidia AGX Orin Arm hardware which I have more readily accessible. In prodfuction this system will likely be on x86_64 so this may be just an academic exercise.
Interestingly, this OpenJDK ticket seems to suggest that the fix has already been backported to 21.05 but maybe not 21.05+11 When was the JRE last updated in the docker image builds?
Yeah, it definitely looks like an issue specific to the Mac M series of ARM64. :/
When was the JRE last updated in the docker image builds?
When a new image gets built, it always pulls the latest packages from the repository. Currently, Ubuntu jammy is used as base image. The develop image was built ~1 week ago.
I'm going to take a look at swapping out the base images for these https://github.com/adoptium/containers using alpine which will give us much finer grained idk versioning but also shrink the final image size substantially. Unfortunately, the current image won't build on a Mac without jdk errors as it is, so I'm going to first start from an x86_64 environment where the existing build works
I did try to use alpine as a base image a few years ago. But unfortunately it wasn't working with musl - so I switched to a base image which uses glibc.
While this result is unsurprising, I have in fact, confirmed that the issue is related specifically to a version of the JVM as it relates to M series Mac hardware implementation of vector mathematics. It seems worth documenting here if for no other reason than for SEO purposes.
Have you seen this? https://github.com/bbernhard/signal-cli-rest-api/issues/631
This seems to be the same issue, no?
I had not. It does seem to be fundamentally the same issue although I have limited confidence that we can expect a solution from openJDK that presents itself only within docker running on an arm mac host. I would suggest that possibly the solution is to pin the Java JRE to a version we know works across all platforms within your project. Certainly we should revisit this periodically to determine when a solution has been found across modern JRE/JDK implementations but for the moment the best solution is to pin a specific known working version.
On Mon, Feb 10, 2025, 02:51 Bernhard B. @.***> wrote:
Have you seen this? #631 https://github.com/bbernhard/signal-cli-rest-api/issues/631
This seems to be the same issue, no?
— Reply to this email directly, view it on GitHub https://github.com/bbernhard/signal-cli-rest-api/issues/651#issuecomment-2647185516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABHNRYTOKEYO26N4CTYA4D2PBLBZAVCNFSM6AAAAABWRUUR46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBXGE4DKNJRGY . You are receiving this because you authored the thread.Message ID: @.***>