Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-27 Thread Chris Morgan 
On Wed, May 27, 2015 at 5:23 AM, Simon McVittie
 wrote:
> On 26/05/15 20:22, Mantas Mikulėnas wrote:
>> But right now, the 'user' bus does not exist by default. To create it,
>> you need either
>> a) enable/install/boot with kdbus,
>> or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
>> dbus-git, or various other places like
>> .)
>
> The Correct™ way to get dbus.service/dbus.socket user units these days
> is with dbus >= 1.9.14 configured with --enable-user-session.
>
> If there are other ways to get similar units (e.g. user-session-units),
> please deprecate them. dbus upstream is where this stuff should have
> been all along, and in particular, dbus >= 1.9.14 is where I've made
> sure that libdbus and `dbus-launch --autolaunch` connect to the user bus
> (if it exists) by default.
>
>> Configured this way, the 'user' bus won't replace the session bus yet
>
> This is not the case. If there is a user bus, then the session bus *is*
> the user bus.
>
> S
>

Hmm.

I'm on F21 here. I can't tell if doing this is easy or hard or if it
will break anything else for me or the other 5 or 6 people that will
have to do the same thing on their systems. If F22 did this by default
I'd upgrade yesterday...

I'm still hoping we can get kdbus (and or user space improvements in
dbus performance...)

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

Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-27 Thread Simon McVittie 
On 26/05/15 20:22, Mantas Mikulėnas wrote:
> But right now, the 'user' bus does not exist by default. To create it,
> you need either
> a) enable/install/boot with kdbus,
> or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
> dbus-git, or various other places like
> .)

The Correct™ way to get dbus.service/dbus.socket user units these days
is with dbus >= 1.9.14 configured with --enable-user-session.

If there are other ways to get similar units (e.g. user-session-units),
please deprecate them. dbus upstream is where this stuff should have
been all along, and in particular, dbus >= 1.9.14 is where I've made
sure that libdbus and `dbus-launch --autolaunch` connect to the user bus
(if it exists) by default.

> Configured this way, the 'user' bus won't replace the session bus yet

This is not the case. If there is a user bus, then the session bus *is*
the user bus.

S

-- 
Simon McVittie
Collabora Ltd. 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-26 Thread Mantas Mikulėnas 
Well, the systemd side is already there – if you have kdbus, it'll create a
user bus there, and if you have traditional dbus.service + dbus.socket,
systemd will also happily connect to that.

On Tue, May 26, 2015, 23:46 Chris Morgan  wrote:

