running as a daemon dbus-system working setup

[ebonit]

Ubuntu 24.04 server.

when I call signal-cli in a cronjob on my server it waits for input after sending the command. As a result my cronjob is not finishing. So I want to run it as a headless service, which would solve the problem.

I followed the documentation at https://github.com/AsamK/signal-cli/wiki/DBus-service#send-using-dbus-send. With that I could not get it to work.

so I had to hack it a little and here is my working setup:

first of all I created a user signal-cli and with that user I went to the link device routine
sudo useradd -r -m signal-cli
sudo -u signal-cli signal-cli link

with the sgnl:// link i did
qrencode -t UTF8 "sgnl://linkdevice?..." this generates the QR-code that you use to link your user to your account in signal on you phone
this will generate your data directory in /home/signal-cli/.local/share.signal-cli

---

/usr/share/dbus-1/system-services/org.asamk.Signal.service

[D-BUS Service]
Name=org.asamk.Signal
Exec=/bin/false
SystemdService=signal-cli.service

Note that I changed the SystemdService from dbus-org.asamk.Signal.service to signal-cli.service

---

/etc/systemd/system/signal-cli.service

[Unit]
Description=Signal-cli DBus daemon
#Description=Send secure messages to Signal clients
#Requires=dbus.socket
#After=dbus.socket
#Wants=network-online.target
#After=network-online.target

[Service]
#Type=dbus
#Environment="SIGNAL_CLI_OPTS=-Xms2m"
ExecStart=/usr/local/bin/signal-cli daemon --dbus-system
User=signal-cli
#BusName=org.asamk.Signal

#[Install]
#Alias=dbus-org.asamk.Signal.service

as you see I commented most of it since it is not started manually. DBus will activate it. it will generate some warning when dbus is reloaded but that is expected.

---

/etc/dbus-1/system.d/org.asamk.Signal.conf

<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

<busconfig>

<!-- Allow the daemon user to own the service -->
<policy user="signal-cli">
<allow own="org.asamk.Signal"/>
</policy>

<!-- Allow any local user (including root, cron, scripts) to send -->
<policy context="default">
<allow send_destination="org.asamk.Signal"/>
<allow send_interface="org.asamk.Signal"/>
<allow send_interface="org.asamk.SignalControl"/>
</policy>
</busconfig

---

Reload systemd and DBus
systemctl disable --now signal-cli THIS IS IMPORTANT!! if you have tried running signal-cli as a service before
sudo systemctl daemon-reload
sudo systemctl reload dbus //with reloading dbus it now starts up signal-cli as a service

this will generate the following warning but it is expected and okay

The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.

---

Test DBus activation

signal-cli --dbus-system send -m "Hello from DBus system activation" +31<phonenumber>

test if signal-cli is activated
systemctl status signal-cli

see all identities
signal-cli --dbus-system listIdentities

---

Summary

• Dedicated user: signal-cli
• Data stored in /home/signal-cli/.local/share/signal-cli
• DBus system bus used (--dbus-system)
• DBus policy allows ownership and client access
• systemd service is DBus-activated, no manual start
• Cron jobs and CLI calls use --dbus-system safely