Discussion:
[Question]: About systemctl and its related commands
(too old to reply)
千葉幹正
2017-11-28 07:16:30 UTC
Permalink
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?

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

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?

Any information you can provide about the above would be much appreciated!
Thanks in advance for your time and all your help.

All the best,

Chiba
KLab Inc.
aleivag
2017-11-28 08:31:35 UTC
Permalink
Hi, i asked similar question a few weeks ago, and you probably will get a
oficial answer soon :P, but in a nutshell would be:

/run/systemd/private is a private socket and its meant for systemd tools to
communicate with systemd even if dbus daemon is down. this is specially
true during boot and shutdown, but you should never try to use the private
sockets for anything, always use dbus sockets, because (in Lennard's words,
not mine) "systemd sucks as a bus replacement". if posible, even forget
that /run/systemd/private exists :P.

after playing around a lot with servers i agree with previous statements,
and always prefere dbus over private.

hope that helps.


Alvaro
Post by 千葉幹正
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.
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?
2. Are we correct in our understanding that /run/systemd/private exists to
control systemctl though the local systemd?
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?
Any information you can provide about the above would be much appreciated!
Thanks in advance for your time and all your help.
All the best,
Chiba
KLab Inc.
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering
2017-11-28 14:32:45 UTC
Permalink
Post by 千葉幹正
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.
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..
Post by 千葉幹正
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.
Post by 千葉幹正
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
千葉幹正
2017-11-28 16:42:31 UTC
Permalink
Thank you.

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

Regards.
Chiba
Post by 千葉幹正
Post by 千葉幹正
We have a few questions about systemctl and -H option.
It looks like systemctl is communicating with /run/systemd/private in
order
Post by 千葉幹正
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
Post by 千葉幹正
usually created by dbus daemon) in order to control systemd.
1. Is it necessary to start up dbus daemon on the computer we're
connecting
Post by 千葉幹正
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..
Post by 千葉幹正
2. Are we correct in our understanding that /run/systemd/private exists
to
Post by 千葉幹正
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.
Post by 千葉幹正
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-***@klab.com

[東京本瀟]
〒106-6122 東京郜枯区六本朚6-10-1 六本朚ヒルズ森タワヌ22F
TEL03-5771-1818 / FAX03-3403-8520
[地方・海倖拠点]
仙台/倧阪/犏岡/シンガポヌル/䞊海
[匊瀟HP]
http://www.klab.com/jp/
Loading...