> On Tue, May 26, 2015 at 4:05 PM, Mantas Mikulėnas 
> wrote:
> > On Tue, May 26, 2015 at 10:32 PM, Chris Morgan 
> wrote:
> >>
> >> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas 
> >> wrote:
> >> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan 
> >> > wrote:
> >> >>
> >> >> But I can't seem to figure out how to do the same for user units.
> >> >> There doesn't seem to be an org.freedesktop.systemd1 interface on my
> >> >> current user's session bus and I wasn't able to spot anything in the
> >> >> interfaces on the system bus that had a nested interface of
> >> >> org.freedesktop.system1.Manager...
> >> >
> >> >
> >> > The first "org.freedesktop.systemd1" here is a /service/ name; the
> usual
> >> > hierarchy is bus - service - object - interface - method, no such
> thing
> >> > as
> >> > nested interfaces.
> >> >
> >> > Anyway. The user processes are not allowed to own service names on the
> >> > system bus. And `systemd --user` is a per-user service, not a
> >> > per-session
> >> > one, so it cannot be on the session bus for various reasons: it
> doesn't
> >> > know
> >> > the bus address; it needs to outlive the session bus; the user might
> >> > sometimes have multiple sessions with their own 'session bus'
> instances.
> >> >
> >> > So the idea is that `systemd --user` would be found on the /user/ bus,
> >> > which
> >> > would someday replace the 'session' bus entirely.
> >> >
> >> > But right now, the 'user' bus does not exist by default. To create it,
> >> > you
> >> > need either
> >> > a) enable/install/boot with kdbus,
> >> > or b) obtain the "dbus.service" & "dbus.socket" user units. (They're
> in
> >> > dbus-git, or various other places like
> >> > .)
> >> >
> >> > Configured this way, the 'user' bus won't replace the session bus yet,
> >> > but
> >> > you *will* be able to connect to it and reach systemd, at address
> >> > "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
> >> >
> >> > --
> >> > Mantas Mikulėnas 
> >>
> >> Hmm. I guess user services aren't used as much as system ones are?
> >>
> >> Is there another way to interface with systemctl like functionality
> >> programmatically? I have a c application that today is shelling out to
> >> systemctl to start services (which is fine for me since I'm not that
> >> concerned if it fails but it would be nice to know right at that
> >
> >
> > Note that systemctl *does* report failure as the process exit status +
> > stderr output.
> >
>
> Yep. But some services fall over after being started (bugs in our code
> etc).
>
> Does this also apply when doing 'systemctl status blah' eg. a non-zero
> exit status if the service isn't running? I'm thinking that may not be
> likely.
>
>
> >>
> >> time), but once everything is started I'd like to go through the
> >> services to make sure they all got started successfully. I didn't want
> >> to shell out to 'systemctl --user status xxx' and parse the output
> >
> >
> > Well, systemctl uses a private socket, at
> $XDG_RUNTIME_DIR/systemd/private.
> > It speaks the same DBus protocol, but using a direct peer-to-peer
> connection
> > (it's not a bus address).
> >
> > Remember that it's named "private" for a reason -- it's not part of the
> > supported API and can go away at any time (e.g. it won't exist anymore
> with
> > kdbus), so use it at your own risk.
> >
>
>
> Hmm. I guess I'll fall back to parsing the output of systemctl status
> until there is some mechanism to interact with user services.
>
> Is support for user dbus manager in the TODO or is that just something
> that is waiting on other infrastructure before being implemented? eg.
> kdbus?
>
> Chris
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-26 Thread Chris Morgan 
On Tue, May 26, 2015 at 4:05 PM, Mantas Mikulėnas  wrote:
> On Tue, May 26, 2015 at 10:32 PM, Chris Morgan  wrote:
>>
>> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas 
>> wrote:
>> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan 
>> > wrote:
>> >>
>> >> But I can't seem to figure out how to do the same for user units.
>> >> There doesn't seem to be an org.freedesktop.systemd1 interface on my
>> >> current user's session bus and I wasn't able to spot anything in the
>> >> interfaces on the system bus that had a nested interface of
>> >> org.freedesktop.system1.Manager...
>> >
>> >
>> > The first "org.freedesktop.systemd1" here is a /service/ name; the usual
>> > hierarchy is bus - service - object - interface - method, no such thing
>> > as
>> > nested interfaces.
>> >
>> > Anyway. The user processes are not allowed to own service names on the
>> > system bus. And `systemd --user` is a per-user service, not a
>> > per-session
>> > one, so it cannot be on the session bus for various reasons: it doesn't
>> > know
>> > the bus address; it needs to outlive the session bus; the user might
>> > sometimes have multiple sessions with their own 'session bus' instances.
>> >
>> > So the idea is that `systemd --user` would be found on the /user/ bus,
>> > which
>> > would someday replace the 'session' bus entirely.
>> >
>> > But right now, the 'user' bus does not exist by default. To create it,
>> > you
>> > need either
>> > a) enable/install/boot with kdbus,
>> > or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
>> > dbus-git, or various other places like
>> > .)
>> >
>> > Configured this way, the 'user' bus won't replace the session bus yet,
>> > but
>> > you *will* be able to connect to it and reach systemd, at address
>> > "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
>> >
>> > --
>> > Mantas Mikulėnas 
>>
>> Hmm. I guess user services aren't used as much as system ones are?
>>
>> Is there another way to interface with systemctl like functionality
>> programmatically? I have a c application that today is shelling out to
>> systemctl to start services (which is fine for me since I'm not that
>> concerned if it fails but it would be nice to know right at that
>
>
> Note that systemctl *does* report failure as the process exit status +
> stderr output.
>

Yep. But some services fall over after being started (bugs in our code etc).

Does this also apply when doing 'systemctl status blah' eg. a non-zero
exit status if the service isn't running? I'm thinking that may not be
likely.


>>
>> time), but once everything is started I'd like to go through the
>> services to make sure they all got started successfully. I didn't want
>> to shell out to 'systemctl --user status xxx' and parse the output
>
>
> Well, systemctl uses a private socket, at $XDG_RUNTIME_DIR/systemd/private.
> It speaks the same DBus protocol, but using a direct peer-to-peer connection
> (it's not a bus address).
>
> Remember that it's named "private" for a reason -- it's not part of the
> supported API and can go away at any time (e.g. it won't exist anymore with
> kdbus), so use it at your own risk.
>


Hmm. I guess I'll fall back to parsing the output of systemctl status
until there is some mechanism to interact with user services.

Is support for user dbus manager in the TODO or is that just something
that is waiting on other infrastructure before being implemented? eg.
kdbus?

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

Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-26 Thread Mantas Mikulėnas 
On Tue, May 26, 2015 at 10:32 PM, Chris Morgan  wrote:

> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas 
> wrote:
> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan 
> wrote:
> >>
> >> But I can't seem to figure out how to do the same for user units.
> >> There doesn't seem to be an org.freedesktop.systemd1 interface on my
> >> current user's session bus and I wasn't able to spot anything in the
> >> interfaces on the system bus that had a nested interface of
> >> org.freedesktop.system1.Manager...
> >
> >
> > The first "org.freedesktop.systemd1" here is a /service/ name; the usual
> > hierarchy is bus - service - object - interface - method, no such thing
> as
> > nested interfaces.
> >
> > Anyway. The user processes are not allowed to own service names on the
> > system bus. And `systemd --user` is a per-user service, not a per-session
> > one, so it cannot be on the session bus for various reasons: it doesn't
> know
> > the bus address; it needs to outlive the session bus; the user might
> > sometimes have multiple sessions with their own 'session bus' instances.
> >
> > So the idea is that `systemd --user` would be found on the /user/ bus,
> which
> > would someday replace the 'session' bus entirely.
> >
> > But right now, the 'user' bus does not exist by default. To create it,
> you
> > need either
> > a) enable/install/boot with kdbus,
> > or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
> > dbus-git, or various other places like
> > .)
> >
> > Configured this way, the 'user' bus won't replace the session bus yet,
> but
> > you *will* be able to connect to it and reach systemd, at address
> > "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
> >
> > --
> > Mantas Mikulėnas 
>
> Hmm. I guess user services aren't used as much as system ones are?
>
> Is there another way to interface with systemctl like functionality
> programmatically? I have a c application that today is shelling out to
> systemctl to start services (which is fine for me since I'm not that
> concerned if it fails but it would be nice to know right at that


Note that systemctl *does* report failure as the process exit status +
stderr output.


> time), but once everything is started I'd like to go through the
> services to make sure they all got started successfully. I didn't want
> to shell out to 'systemctl --user status xxx' and parse the output
>

