search

isamert / scli

a simple terminal user interface for signal messenger (using signal-cli)
GNU General Public License v3.0
432 stars 40 forks source link

scli fails to initialize daemon and won't send messages #195

Closed scottwn closed 1 year ago

scottwn commented 2 years ago

Signal-cli is working for me while specifying the session bus. Running this command succeeds.

signal-cli --verbose --log-file ./.local/share/signal-cli/log -u +13478139851 --output=json daemon --socket $DBUS_SESSION_BUS_ADDRESS

Logs show successful operation.

2022-06-04T15:24:55.825-0400 [receive-0] INFO  LibSignal - [WebSocketConnection]: [unidentified:200800912] connect()
2022-06-04T15:24:55.828-0400 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Handling message actions
2022-06-04T15:24:55.851-0400 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Checking for new message from server
2022-06-04T15:24:55.925-0400 [OkHttp https://chat.signal.org/...] INFO  LibSignal - [WebSocketConnection]: [unidentified:200800912] onOpen() connected
2022-06-04T15:24:55.925-0400 [OkHttp https://chat.signal.org/...] INFO  LibSignal - [WebSocketConnection]: [normal:1878046167] onOpen() connected
2022-06-04T15:24:55.925-0400 [RxComputationThreadPool-5] DEBUG o.a.s.m.SignalWebSocketHealthMonitor - WebSocket is now connected
2022-06-04T15:24:55.925-0400 [RxComputationThreadPool-4] DEBUG o.a.s.m.SignalWebSocketHealthMonitor - WebSocket is now connected
2022-06-04T15:24:55.952-0400 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Received indicator that server queue is empty
2022-06-04T15:24:55.953-0400 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Handling message actions
2022-06-04T15:24:55.953-0400 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Checking for new message from server
2022-06-04T15:25:50.930-0400 [Thread-2] INFO  LibSignal - [WebSocketConnection]: [normal:1878046167] Sending keep alive...
2022-06-04T15:25:50.933-0400 [Thread-2] INFO  LibSignal - [WebSocketConnection]: [unidentified:200800912] Sending keep alive...
2022-06-04T15:25:55.979-0400 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Checking for new message from server

However, scli hangs on "initializing daemon" when I pass the daemon command to scli, like this:

scli --debug --daemon-command 'signal-cli -u %u --output=json daemon --socket $DBUS_SESSION_BUS_ADDRESS'

Logs show a NullPointerException coming from signal-cli, despite confirmation that the daemon command is correct.

INFO:root:scli 0.7.1-3-g6ad260c
DEBUG:root:signal-cli account: linked device
DEBUG:root:callf: `['signal-cli', '-u', '+13478139851', '--output=json', 'daemon', '--socket', '$DBUS_SESSION_BUS_ADDRESS']`
INFO:root:daemon_log: INFO  DaemonCommand - Starting daemon in single-account mode for +13478139851
INFO:root:daemon_log: java.lang.NullPointerException: Cannot invoke "java.io.File.exists()" because "file" is null
INFO:root:daemon_log: at org.asamk.signal.util.IOUtils.createPrivateDirectories(IOUtils.java:58)
    at org.asamk.signal.util.IOUtils.preBind(IOUtils.java:151)
    at org.asamk.signal.util.IOUtils.bindSocket(IOUtils.java:136)
    at org.asamk.signal.commands.DaemonCommand.handleCommand(DaemonCommand.java:118)
    at org.asamk.signal.App.handleLocalCommand(App.java:273)
    at org.asamk.signal.App.init(App.java:213)
    at org.asamk.signal.Main.main(Main.java:58)
scottwn commented 2 years ago

The NullPointerException was caused by bad variable expansion. Expanding the variable correctly clears the exception.

scli --debug --daemon-command "signal-cli --verbose --log-file ./.local/share/signal-cli/log -u +13478139851 --output=json daemon --socket $DBUS_SESSION_BUS_ADDRESS"

starts scli without errors, but it still hangs on initializing daemon.

INFO:root:scli 0.7.1-3-g6ad260c
DEBUG:root:signal-cli account: linked device
DEBUG:root:callf: `['signal-cli', '--verbose', '--log-file', './.local/share/signal-cli/log', '-u', '+13478139851', '--output=json', 'daemon', '--socket', 'unix:path=/private/tmp/com.apple.launchd.Hb4fTbtmzP/unix_domain_listener']`
INFO:root:daemon_log: INFO  DaemonCommand - Starting daemon in single-account mode for +13478139851
INFO:root:daemon_log: INFO  IOUtils - Listening on socket: unix:path=/private/tmp/com.apple.launchd.Hb4fTbtmzP/unix_domain_listener

However, when I try to send a message, the dbus-send command fails.

ERROR:root:proc: cmd:`dbus-send --session --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal org.asamk.Signal.sendMessage 'string:this is a test messagte' array:string: string:+15085969529 1>&2; echo $$ $?`; return_code:1; output:"Failed to open connection to "session" message bus: Failed to connect to socket /private/tmp/com.apple.launchd.Hb4fTbtmzP/unix_domain_listener: Connection refused"
scottwn commented 2 years ago

After resetting the dbus address environment variables, I'm not getting connection refused anymore. Now I'm seeing ServiceUnknown.

ERROR:root:proc: cmd:`dbus-send --session --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal org.asamk.Signal.sendMessage 'string:this is a test message' array:string: string:+15085969529 1>&2; echo $$ $?`; return_code:1; output:"Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.asamk.Signal was not provided by any .service files"
exquo commented 2 years ago

The daemon-command needs to be changed. The --socket argument specifies signal-cli's daemon with a JSON-RPC interface listening on a Unix socket. Scli, on the other hand, uses a DBus interface. When signal-cli daemon is started without a dbus interface, the dbus-send returns the ServiceUknown error when it attempts to connect to that non-existent service.

You can use --dbus argument to signal-cli's daemon (or leave it out, since it's the default). There might be some complications with getting DBus to work correctly on macOS. See https://github.com/AsamK/signal-cli/wiki/DBus-service#macos. If troubleshooting is needed, you can leave scli out of the loop: you just need to make sure that the signal-cli daemon ... and dbus-send ... commands work correctly.

scottwn commented 2 years ago

When I run signal-cli --verbose --log-file ./.local/share/signal-cli/log -u +13478139851 --output=json daemon --dbus I get Connection refused.

Dbus command failed: Failed to connect to bus: Connection refused
org.freedesktop.dbus.exceptions.DBusException: Failed to connect to bus: Connection refused
    at org.freedesktop.dbus.connections.AbstractConnection.<init>(AbstractConnection.java:150)
    at org.freedesktop.dbus.connections.impl.DBusConnection.<init>(DBusConnection.java:228)
    at org.freedesktop.dbus.connections.impl.DBusConnectionBuilder.build(DBusConnectionBuilder.java:265)
    at org.asamk.signal.commands.DaemonCommand.runDbus(DaemonCommand.java:353)
    at org.asamk.signal.commands.DaemonCommand.runDbusSingleAccount(DaemonCommand.java:295)
    at org.asamk.signal.commands.DaemonCommand.handleCommand(DaemonCommand.java:138)
    at org.asamk.signal.App.handleLocalCommand(App.java:273)
    at org.asamk.signal.App.init(App.java:213)
    at org.asamk.signal.Main.main(Main.java:58)
Caused by: java.net.ConnectException: Connection refused
    at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)
    at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:148)
    at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:144)
    at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:851)
    at java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:285)
    at org.freedesktop.dbus.transport.jre.NativeUnixSocketTransport.connectImpl(NativeUnixSocketTransport.java:70)
    at org.freedesktop.dbus.connections.transports.AbstractTransport.connect(AbstractTransport.java:126)
    at org.freedesktop.dbus.connections.transports.TransportBuilder.build(TransportBuilder.java:351)
    at org.freedesktop.dbus.connections.AbstractConnection.<init>(AbstractConnection.java:144)
    ... 8 more

