Re: [systemd-devel] sd_bus_get_unique_name returns -EBADMSG or -EBUSY

2021-04-07 Thread Carlo Wood
On Wed, 7 Apr 2021 16:15:40 +0200
Lennart Poettering  wrote:

> 
> > As you stated in the linked email, there is no global state.
> > So, I suppose that if I call any sd_bus_* function that
> > all that I have to take into account is that the data
> > that is passed to those functions is protected. If they
> > use different connections, then no data should be shared,
> > no?  
> 
> Not sure I grok the question.

It was just a repeat, stated differently.

I assume that anything related to the same sd_bus* object,
which includes sd_bus_message* objects that use that sd_bus*
can not be passed to more than one function at a time and
executed in parallel. But (which is what I stated above)
if the (associated) sd_bus* is different, then that is possible.

I think you already confirmed that this is possible.

So, my plan will be to add a "lock" per connection.

I have dbus::Connection objects and it will be very clear
which one any call to a sd_bus_* function is associated
with; so I can use those objects as "lock". I put lock between
quotes here because it won't be an ordinary mutex: a mutex
blocks other threads as long as the thread holds this mutex
(aka, is inside the function). That is quite long imho:
normally I try to keep mutexes that can block out other threads
for (much) less than a micro second. Longer than 10 micro
seconds is unacceptable (and wrong use of mutexes imho).

I invented a different concept to deal with threads with
my library: I run threaded code in 'tasks' which are then
basically executed single-threaded (not the same thread,
but one thread at a time runs a task). All variables that
a task deals with while running are private members of
the task object and there is therefore no locking needed
at all for those variables.

However, I decided against using a different sdbus connection
per thread for the simple reason that I do not keep track
of threads; I have tasks that when needing to run get cpu
time from an available thread. I could use one connection
per task, but that has (a lot of) overhead, since I create,
execute and destroy tasks a LOT. Aka, you'd get a new
connection for every sd_bus message. It seemed more logical
to me to make a connection and keep that alive; and reuse
it over and over for new messages. That way, in most cases,
I'll just have a single connection (ie, to the userbus)
without a repeat of the handshake all the time.

But since I have tasks for doing everything, like sending
a signal, or a method call, and those run in parallel at
the moment, the connection, aka sd_bus object, is used
by multiple threads concurrently at the moment, causing
more than one thread to enter the sd_bus library at the
time time for the same sd_bus object.


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


Re: [systemd-devel] sd_bus_get_unique_name returns -EBADMSG or -EBUSY

2021-04-07 Thread Lennart Poettering
On Mi, 07.04.21 12:17, Carlo Wood (ca...@alinoe.com) wrote:

> On Tue, 6 Apr 2021 18:41:21 +0200
> Lennart Poettering  wrote:
>
> > EBADMSG usually means that somehow an invalid dbus packet we couldn't
> > parse entered the stream. maybe some memory corruption thing? or maybe
> > you are using this in a threaded env without locking?
> >
> > Lennart
>
> Yes, that is the case. I was reading up on the demands,
> which I found on
> https://www.spinics.net/lists/systemd-devel/msg01779.html
>
> making me wonder why I went through the trouble of supporting
> dbus with my library :p (which aims at massive parallel
> execution without EVER blocking or going to sleep).

sd-bus is fully async. It only blocks if you call the functions that
are synchronous wrappers around async functions. e.g. sd_bus_call() is
actually more or less a synchronous wrapper around the same stuff that
sd_bus_call_async() does async.

Async means here the work is enqueued into the socket or client side,
and then dispatched by an event loop of sorts. The event loop can be
sd-event, or you can use any other you like, that has a poll()-like
glue interface.

You are supposed to have one sd-bus connection per thread though. It's
the model this is all built for. If you want to share one connection
among multiple threads, you need to do your locking around that
yourself.

> Libraries that do not support threading are a pain :/.

Well, depends what you mean by "supporting". sd-bus is written with
threads in mind, i.e. everything is broken down to local contexts,
there's no global non-fixed data and such. It's just a different model
that you might be used to: i.e. one connection per thread and locking
if desired must be done in your own code.

> It would really help if you could tell me a more fine-
> grained multi-threading demands; like - per connection.

D-Bus as a protocol is big on global ordering. It's thus not really
compatible with being dispatched in thread pools, because those would
basically randomize dispatch ordering.

It's a design decision of D-Bus.

> Surely I can execute sd_bus_* functions that deal with
> a different dbus* in parallel?

Yes. You are not supposed to share individual sd_bus objects (and
their associated helper objects) between multiple threads, unless you
do your own locking around it. But you can have as many sd_bus objects
you want and run the independently from any number of threads you
like, fully in parallel.

> As you stated in the linked email, there is no global state.
> So, I suppose that if I call any sd_bus_* function that
> all that I have to take into account is that the data
> that is passed to those functions is protected. If they
> use different connections, then no data should be shared,
> no?

