Closed NK308 closed 1 year ago
I've seen this before, but it seems to have fixed itself on my system.. The issue is "lower" than scli's level: it might be the signal-cli's dbus daemon not waking up after a suspend.
To reproduce / troubleshoot, try running signal-cli daemon in verbose mode (while scli is not running):
signal-cli -u +1234567890 --output=json --verbose daemon
Wait for it to start up and receive messages, then suspend the computer (it might have to stay suspended for longer than a certain amount of time for this issue to occur). After waking up, issue some commands to the daemon through dbus-send
, like documented on signal-cli's wiki, e.g.:
dbus-send --session --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.sendMessage string:'some test message' array:string: string:+123RECIPIENT890
I'm gonna check this the next time, I'm connected to the wifi of my university, which wil be next week.
If the problem still occurs, feel free to reopen.
Now, when I'm no longer studying completely remote from home, I realized, that scli seemingly doesn't handle the connection loss after suspending my laptop for a few minutes, very well. In fact I have to restart scli after awakening my device from suspension after moving from one room to another. I'm still in the same wifi network, so it doesn't only happen, when I'm actually switching the network.
Being able to handle this kind of interrupt would be a critical feature for a program, which is intended to stay open in the background for a long time.