Re: [systemd-devel] proper use of /run/{user/, }/systemd/private sockets

[aleivag]

>
>
> Don't connect directly to it. Use the official bus instead. Forget
> that you know about the private connection at all...
>
> Lennart
>
>
got it, "this aren't the sockets you're looking for" :), will use then
propper `sd_bus_open_*`

Thanks Guys!
Alvaro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] proper use of /run/{user/, }/systemd/private sockets

[Lennart Poettering]

On Mo, 13.11.17 19:26, aleivag (alei...@gmail.com) wrote:

> Hi all:
> 
> hope you guys are doing great!. So i have a few questions, hope this is the
> best place for them.
> 
> I've been doing a lot of work with `sd-bus.h` (basically i've been trying
> to bind it to other languages to then interact with systemd natively).
> 
> I've been reading the man pages/blog post/general docs, but mostly the src
> code. and i stumble across
> https://github.com/systemd/systemd/blob/master/src/shared/bus-util.c#L598-L605
> and saw that you can connect to systemd using the sockets, for root would
> be `/run/systemd/private`, and for users something like
> `/run/user//systemd/private` and this trigger lots of questions, that
> i have not been able to answer, so here they are:

Note that these sockets aren't really the official way to talk to
systemd, they are called "private" for the reason that they, well, are
"private" to systemd...

> Question 1)
> 
> what would be the advantage of connecting through dbus instead of directly
> through the socket?

They are available unconditionally as long as systemd is running, from
earliest boot to final shutdown. They are available in emergency mode,
and normal boot and really always. This is different for dbus-daemon,
which is available only during later boot, and is likely to be missing
in emergency mode, the initrd, and during shutdown.

Since systemd must take client requests at any time we thus bind to
this socket, and systemctl has some code to optionally connect to
that.

> 
> the way i connect to systemd is with `sd_bus_open_system` but i can also do
> 
> ```
> sd_bus_new();
> sd_bus_set_address(bus, "unix:path=/run/systemd/private");
> sd_bus_start(bus);
> ```
> 
> why (or when) would one be better than the other?

Generally the bus is the official way, and the private socket is only
for systemctl and very few other cases which must be able to deal with
dbus-daemon, i.e. the official bus being absent.

Note that the private socket is accessible to root only.

> question 2);
> 
> i also look that you can do the same with the user connections (and this is
> mostly true when the --user flag is given, at least on systemd-run), and
> you can connect to something like `/run/user//systemd/private`, where
> `/run/user/` is $XDG_RUNTIME_DIR, and i guess this is really the best
> form to connect to systemd as a user, but is there any difference between
> using that socket or doing `sd_bus_open_user`. ?

systemd sucks as a bus replacement. Use the proper bus, and leave the
private sockets be, please. Unless you have a very good reason to
prefer the private socket: it's not for normal users. 

> question 3)
> 
> systemd source code is pretty clear, really easy to learn from, also
> sd-bus.h is incredible helpful and easy to use.
> 
> But the docs is good, don't get me wrong, but it could definitely use more
> love. for instance the usage of the sockets
> `/run/{user/uid,}/systemd/private`, is not documented anywhere that i could
> find. is this intentional?,

Yes, it is intentional. The name "private" is also intentional: it's a
private, internal API of systemd, and should not be considered
something people should use outside of very specific environments.

> is this because this is a implementation detail
> that may change in the future?. if so, what would be the correct way to
> connect to systemd's socket?

Don't connect directly to it. Use the official bus instead. Forget
that you know about the private connection at all...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] proper use of /run/{user/, }/systemd/private sockets

[Simon McVittie]

On Tue, 14 Nov 2017 at 09:19:08 +0100, Jérémy Rosen wrote:
> That being said, the system socket location is hardcoded not just in systemd,
> but in the dbus specification itself.

The D-Bus Specification does not say anything about the
.../systemd/private sockets. That would be inappropriate: those sockets
are private (not API), and are part of systemd (not D-Bus).

The socket path that is hard-coded in the D-Bus specification is the
well-known system bus socket, /var/run/dbus/system_bus_socket, used by
`dbus-daemon --system` and all D-Bus client implementations (dbus, GDBus,
sd-bus and others). This is present in the D-Bus Specification because
every D-Bus implementation needs to agree on it: otherwise they cannot
interoperate.

If you have dbus-daemon installed and available, then you can
communicate with the system instance of systemd (pid 1) via the D-Bus
system bus. This is a public API that offers the same functionality as
/run/systemd/private, except that it does not work without the system
dbus-daemon.

