Receiving 400 Response and API Timeout

[funkybunch]

I have the Docker container up and running, but I'm getting a 400 HTTP response as well as a {"error":"process killed as timeout reached"} message in the body. I haven't tried all endpoints, but /v1/about works just fine, but anytime I try to register a number it times out.

Has anyone else run into this? I'm not seeing much else in logs unfortunately. I did modify the code I'm running to run on port 3000. I'm running this on Docker Swarm and port 8080 was already in use. Are there places that port 8080 is expected that I might be missing?

A way to configure the port at build/runtime would be super helpful if that is what is causing the issue I'm having.

[funkybunch]

If I'm reading this file right, it looks like the CLI is failing to run?

https://github.com/bbernhard/signal-cli-rest-api/blob/master/src/api/api.go#L260

[bbernhard]

That's strange.

Are there places that port 8080 is expected that I might be missing?

Where did you change the port? The port is exposed in the Dockerfile, in the swagger documentation URL and in the router.Run() call. If no argument is provided it listens per default on 0.0.0.0:8080. So, if you would like to listen on a different port, you would need to do it like that: router.Run(":6000") which e.g would listen on port 0.0.0.0:6000.

A way to configure the port at build/runtime would be super helpful if that is what is causing the issue I'm having.

I'll have a look whether I can add something!

Could you maybe post the curl request (please obfuscate any private information) you are using when the timeout happens?

As you've modified the sourcecode, I guess you are using a self-built docker image, right? On which host architecture (ARM, x86-64, etc) is the docker container running?

[funkybunch]

Where did you change the port? The port is exposed in the Dockerfile, in the swagger documentation URL and in the router.Run() call. If no argument is provided it listens per default on 0.0.0.0:8080. So, if you would like to listen on a different port, you would need to do it like that: router.Run(":6000") which e.g would listen on port 0.0.0.0:6000.

I changed it in the 3 places you mentioned. Gin seems to be running just fine which makes me think it the port isn't the source of the issue (although a way to configure it at runtime would still be nice!). To that end it's worth mentioning that simply setting the PORT environment variable in the Dockerfile did not work for me. Gin supposedly defaults to 8080 unless defined in the code or the PORT env variable is set, but there must been some way to pass it in that I still missed.

Could you maybe post the curl request (please obfuscate any private information) you are using when the timeout happens?

The CURL request I've been using was pulled from the docs:

curl -X POST -H "Content-Type: application/json" 'http://<docker swarm IP>:3000/v1/register/<number with +{country code}>'

I tried with a number that had already been registered with Signal (which is supposed to just register like normal based on the Signal CLI, just cut off the old account). I also tried with a brand new number that had not been registered yet.

As you've modified the sourcecode, I guess you are using a self-built docker image, right? On which host architecture (ARM, x86-64, etc) is the docker container running?

You are correct that I'm building the image myself. It's being built on ARM architecture that is also running the Docker containers.

The other thing I'm doing is running it in Docker Swarm (Raspberry Pi cluster), but the errors occur just the same even when I'm running it using docker-compose. It's also worth noting that I currently have the standalone Signal CLI running on a different Raspberry Pi without issue. It just isn't Dockerized and doesn't have the API wrapper installed.

Edit: clarity and spelling

[bbernhard]

You are correct that I'm building the image myself. It's being built on ARM architecture that is also running the Docker containers.

Are you building the ARM docker image directly on the Raspberry Pi that it is running on, or are you "cross-building" it on a different architecture (e.g via docker buildx)?

I am running into a similar issue when I am building the ARM image on my x86-64 system with docker buildx (I'll create a ticket for that later). That's btw. also the reason why the bbernhard/signal-cli-rest-api:latest tag on dockerhub hasn't been updated in a while. At the moment, I do not know why this happens, but what works for me is to build the image directly on the Raspberry Pi. The reason for that is, that the signal-clibinary in the docker container somehow blocks forever.

edit: Could you maybe build the docker container on a different platform (e.g x86-64) and run the docker container there? If it works there, then you are probably running in the same issue as I am.

[bbernhard]

btw: here is the issue #42

[funkybunch]

I've been building directly on the Raspberry Pi using docker-compose build. I'll give it a shot on my x86-64 machine, I'm sure at this point its an issue with how the dependencies are playing with the ARM architecture. I'm wondering if the issue is actually related to Java.

Now that I've been refreshing myself on the docs for the Signal CLI repo, I remember I had to manually configure the Unlimited Strength Crypto Java settings when I installed it on the Raspberry Pi I have it on now. I wonder if the version of Java installed for ARM architecture doesn't include this and is causing the CLI to lock up when called through the API. Any idea on how to check that?

Signal CLI Wiki discussing Unlimited Strength Crypto: AsamK/signal-cli#101

Linked Stack Overflow answer with how to manually configure it: https://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters

Still odd that it just locks up and doesn't fail loudly. I remember some extensive stderr messages when I was setting it up on a standalone Pi. Could Gin be piping the stderr output elsewhere?

[bbernhard]

Still odd that it just locks up and doesn't fail loudly. I remember some extensive stderr messages when I was setting it up on a standalone Pi. Could Gin be piping the stderr output elsewhere?

At least on my machine it really blocks.

I think it is related to Ubuntu 20.04, docker and seccomp (for details, see this ticket here: #42).

Could you maybe run your docker container with --privileged or --security-opt seccomp:unconfined to see if that changes anything? Both of those options are not recommended for production use, but for testing it should be perfectly fine.

[funkybunch]

Yup, using the --security-opt seccomp:unconfined worked.

I have it working using docker-compose by adding security_opt to my docker-compose.yml file:

services
  signal-cli-rest-api:
      security_opt:
        - seccomp:unconfined

Unfortunately the option to bypass the security settings is disabled in Docker Swarm. I'm playing around with different versions of the JRE to see if simply switching the image referenced in the Dockerfile is enough to make it work. I did confirm that ARM is supported by the JRE image already being used, but if it is an upstream problem with Ubuntu 20 then I'd need to find an image > 8u161 and using Ubuntu 18.

[bbernhard]

I think that's the change where they switched from Ubuntu 18.04 to 20.04 - which happened 29 days ago. So I guess if you find the docker tag for the adoptopenjdk:11-jre-hotspot image right before that change, I think it could work.

[funkybunch]

I think I figured it out. Looks like the 11-jdk-hotspot-bionic tag was first published a month ago when they upgraded, so since they still provide that image specific to Bionic it should be stable to use without fear of them changing it on you again. That image uses Ubuntu 18.04 Bionic and since the Go base image you're using uses Debian Buster it should be fully compatible since Ubuntu Bionic is based on Debian Buster.

To test things out I just changed the Dockerfile line from:

FROM adoptopenjdk:11-jdk-hotspot

to

FROM adoptopenjdk:11-jdk-hotspot-bionic

That seemed to do the trick. Even works deployed to Docker Swarm now. I can submit a PR if you like. Should resolve #42 as well if you decide to go that route.

[bbernhard]

I can submit a PR if you like. Should resolve #42 as well if you decide to go that route.

That would be great! (I don't care about the actual Ubuntu version as long as it is working and still supported 😀 ; Bionic Beaver is supported until April 2028, so that's perfect.)

Many thanks!

[funkybunch]

@bbernhard PR #43 is up. It also includes some code that allows the port to be configured if building via docker-compose.