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

scottwn · 2022-06-04T19:35:58Z

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 text was updated successfully, but these errors were encountered:

scottwn · 2022-06-04T19:44:23Z

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 · 2022-06-04T19:54:21Z

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 · 2022-06-12T19:43:02Z

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 · 2022-06-13T18:51:16Z

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 · 2022-06-14T10:55:15Z

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 · 2022-08-12T20:19:18Z

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 · 2022-08-18T16:03:54Z

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 · 2022-08-28T20:44:55Z

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

scottwn mentioned this issue Jun 4, 2022

Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.asamk.Signal was not provided by any .service files AsamK/signal-cli#967

Closed

exquo closed this as completed Aug 28, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

scottwn commented Jun 4, 2022

scottwn commented Jun 4, 2022

scottwn commented Jun 4, 2022

exquo commented Jun 12, 2022

scottwn commented Jun 13, 2022

exquo commented Jun 14, 2022

Dax911 commented Aug 12, 2022 •

edited

Loading

scottwn commented Aug 18, 2022

exquo commented Aug 28, 2022

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

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

Comments

scottwn commented Jun 4, 2022

scottwn commented Jun 4, 2022

scottwn commented Jun 4, 2022

exquo commented Jun 12, 2022

scottwn commented Jun 13, 2022

exquo commented Jun 14, 2022

Dax911 commented Aug 12, 2022 • edited Loading

scottwn commented Aug 18, 2022

exquo commented Aug 28, 2022

Dax911 commented Aug 12, 2022 •

edited

Loading