Thank you. I know have a deeper understanding of the this topic :)
Regards. Chiba 2017年11月28日(火) 23:32 Lennart Poettering <[email protected]>: > f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 ([email protected]) 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株式会社 インフラマネジメント部 千葉 幹正 [email protected] [東京本社] 〒106-6122 東京都港区六本木6-10-1 六本木ヒルズ森タワー22F TEL：03-5771-1818 / FAX：03-3403-8520 [地方・海外拠点] 仙台/大阪/福岡/シンガポール/上海 [弊社HP] http://www.klab.com/jp/
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
