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

[千葉幹正]

Thank you.

I know have a deeper understanding of the this topic :)

Regards.
Chiba

2017年11月28日(火) 23:32 Lennart Poettering <lennart at poettering.net>:

> 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
>
-- 
KLab株式会社 インフラマネジメント部
千葉 幹正 chiba-k at klab.com

 [東京本社]
  〒106-6122 東京都港区六本木6-10-1 六本木ヒルズ森タワー22F
  TEL：03-5771-1818  / FAX：03-3403-8520
 [地方・海外拠点]
仙台/大阪/福岡/シンガポール/上海
 [弊社HP]
  http://www.klab.com/jp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20171128/b3192302/attachment-0001.html>