[systemd-devel] [Question]: About systemctl and its related commands

[Lennart Poettering]

f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chiba-k at klab.com) wrote:

> We have a few questions about systemctl and -H option.
> 
> It looks like systemctl is communicating with /run/systemd/private in order
> to interact with systemd.
> 
> However, after you log in the connected computer via ssh, it looks like
> it's trying to control systemd by going through systemd-stdio-bridge when
> you use systemctl's -H option.
> 
> Instead of going through /run/systemd/private, it looks like
> systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is
> usually created by dbus daemon) in order to control systemd.
> 
> This where we run into the following 2 questions:
> 
> 1. Is it necessary to start up dbus daemon on the computer we're connecting
> to in order to control systemd by using the systemctl -H option?

Currently, yes. And I doubt this will change anytime soon.

D-Bus is designed around a bus concept: all services are available on
the same IPC bus. That's usually a good thing, as that means systemctl
can talk to all services it needs to through a single IPC
connection. systemctl talks to a number of daemons actually, not just
PID 1: for example, it also talks to logind and policykit.

If the private IPC socket is used a very limited way of IPC is
available only: since the other side is PID 1 and PID 1 only, there's
no hookup with polkit, and communication with logind is not
available. Moreover a couple of peer tracking concepts in PID 1 are
disabled for such "direct" connections, as a peer concept is not
really existing for such connections that do not involve a bus.

systemctl currently contains some logic to use the private socket
(i.e. a direct connection) automatically in a number of cases,
preferring it over the bus. It does that so that systemctl can talk to
systemd during early boot too (when dbus-daemon is not up yet, hence
the proper bus is not available), as well as when the system is really
hosed (so that you can still debug things and shut things down). The
direct connections however are a very specific hack in systemctl
ultimately, done under very specific conditions, in order to deal with
a very specific set of problems. When PK or logind involvement is
needed, when the caller is not privileged and so on, the direct
connections are not used. Now, the ssh transport (i.e. -H) doesn't
know about all this, and cannot possibly guess what systemctl actually
wants to do, hence it is exclusively a gateway to the full bus, it
contains no special hookup with the private socket. Moreover, ssh is
a late boot service anyway, i.e. dbus is already up at that moment,
hence the early-boot reason for the private socket doesn't even apply
to remote connections at all..

> 2. Are we correct in our understanding that /run/systemd/private exists to
> control systemctl though the local systemd?

the private socket is an implementation detail between systemctl and
systemd, to support the aforementioned usecases. It's not a public
API (which is the reason btw, why it is called 'private'…), it's not
fully featured, and it should not be used except under very well
defined conditions, and remote access does not fall under that.

> Why does systemctl use the specialized interface called
> /run/systemd/private to control systemd?
> Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> like systemctl does?

Besides the fact that systemctl talks to logind and so on, the stdio
bridge is also used by the various other tools in systemd, including
machinectl, loginctl, busctl, systemd-run, … Since they generally talk
to other daemons than just PID 1 a full ybus connection is required.

Lennart

-- 
Lennart Poettering, Red Hat