Similarly, if you have dbus-daemon installed and available and dbus was
configured with the --enable-user-session option (or on Debian derivatives
and similar, if the dbus-user-session package is installed), then you
can communicate with the per-user instance of systemd (systemd --user)
via the D-Bus session bus (which is a "user bus" in this configuration),
$XDG_RUNTIME_DIR/bus. This is a public API that offers the same
functionality as $XDG_RUNTIME_DIR/systemd/private, except that it does
not work without the per-user dbus-daemon.

(Or strictly speaking, you don't *need* dbus-daemon; you could be using
a compatible reimplementation instead.)

Regards,
smcv
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to disable systemd multiseat feature?

[Reindl Harald]

Am 14.11.2017 um 05:26 schrieb Farhad Mohammadi Majd:

Thanks for answer Mr. Lennart, I thought GDM is always active due to
systemd, because in Wikipedia it is written in GNOME article that:

"Since GNOME 3.2 multiseat support has been only available on systems
using systemd."

so I thought it is related to systemd


yes gnome is using logind - your understanding of cause and effect is 
inverted

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to disable systemd multiseat feature?

[Floris]

Op Tue, 14 Nov 2017 05:26:29 +0100 schreef Farhad Mohammadi Majd  
:



Thanks for answer Mr. Lennart, I thought GDM is always active due to
systemd, because in Wikipedia it is written in GNOME article that:

"Since GNOME 3.2 multiseat support has been only available on systems
using systemd."

so I thought it is related to systemd, I don't want disable graphical
login, I just want when someone do login with GDM, it (GDM) becomes
idle.


I think* GDM is still active, because of fast-user-switching. Linux is a  
multi-user OS and so it is possible to work with different users  
simultaneous on the same machine. GDM just wait till an other user login,  
which in your case will never happen.


Maybe you can disable the fast-user-switch feature? But I'm not sure if  
this stops GDM from running.


Floris

*) Correct me if I'm wrong
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] proper use of /run/{user/, }/systemd/private sockets

[Jérémy Rosen]

On 14/11/2017 04:26, aleivag wrote:

Hi all:

hope you guys are doing great!. So i have a few questions, hope this 
is the best place for them.


I've been doing a lot of work with `sd-bus.h` (basically i've been 
trying to bind it to other languages to then interact with systemd 
natively).


I've been reading the man pages/blog post/general docs, but mostly the 
src code. and i stumble across 
https://github.com/systemd/systemd/blob/master/src/shared/bus-util.c#L598-L605 
and saw that you can connect to systemd using the sockets, for root 
would be `/run/systemd/private`, and for users something like 
`/run/user//systemd/private` and this trigger lots of questions, 
that i have not been able to answer, so here they are:


Question 1)

what would be the advantage of connecting through dbus instead of 
directly through the socket?


the way i connect to systemd is with `sd_bus_open_system` but i can 
also do


```
sd_bus_new();
sd_bus_set_address(bus, "unix:path=/run/systemd/private");
sd_bus_start(bus);
```

why (or when) would one be better than the other?
My understanding is that you should always connect through the normal 
system dbus socket and not use systemd's private socket


The private socket (afaiu) is meant to be used only by systemctl. It 
talks directly to systemd (without a dbus daemon) and is here to make 
sure systemd and systemctl can communicate even when dbus is broken or 
not started yet


question 2);

i also look that you can do the same with the user connections (and 
this is mostly true when the --user flag is given, at least on 
systemd-run), and you can connect to something like 
`/run/user//systemd/private`, where `/run/user/` is 
$XDG_RUNTIME_DIR, and i guess this is really the best form to connect 
to systemd as a user, but is there any difference between using that 
socket or doing `sd_bus_open_user`. ?


question 3)

systemd source code is pretty clear, really easy to learn from, also 
sd-bus.h is incredible helpful and easy to use.


But the docs is good, don't get me wrong, but it could definitely use 
more love. for instance the usage of the sockets 
`/run/{user/uid,}/systemd/private`, is not documented anywhere that i 
could find. is this intentional?, is this because this is a 
implementation detail that may change in the future?. if so, what 
would be the correct way to connect to systemd's socket?
i was particularly surprise that the sockets' path are hardcoded in 
the code.
Yesn systemd private sockets are private and systemd does not want to 
document private interfaces.


That being said, the system socket location is hardcoded not just in 
systemd, but in the dbus specification itself. It won't change, so it 's 
ok to hardcode it...


I didn't answer all your questions, but I hope the bits I know helped

Jeremy


if this parts have not just gotten into the docs, i would be more than 
happy to submit the PR for the docs.


Thank you guys!
Alvaro Leiva


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel