JSON-RPC-Mode: Can't read data for number +4123123123: EOF. Is the number properly registered?"

[horst23666]

The problem

Hi there!
I cannot get the JSON-RPC Mode to work. It has worked a couple of weeks but now after redeploying my container it stopped working. I have already started from scratch by deleting the data folder.
I am using the latest build. Normal-Mode is working flawlessly. As I am triggering Automations via signal messages I need json-rpc to work. Normal mode is sadly not an option for me.

After starting the container. I receive the following message:
level=error msg="Couldn't read data for number +121231123123: EOF. Is the number properly registered?"

My landline number has ben successfully registered. As mentioned above normal mode is working.

supervisor.log:
`2023-02-10 20:22:08,982 INFO Included extra file "/etc/supervisor/conf.d/signal-cli-json-rpc-1.conf" during parsing
2023-02-10 20:22:08,993 INFO RPC interface 'supervisor' initialized
2023-02-10 20:22:08,993 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2023-02-10 20:22:08,996 INFO daemonizing the supervisord process
2023-02-10 20:22:08,998 INFO supervisord started with pid 32
2023-02-10 20:22:10,002 INFO spawned: 'signal-cli-json-rpc-1' with pid 34
2023-02-10 20:22:11,527 INFO success: signal-cli-json-rpc-1 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-02-10 20:22:25,702 INFO exited: signal-cli-json-rpc-1 (exit status 3; not expected)
2023-02-10 20:22:26,706 INFO spawned: 'signal-cli-json-rpc-1' with pid 100
2023-02-10 20:22:27,708 INFO success: signal-cli-json-rpc-1 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

out.log:
Error while checking account +123123123123: java.net.UnknownHostException: chat.signal.org: Temporary failure in name resolution

When I try to send a message in json-rpc mode directly within the container "signal-cli -a +12312312 send -m "test" +39402923"' Signal-CLI returns: INFO SignalAccount - Config file is in use by another instance, waiting…

To prevent write access issues in the home/.local/share/signal-cli folder, I created a volume to store signal-cli data. Nevertheless using a local folder to store the crypto keys lead to the same behavior.

Thank you very much in advance!! And thanks so muck for all the work you are putting into this great project!

Are you using the latest released version?

• Yes

Have you read the troubleshooting page?

• Yes

What type of installation are you running?

signal-cli-rest-api Docker Container

In which mode are you using the docker container?

JSON-RPC Mode

What's the architecture of your host system?

x86-64

Additional information

I am using an external Network.

My Docker Compose File:

version: "3"
services:
signal-api:
image: bbernhard/signal-cli-rest-api:latest
environment:
- MODE=json-rpc
ports:
- "9922:8080" #map docker port 8080 to host port 8080.
volumes:
- signal-cli-volume:/home/.local/share/signal-cli
networks:
Network-name:
ipv4_address: Local IP
networks:
qnet-static-eth0-11eefa:
name: qnet-static-eth0-11eefa
external: true
volumes:
signal-cli-volume:

[bbernhard]

When I try to send a message in json-rpc mode directly within the container "signal-cli -a +12312312 send -m "test" +39402923"' Signal-CLI returns: INFO SignalAccount - Config file is in use by another instance, waiting…

That is expected, as there is already another signal-cli instance running.

Error while checking account +123123123123: java.net.UnknownHostException: chat.signal.org: Temporary failure in name resolution

can you ping chat.signal.org?

[horst23666]

Yes I can ping chat.signal.org from within the container.

Maybe signal-cli is looking in the wrong directory for the config? I looked into the jsonrpc2.yaml

tail jsonrpc2.yml 
config:
  "+49mynumber":
    tcp_port: 6000
    fifo_pathname: /tmp/sigsocket0

Is "+49mynumber" pointing signal-cli to the config directory which is also supposed to be named "+49mynumber"?
When I check my data folder I see three folder/files "2123123", "2123123.d", accounts.db and no folder named +49mynumber". So is signal-cli is looking for the folder "+49mynumber"" in data? I am referring to this issue

[horst23666]

Hi,

following your steps @bbernhard from (being in json-rpc mode) here I am able to receive messages being send to my number.

root@signal-cli:/# supervisorctl stop all
signal-cli-json-rpc-1: stopped 

root@signal-cli:/# ps -ax | grep signal
    1 ?        Ssl    3:04 signal-cli-rest-api -signal-cli-config=/home/.local/share/signal-cli
  101 ?        Sl     0:13 /opt/java/openjdk/bin/java -classpath /opt/signal-cli-0.11.6/lib/signal-cli-0.11.6.jar:/opt/signal-cli-0.11.6/lib/lib.jar:/opt/signal-cli-0.11.6/lib/bcprov-jdk15on-1.70.jar:/opt/signal-cli-0.11.6/lib/jackson-annotations-2.14.1.jar:/opt/signal-cli-0.11.6/lib/jackson-core-2.14.1.jar:/opt/signal-cli-0.11.6/lib/signal-service-java-2.15.3_unofficial_65.jar:/opt/signal-cli-0.11.6/lib/jackson-databind-2.14.1.jar:/opt/signal-cli-0.11.6/lib/argparse4j-0.9.0.jar:/opt/signal-cli-0.11.6/lib/dbus-java-transport-native-unixsocket-4.2.1.jar:/opt/signal-cli-0.11.6/lib/logback-classic-1.4.5.jar:/opt/signal-cli-0.11.6/lib/jul-to-slf4j-2.0.6.jar:/opt/signal-cli-0.11.6/lib/dbus-java-core-4.2.1.jar:/opt/signal-cli-0.11.6/lib/HikariCP-5.0.1.jar:/opt/signal-cli-0.11.6/lib/slf4j-api-2.0.6.jar:/opt/signal-cli-0.11.6/lib/logback-core-1.4.5.jar:/opt/signal-cli-0.11.6/lib/protobuf-javalite-3.21.12.jar:/opt/signal-cli-0.11.6/lib/sqlite-jdbc-3.40.0.0.jar:/opt/signal-cli-0.11.6/lib/jsr305-3.0.2.jar:/opt/signal-cli-0.11.6/lib/libphonenumber-8.12.54.jar:/opt/signal-cli-0.11.6/lib/libsignal-client-0.21.1.jar:/opt/signal-cli-0.11.6/lib/okhttp-4.10.0.jar:/opt/signal-cli-0.11.6/lib/rxjava-3.0.13.jar:/opt/signal-cli-0.11.6/lib/okio-jvm-3.2.0.jar:/opt/signal-cli-0.11.6/lib/kotlin-stdlib-jdk8-1.6.20.jar:/opt/signal-cli-0.11.6/lib/kotlin-stdlib-jdk7-1.6.20.jar:/opt/signal-cli-0.11.6/lib/kotlin-stdlib-1.6.20.jar:/opt/signal-cli-0.11.6/lib/reactive-streams-1.0.3.jar:/opt/signal-cli-0.11.6/lib/kotlin-stdlib-common-1.6.20.jar:/opt/signal-cli-0.11.6/lib/annotations-13.0.jar org.asamk.signal.Main --output=json -u +4945192998614 --config /home/.local/share/signal-cli/ jsonRpc
  246 pts/0    S+     0:00 grep --color=auto signal
root@signal-cli:/# kill 101
root@signal-cli:/# ps -ax | grep signal
    1 ?        Ssl    3:20 signal-cli-rest-api -signal-cli-config=/home/.local/share/signal-cli
  259 pts/0    S+     0:00 grep --color=auto signal

root@signal-cli:/# su signal-api

signal-api@signal-cli:/$ signal-cli --output=json -u +MYNUMBER --config /home/.local/share/signal-cli/ jsonRpc 

{"timestamp":1676463529231,"message":"TEST","expiresInSeconds":0,"viewOnce":false}},"account":"+MYNUMBER","subscription":0}}

So it seems that generally json-rpc is working. the "data"-directory seems to blocked somehow

[akuntsch]

I have a very similar problem all of a sudden (I think after the recent update to 0.70).

native and normal modes work fine, but in json-rpc mode, I get the following error during container startup:

time="2023-10-29T08:16:05Z" level=info msg="Started Signal Messenger REST API"
time="2023-10-29T08:16:06Z" level=error msg="Couldn't read data for number : EOF. Is the number properly registered?"

/var/log/signal-cli-json-rpc-1/out.log then also contains the following error messages:

usage: signal-cli [-h] [--version] [-v] [--log-file LOG_FILE] [--scrub-log]
                  [-c CONFIG] [-a ACCOUNT] [-o {plain-text,json}]
                  [--service-environment {live,staging,sandbox}]
                  [--trust-new-identities {always,on-first-use,never}]
                  [--disable-send-log] [--dbus | --dbus-system]
                  {addDevice,addStickerPack,block,daemon,deleteLocalAccountData,finishChangeNumber,getAttachment,getUserStatus,joinGroup,jsonRpc,link,listAccounts,listContacts,listDevices,listGroups,listIdentities,listStickerPacks,quitGroup,receive,register,remoteDelete,removeContact,removeDevice,removePin,send,sendContacts,sendPaymentNotification,sendReaction,sendReceipt,sendSyncRequest,sendTyping,setPin,startChangeNumber,submitRateLimitChallenge,trust,unblock,unregister,updateAccount,updateConfiguration,updateContact,updateGroup,updateProfile,uploadStickerPack,verify,version}
                  ...
signal-cli:  error:  argument   -a/--account/-u/--username:   expected  one
argument
usage: signal-cli [-h] [--version] [-v] [--log-file LOG_FILE] [--scrub-log]
                  [-c CONFIG] [-a ACCOUNT] [-o {plain-text,json}]
                  [--service-environment {live,staging,sandbox}]
                  [--trust-new-identities {always,on-first-use,never}]
                  [--disable-send-log] [--dbus | --dbus-system]
                  {addDevice,addStickerPack,block,daemon,deleteLocalAccountData,finishChangeNumber,getAttachment,getUserStatus,joinGroup,jsonRpc,link,listAccounts,listContacts,listDevices,listGroups,listIdentities,listStickerPacks,quitGroup,receive,register,remoteDelete,removeContact,removeDevice,removePin,send,sendContacts,sendPaymentNotification,sendReaction,sendReceipt,sendSyncRequest,sendTyping,setPin,startChangeNumber,submitRateLimitChallenge,trust,unblock,unregister,updateAccount,updateConfiguration,updateContact,updateGroup,updateProfile,uploadStickerPack,verify,version}
                  ...
signal-cli:  error:  argument   -a/--account/-u/--username:   expected  one
argument

I have the signal-cli-rest-api container linked to my main Signal number and not registered via a separate number.

[joop3]

I am having the exact same issue as akuntsch describes above. Running Signal in normal modes works (although being on a rpi3 being really slow) but when switching to json-rpc I get the same error message (level=error msg="Couldn't read data for number : EOF. Is the number properly registered?")

I tried removing the add-on and registering the dedicated number again but still doesn't work.

[jpk75]

Same on my side. I freshly set up a container within Portainer on my Rpi4 with 64Bit Raspberry Pi OS (Bullseye). And I also linked the instance to an existing signal account number.

In normal and native mode everything works like a charm. In json-rpc mode, I get the same error

time="2023-11-03T16:53:44Z" level=error msg="Couldn't read data for number : EOF. Is the number properly registered?"

May be as a hint for you. Some lines above in my log, there is a weird message from jsonrpc2-helper tool.

+ [ json-rpc = json-rpc ]
+ /usr/bin/jsonrpc2-helper
time="2023-11-03T16:53:39Z" level=info msg="Found number  and added it to jsonrpc2.yml"

It seems it found a number. But the number is empty.

I used the latest image from Dockerhub. But I also tried it with older ones (until 0.65). All with the same behavior.

[bbernhard]

Have you registered a dedicated number or do you use a linked number?

[jpk75]

Have you registered a dedicated number or do you use a linked number?

I linked it

[bbernhard]

Have you registered a dedicated number or do you use a linked number?

I linked it

Okay, I think I've stumbled across that issue while debugging another one a few days ago. Can you please have a look at the config file, which should be located here: signal-cli-config/data/<some random id>. I guess the username is null, right?

[jpk75]

Have you registered a dedicated number or do you use a linked number?

I linked it

Okay, I think I've stumbled across that issue while debugging another one a few days ago. Can you please have a look at the config file, which should be located here: signal-cli-config/data/<some random id>. I guess the username is null, right?

It's an empty string.

{
  "version" : 8,
  "serviceEnvironment" : "LIVE",
  "registered" : true,
  "number" : "+49xxxxxxxxxxxx",
  "username" : "",
...

[bbernhard]

Have you registered a dedicated number or do you use a linked number?

I linked it

Okay, I think I've stumbled across that issue while debugging another one a few days ago. Can you please have a look at the config file, which should be located here: signal-cli-config/data/<some random id>. I guess the username is null, right?

It's an empty string.

{
  "version" : 8,
  "serviceEnvironment" : "LIVE",
  "registered" : true,
  "number" : "+49xxxxxxxxxxxx",
  "username" : "",
...

Ok, in my case it was null, but an empty string also explains the behavior you are seeing. I think signal-cli changed its behavior at some point and now the username is not set anymore for linked numbers. What you could try is to set the username manually - just set it to your number "+49xxxxxxxxxxxx". I haven't tried that yet, but I guess it could work. However, in the worst case, it messes up the config and you have to re-register your device. In any case, this is something that should be fixed in the next release.

[jpk75]

Have you registered a dedicated number or do you use a linked number?

I linked it

Okay, I think I've stumbled across that issue while debugging another one a few days ago. Can you please have a look at the config file, which should be located here: signal-cli-config/data/<some random id>. I guess the username is null, right?

It's an empty string.

{
  "version" : 8,
  "serviceEnvironment" : "LIVE",
  "registered" : true,
  "number" : "+49xxxxxxxxxxxx",
  "username" : "",
...

Ok, in my case it was null, but an empty string also explains the behavior you are seeing. I think signal-cli changed its behavior at some point and now the username is not set anymore for linked numbers. What you could try is to set the username manually - just set it to your number "+49xxxxxxxxxxxx". I haven't tried that yet, but I guess it could work. However, in the worst case, it messes up the config and you have to re-register your device. In any case, this is something that should be fixed in the next release.

That did the trick. I added the phone number to the username. Additionally, I also had to recreate the complete container. to get the helper run. May be there is a smarter way to rerun the script :-)

Thanks a lot for your support. 👍

[joop3]

Have you registered a dedicated number or do you use a linked number?

I linked it

Okay, I think I've stumbled across that issue while debugging another one a few days ago. Can you please have a look at the config file, which should be located here: signal-cli-config/data/<some random id>. I guess the username is null, right?

It's an empty string.

{
  "version" : 8,
  "serviceEnvironment" : "LIVE",
  "registered" : true,
  "number" : "+49xxxxxxxxxxxx",
  "username" : "",
...

Ok, in my case it was null, but an empty string also explains the behavior you are seeing. I think signal-cli changed its behavior at some point and now the username is not set anymore for linked numbers. What you could try is to set the username manually - just set it to your number "+49xxxxxxxxxxxx". I haven't tried that yet, but I guess it could work. However, in the worst case, it messes up the config and you have to re-register your device. In any case, this is something that should be fixed in the next release.

Hi Bernhard,

With manually setting the username, you mean edit it directly in that config file?

I tried to update directly within the container by: signal-cli --config: /data updateProfile --name "namehere". Although the command was accepted, the config file still shows "username" : null

Edit: I just realised I have an older vm with home assistant with the add-on version 0.69, I checked the config file there and I see the username there is set to the phone number. The format also seems bit different compared to the 0.70 version.

Version 0.69:

{
"version" : 7,
"username" : "+phonenumber",
"serviceEnvironment" : "LIVE",
"usernameIdentifier" : null,

Version 0.70:

{
"version" : 8,
"serviceEnvironment" : "LIVE",
"registered" : true,
"number" : "+phonenumber",
"username" : null,

Edit2:
Impatient as I am(...), I manually edited the file and filled in the used phonenumber for the username, and it works again!

To avoid having to edit this every time, can you fix this in the next release maybe?

[bbernhard]

yep, this should be fixed with the next release.