using dbus to talk to systemd from inside a confined snap won’t work. What you should be doing instead is snapctl stop --disable the-service (analogous to what you do “outside” the snap, snap stop --disable the-snap.the-service.
Hey @prasath, where did you find such an interface? Here is a list of all the supported interfaces, dbus-systemd is not one of them… You may be able to use the dbus interface with the appropriate attributes, though.
Our intention is to enable/disable the ssh service.
As we seen, its controlled by systemd with the service name sshd.service, we have tried by below methods, but none of the worked for me.
Using systemctl stop/start sshd.service (We have integrated systemctl into the snap).
Using start-stop-daemon --start --quiet --oknodo --pidfile /var/run/sshd.pid --exec $SNAP/bin/sshd (In this we have integrated the start-stop-daemon and sshd into the snap, but running sshd results in various errors like chmod, setgroups, etc,… Need permissions to access them.
Using direct $SNAP/etc/init.d/ssh start, results in same failure cases as mentioned in method 2.
DBUS: As mentioned in my previous post.
Also the dbus interface supported by snap has no slot for communicating with systemd dbus api’s.
@chipaca, the suggestion which you have mentioned works for a non-snappy service? Because ssh is not controlled by snap and its shipped with the OS and running as a separate systemd service as mentioned earlier.
On core devices you can run snap set system service.ssh.disable=true to disable sshd (and similarly for rsyslog); it’s considered part of the system’s configuration (and you can default it to disabled via the gadget iirc). You can’t run snap from inside a snap, so you can’t do that, but the snapd-control interface lets you talk to the /run/snapd.socket socket, so you can use the API.