json-rpc mode issues, high CPU about signal-addon

[haberda]

There was a typo in the environment variable. A new version is building that should fix it.

[ThePatricide]

Yeah this is fixed in 0.54.1. See performance below, super!

However, now the CPU usage is extremely high of the add-on, keeps around 92% (I can hear the CPU fan spinning up because of it).

Also, getting some errors in the log that were not there before:

+ set -e
+ [ -z /data ]
+ chown 1000:1000 -R /data
+ cat
+ cap_prefix=-cap_
+ cat /proc/sys/kernel/cap_last_cap
+ seq -s ,-cap_ 0 40
+ 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
+ [ json-rpc = json-rpc ]
+ /usr/bin/jsonrpc2-helper
time="2021-12-29T08:48:44+01:00" level=info msg="Found number +31xxxxxx105 and added it to jsonrpc2.yml"
time="2021-12-29T08:48:44+01:00" level=info msg="Found number +31xxxxxx609 and added it to jsonrpc2.yml"
time="2021-12-29T08:48:44+01:00" level=info msg="Found number +31xxxxxx857 and added it to jsonrpc2.yml"
+ service supervisor start
Starting supervisor: supervisord.
+ supervisorctl start all
+ 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=/data
time="2021-12-29T08:48:45+01:00" level=info msg="Started Signal Messenger REST API"
time="2021-12-29T08:48:51+01:00" level=error msg="Couldn't read data for number +31xxxxxx857: EOF. Is the number properly registered?"
time="2021-12-29T08:48:54+01:00" level=error msg="Couldn't read data for number +31xxxxxx609: EOF. Is the number properly registered?"
[GIN] 2021/12/29 - 08:49:02 | 200 |      27.523µs |    192.168.1.17 | GET      "/v1/about"
[GIN] 2021/12/29 - 08:49:03 | 201 |  373.494318ms |    192.168.1.17 | POST     "/v2/send"
[GIN] 2021/12/29 - 08:49:07 | 200 |      23.847µs |    192.168.1.17 | GET      "/v1/about"
[GIN] 2021/12/29 - 08:49:07 | 201 |  322.839394ms |    192.168.1.17 | POST     "/v2/send"
[GIN] 2021/12/29 - 08:49:10 | 200 |      21.299µs |    192.168.1.17 | GET      "/v1/about"
[GIN] 2021/12/29 - 08:49:10 | 201 |  311.228277ms |    192.168.1.17 | POST     "/v2/send"
[GIN] 2021/12/29 - 08:49:14 | 200 |      22.254µs |    192.168.1.17 | GET      "/v1/about"
[GIN] 2021/12/29 - 08:49:14 | 201 |  286.375859ms |    192.168.1.17 | POST     "/v2/send"
[GIN] 2021/12/29 - 08:49:31 | 200 |      21.305µs |    192.168.1.17 | GET      "/v1/about"
[GIN] 2021/12/29 - 08:49:31 | 201 |  291.176719ms |    192.168.1.17 | POST     "/v2/send"

So for now switching back to Native, would love to test some more.

[haberda]

In terms of the CPU usage, I can't say why that would be. What CPU arch are you using? I only use x86 and it's basically always at 0%.

The errors might mean there is something wrong with the numbers registration. I had that when I first tested rpc because I had a typo in the number I tried to register and I didn't wipe the data before actually registering my number. If those are working numbers, it may be the profile is out of date, I think rpc requires the most up to date profiles. There is a REST API documented upstream for updating the profile. Otherwise, you will have to delete those numbers and register them again.

One thing to note, because you are getting the errors, it might be the cause of high CPU use. I don't change much from the upstream container, all I do is set some environment variables before the service starts (hence the typo problem). Nothing I changed should be impacting CPU use, but I am willing to try to troubleshoot.

[ThePatricide]

Thanks for your elaborate reply. I'm using x86(-64) as well. After reregistering the two numbers that gave the error I put it back to json-rpc. The errors are now gone. CPU usage back to normal. Nodered gives an API error now: untrusted numbers.

So added them as trusted numbers. Now I have to be patient as I get a rate limit error :X.

Other minor thing that now happens when the addon starts: the supervisor shows a warning:

21-12-30 09:01:13 WARNING (MainThread) [supervisor.addons.options] Option 'native_mode' does not exist in the schema for Signal Messenger (1315902c_signal_messenger)

[haberda]

That warning is because the old way of setting native mode was a binary environment variable. The upstream container no longer supports it; however the way that add-ons store the options it persists in the options file. You can either manually remove the native_mode option from the options.json file in the /data folder of the add-on; or under the add-on configuration I think if you use the 'revert to default' it will replace the file with the default settings. So you can revert to default, choose your preferred mode, and start again. Reverting to default will not delete your number registrations.

[ThePatricide]

The reset did the trick: it solved the CPU usage issue and errors. Then reregistered, created a new group, trusted the numbers and THEN switch it to JSON_RPC (in that mode the methods for registering are not supported). All works perfect now! Thanks a lot for the support!