Well, systemctl uses a private socket, at $XDG_RUNTIME_DIR/systemd/private.
It speaks the same DBus protocol, but using a direct peer-to-peer
connection (it's not a bus address).

Remember that it's named "private" for a reason -- it's not part of the
supported API and can go away at any time (e.g. it won't exist anymore with
kdbus), so use it at your own risk.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-26 Thread Chris Morgan 
On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas  wrote:
> On Tue, May 26, 2015 at 9:33 PM, Chris Morgan  wrote:
>>
>> But I can't seem to figure out how to do the same for user units.
>> There doesn't seem to be an org.freedesktop.systemd1 interface on my
>> current user's session bus and I wasn't able to spot anything in the
>> interfaces on the system bus that had a nested interface of
>> org.freedesktop.system1.Manager...
>
>
> The first "org.freedesktop.systemd1" here is a /service/ name; the usual
> hierarchy is bus - service - object - interface - method, no such thing as
> nested interfaces.
>
> Anyway. The user processes are not allowed to own service names on the
> system bus. And `systemd --user` is a per-user service, not a per-session
> one, so it cannot be on the session bus for various reasons: it doesn't know
> the bus address; it needs to outlive the session bus; the user might
> sometimes have multiple sessions with their own 'session bus' instances.
>
> So the idea is that `systemd --user` would be found on the /user/ bus, which
> would someday replace the 'session' bus entirely.
>
> But right now, the 'user' bus does not exist by default. To create it, you
> need either
> a) enable/install/boot with kdbus,
> or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
> dbus-git, or various other places like
> .)
>
> Configured this way, the 'user' bus won't replace the session bus yet, but
> you *will* be able to connect to it and reach systemd, at address
> "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
>
> --
> Mantas Mikulėnas 

Hmm. I guess user services aren't used as much as system ones are?

Is there another way to interface with systemctl like functionality
programmatically? I have a c application that today is shelling out to
systemctl to start services (which is fine for me since I'm not that
concerned if it fails but it would be nice to know right at that
time), but once everything is started I'd like to go through the
services to make sure they all got started successfully. I didn't want
to shell out to 'systemctl --user status xxx' and parse the output

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

Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-26 Thread Mantas Mikulėnas 
On Tue, May 26, 2015 at 9:33 PM, Chris Morgan  wrote:

> But I can't seem to figure out how to do the same for user units.
> There doesn't seem to be an org.freedesktop.systemd1 interface on my
> current user's session bus and I wasn't able to spot anything in the
> interfaces on the system bus that had a nested interface of
> org.freedesktop.system1.Manager...
>

The first "org.freedesktop.systemd1" here is a /service/ name; the usual
hierarchy is bus - service - object - interface - method, no such thing as
nested interfaces.

Anyway. The user processes are not allowed to own service names on the
system bus. And `systemd --user` is a per-user service, not a per-session
one, so it cannot be on the session bus for various reasons: it doesn't
know the bus address; it needs to outlive the session bus; the user might
sometimes have multiple sessions with their own 'session bus' instances.

So the idea is that `systemd --user` would be found on the /user/ bus,
which would someday replace the 'session' bus entirely.

But right now, the 'user' bus does not exist by default. To create it, you
need either
a) enable/install/boot with kdbus,
or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
dbus-git, or various other places like <
https://wiki.archlinux.org/index.php/Systemd/User#D-Bus>.)

Configured this way, the 'user' bus won't replace the session bus yet, but
you *will* be able to connect to it and reach systemd, at address
"kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] how to call dbus ListUnits for user units?

2015-05-26 Thread Chris Morgan 
Hello.

I'm able to use:

dbus-send --system --print-reply --reply-timeout=2000 --type=method_call \
--dest=org.freedesktop.systemd1 \
/org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.ListUnits

to list system units.

But I can't seem to figure out how to do the same for user units.
There doesn't seem to be an org.freedesktop.systemd1 interface on my
current user's session bus and I wasn't able to spot anything in the
interfaces on the system bus that had a nested interface of
org.freedesktop.system1.Manager...

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