scli fails to initialize daemon and won't send messages
scottwn opened this issue · comments
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)
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"
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"
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.
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
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..).
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.
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