The logs have a little more information.

java.net.ConnectException: Connection refused
    at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)
    at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:148)
    at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:144)
    at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:851)
    at java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:285)
    at org.freedesktop.dbus.transport.jre.NativeUnixSocketTransport.connectImpl(NativeUnixSocketTransport.java:70)
    at org.freedesktop.dbus.connections.transports.AbstractTransport.connect(AbstractTransport.java:126)
    at org.freedesktop.dbus.connections.transports.TransportBuilder.build(TransportBuilder.java:351)
    at org.freedesktop.dbus.connections.AbstractConnection.<init>(AbstractConnection.java:144)
    at org.freedesktop.dbus.connections.impl.DBusConnection.<init>(DBusConnection.java:228)
    at org.freedesktop.dbus.connections.impl.DBusConnectionBuilder.build(DBusConnectionBuilder.java:265)
    at org.asamk.signal.commands.DaemonCommand.runDbus(DaemonCommand.java:353)
    at org.asamk.signal.commands.DaemonCommand.runDbusSingleAccount(DaemonCommand.java:295)
    at org.asamk.signal.commands.DaemonCommand.handleCommand(DaemonCommand.java:138)
    at org.asamk.signal.App.handleLocalCommand(App.java:273)
    at org.asamk.signal.App.init(App.java:213)
    at org.asamk.signal.Main.main(Main.java:58)

Running daemon --socket still works without error, but dbus-send fails.

I've read the MacOS DBus guide on the WIKI and have the environment variables set correctly.

~ $ printenv DBUS_LAUNCHD_SESSION_BUS_SOCKET
/private/tmp/com.apple.launchd.MY5mOAWaVK/unix_domain_listener
~ $ printenv DBUS_SESSION_BUS_ADDRESS
unix:path=/private/tmp/com.apple.launchd.MY5mOAWaVK/unix_domain_listener
exquo commented 2 years ago

That's an issue with DBus on macOS then. I see back here you did get signal-cli daemon to run. So some prior setup (combination of environment variables, etc) should succeed. Unfortunately I don't have a mac to reproduce this on. It must be doable though, since there certainly are signal-cli users on macOS (cold comfort, I know..).

Dax911 commented 1 year ago

I can unfortunately confirm this issue verbatim on the new M2 Air.

I seem to have no problems on my Arch though, so thank you for the fun tool and your hard work.

scottwn commented 1 year ago

I did finally get this to work. The issue is definitely with DBUS_SESSION_BUS_ADDRESS. What I found is that the value must be empty before you start dbus. If you set it yourself, or if it's already set by the OS, it will break.

This works for me on fish, I would expect something similar to work on zsh or bash.

# Unset environment variables

set -e DBUS_SESSION_BUS_ADDRESS
set -e DBUS_LAUNCHD_SESSION_BUS_SOCKET

# Restart dbus

brew services restart dbus

# Test dbus-send

dbus-send --session --type=method_call --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

# Test signal-cli (where $SIGNAL_USER is your Signal number)

signal-cli -u $SIGNAL_USER daemon --dbus

# Run scli

scli
exquo commented 1 year ago

Thanks @scottwn! Hopefully this should help others coming across this issue.