<div><div dir="auto">Thank you.</div></div><div dir="auto"><br></div><div dir="auto">I know have a deeper understanding of the this topic :)</div><div dir="auto"><br></div><div><div dir="auto">Regards.</div><div dir="auto">Chiba</div><br><div class="gmail_quote"><div>2017年11月28日(火) 23:32 Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (<a href="mailto:chiba-k@klab.com" target="_blank">chiba-k@klab.com</a>) wrote:<br>
<br>
> We have a few questions about systemctl and -H option.<br>
><br>
> It looks like systemctl is communicating with /run/systemd/private in order<br>
> to interact with systemd.<br>
><br>
> However, after you log in the connected computer via ssh, it looks like<br>
> it's trying to control systemd by going through systemd-stdio-bridge when<br>
> you use systemctl's -H option.<br>
><br>
> Instead of going through /run/systemd/private, it looks like<br>
> systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is<br>
> usually created by dbus daemon) in order to control systemd.<br>
><br>
> This where we run into the following 2 questions:<br>
><br>
> 1. Is it necessary to start up dbus daemon on the computer we're connecting<br>
> to in order to control systemd by using the systemctl -H option?<br>
<br>
Currently, yes. And I doubt this will change anytime soon.<br>
<br>
D-Bus is designed around a bus concept: all services are available on<br>
the same IPC bus. That's usually a good thing, as that means systemctl<br>
can talk to all services it needs to through a single IPC<br>
connection. systemctl talks to a number of daemons actually, not just<br>
PID 1: for example, it also talks to logind and policykit.<br>
<br>
If the private IPC socket is used a very limited way of IPC is<br>
available only: since the other side is PID 1 and PID 1 only, there's<br>
no hookup with polkit, and communication with logind is not<br>
available. Moreover a couple of peer tracking concepts in PID 1 are<br>
disabled for such "direct" connections, as a peer concept is not<br>
really existing for such connections that do not involve a bus.<br>
<br>
systemctl currently contains some logic to use the private socket<br>
(i.e. a direct connection) automatically in a number of cases,<br>
preferring it over the bus. It does that so that systemctl can talk to<br>
systemd during early boot too (when dbus-daemon is not up yet, hence<br>
the proper bus is not available), as well as when the system is really<br>
hosed (so that you can still debug things and shut things down). The<br>
direct connections however are a very specific hack in systemctl<br>
ultimately, done under very specific conditions, in order to deal with<br>
a very specific set of problems. When PK or logind involvement is<br>
needed, when the caller is not privileged and so on, the direct<br>
connections are not used. Now, the ssh transport (i.e. -H) doesn't<br>
know about all this, and cannot possibly guess what systemctl actually<br>
wants to do, hence it is exclusively a gateway to the full bus, it<br>
contains no special hookup with the private socket. Moreover, ssh is<br>
a late boot service anyway, i.e. dbus is already up at that moment,<br>
hence the early-boot reason for the private socket doesn't even apply<br>
to remote connections at all..<br>
<br>
> 2. Are we correct in our understanding that /run/systemd/private exists to<br>
> control systemctl though the local systemd?<br>
<br>
the private socket is an implementation detail between systemctl and<br>
systemd, to support the aforementioned usecases. It's not a public<br>
API (which is the reason btw, why it is called 'private'…), it's not<br>
fully featured, and it should not be used except under very well<br>
defined conditions, and remote access does not fall under that.<br>
<br>
> Why does systemctl use the specialized interface called<br>
> /run/systemd/private to control systemd?<br>
> Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private<br>
> like systemctl does?<br>
<br>
Besides the fact that systemctl talks to logind and so on, the stdio<br>
bridge is also used by the various other tools in systemd, including<br>
machinectl, loginctl, busctl, systemd-run, … Since they generally talk<br>
to other daemons than just PID 1 a full ybus connection is required.<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>KLab株式会社 インフラマネジメント部</div><div>千葉 幹正 <a href="mailto:chiba-k@klab.com" target="_blank">chiba-k@klab.com</a></div><div><br></div><div> [東京本社]</div><div>  〒106-6122 東京都港区六本木6-10-1 六本木ヒルズ森タワー22F</div><div>  TEL：03-5771-1818  / FAX：03-3403-8520</div><div> [地方・海外拠点]</div><div>　仙台/大阪/福岡/シンガポール/上海</div><div> [弊社HP]</div><div>  <a href="http://www.klab.com/jp/" target="_blank">http://www.klab.com/jp/</a></div></div></div></div></div></div></div>