FAQ

Performance

JVM startup

Every invocation of signal-cli ... starts a Java Virtual Machine instance. This can take anywhere from a second to a long time, depending on the system.

To avoid it, signal-cli can be started as a daemon, with subsequent commands sent to it through DBus. See using dbus-send.

There is a also an experimental native library build using GraalVM that avoids JVM startup. See GraalVM section in README.

System entropy

Some signal-cli's operations require that enough system entropy / randomness is available.

Available entropy can be monitored with

watch cat /proc/sys/kernel/random/entropy_avail

If it is hitting zero during signal-cli ... execution, signal-cli will block until enough entropy is available.

System entropy is more likely to get depleted on headless servers. There are programs that allow to increase the amount of available entropy, e.g. haveged.

See also

#351 with links to past discussions.

Error parsing arguments

The signal-cli program has a set of options, and each subcommand may have its own options. The correct order is:

signal-cli [SIGNAL-CLI_OPTIONS] [SUBCOMMAND] [SUBCOMMAND_OPTIONS]

So, for example:

$ signal-cli receive --output=json
signal-cli: error: unrecognized arguments: '--output=json'

The --output=... option belongs to the main program, and needs to be in front of the receive subcommand:

$ signal-cli --output=json receive 

This is Argparse4j's behavior.

DBus errors when starting daemon

See Troubleshooting DBus.