Not sure I grok the question.

Lennart

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


Re: [systemd-devel] hostnamectl set-hostname non-admin user

2021-04-07 Thread Damien LEFEVRE
Thanks Silvio! That's just what I needed.

Cheers,
-Damien

On Tue, Apr 6, 2021 at 9:26 PM Silvio Knizek  wrote:

> Am Dienstag, dem 06.04.2021 um 16:21 +0300 schrieb Damien LEFEVRE:
> > Hi,
> >
> > I have an embedded device and I do not install sudo. I need to have a
> > non-root running the main service capable of changing the hostname.
> >
> > After spending a long afternoon on this I still have not managed.
> >
> > Here i've tried adding my new user but only read-only requests go
> > through
> > /usr/share/dbus-1/system.d/org.freedesktop.hostname1.conf
> > ```xml
> >  
> >  > Configuration 1.0//EN"
> >
> > "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;>
> >
> > 
> >
> > 
> >
> > 
> > 
> > 
> > 
> > 
> >
> > 
> > 
> > 
> > 
> > 
> >
> > 
> > 
> > 
> > 
> >
> > 
> > ```
> >
> >
> > /usr/share/polkit-1/actions/org.freedesktop.hostname1.policy
> > ```xml
> >  
> >  > Configuration 1.0//EN"
> > "
> > http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd;>
> >
> > 
> >
> > 
> >
> > The systemd Project
> >
> > http://www.freedesktop.org/wiki/Software/systemd > url>
> >
> > 
> > Set host
> > name
> > Authentication is
> > required to set the local host name.
> > 
> > auth_admin_keep
> >
> > auth_admin_keep
> > auth_admin_keep
> > 
> > 
> >
> > 
> > Set static host
> > name
> > Authentication is
> > required to set the statically configured local host name, as well as
> > the pretty host name.
> > 
> > auth_admin_keep
> >
> > auth_admin_keep
> > auth_admin_keep
> > 
> >  > key="org.freedesktop.policykit.imply">org.freedesktop.hostname1.set-
> > hostname org.freedesktop.hostname1.set-machine-info
> > 
> >
> > 
> > Set machine
> > information
> > Authentication is
> > required to set local machine information.
> > 
> > auth_admin_keep
> >
> > auth_admin_keep
> > auth_admin_keep
> > 
> > 
> >
> > 
> > Get product
> > UUID
> > Authentication is
> > required to get product UUID.
> > 
> > auth_admin_keep
> >
> > auth_admin_keep
> > auth_admin_keep
> > 
> > 
> >
> > 
> > ```
> >
> > Despite all my attempts I always get 'Could not set property: Access
> > denied' for hostnamectl set-hostname
> >
> > And get the 'org.freedesktop.DBus.Error.AccessDenied' in dbus-monitor
> >
> > method call time=1617739342.317948 sender=:1.23 ->
> > destination=org.freedesktop.hostname1 serial=3
> > path=/org/freedesktop/hostname1; interface=org.freedesktop.hostname1;
> > member=SetStaticHostname
> >string "blabla"
> >boolean true
> > ...
> > error time=1617739342.320289 sender=:1.24 -> destination=:1.23
> > error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=3
> >string "Permission denied"
> >
> >
> > Any help would be greatly appreciated =)
> >
> > -Damien
>
> Hi Damien,
>
> you actually need to configure polkit for this. Something like
> /etc/polkit-1/rules.d/49-allow-myuser-access-to-hostnamed.rules
>
> ```javascript
> polkit.addRule(function(action, subject) {
> if (action.id == "org.freedesktop.hostname1.set-hostname") {
> if (subject.user == "myuser") {
> return polkit.Result.YES;
> }
> }
> });
> ```
>
> Your dbus definition only says that one can define rules including such
> actions.
>
> HTH
> Silvio
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] sd_bus_get_unique_name returns -EBADMSG or -EBUSY

2021-04-07 Thread Carlo Wood
On Tue, 6 Apr 2021 18:41:21 +0200
Lennart Poettering  wrote:

> EBADMSG usually means that somehow an invalid dbus packet we couldn't
> parse entered the stream. maybe some memory corruption thing? or maybe
> you are using this in a threaded env without locking?
> 
> Lennart

Yes, that is the case. I was reading up on the demands,
which I found on
https://www.spinics.net/lists/systemd-devel/msg01779.html

making me wonder why I went through the trouble of supporting
dbus with my library :p (which aims at massive parallel
execution without EVER blocking or going to sleep).

Libraries that do not support threading are a pain :/.

It would really help if you could tell me a more fine-
grained multi-threading demands; like - per connection.

Surely I can execute sd_bus_* functions that deal with
a different dbus* in parallel?

As you stated in the linked email, there is no global state.
So, I suppose that if I call any sd_bus_* function that
all that I have to take into account is that the data
that is passed to those functions is protected. If they
use different connections, then no data should be shared,
no?

Carlo



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