In GitLab by @whot on Jul 24, 2020, 08:50

Apologies, this is rather a beginner question. I'm failing at trying to set up an ObjectServer - my requirement is that everything is contained within a context struct (this will be a library with a internal dbus backend). So effectively I need:

struct Context {
   connection: zbus::Connection,
   object_server: zbus::ObjectServer,
}

Since the ObjectServer::new() takes a reference to the Connection, Rust screams at me no matter what I try. The naive implementation was of course

impl Context {
  fn new() -> Self {
     let c = Connection::new_session();
     let o = ObjectServer::new(&c);
     Context {c, o}
  }
}

Which won't work because c gets moved. And all other 50 tries of lifetimes, RefCells, etc. attempts all failed too so at this point I'm lost. The only example for ObjectServer I could find has a static lifetime so it doesn't cover this use-case. I'd appreciate any help here in how to store this in a struct. Thanks.

In GitLab by @fluke on Apr 7, 2021, 03:44

asusd is a long running process and can receive many messages over time. The BT is:

thread 'main' panicked at 'failed to spawn thread: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }', /home/luke/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:620:29
stack backtrace:
   0:     0x557e9a2de740 - std::backtrace_rs::backtrace::libunwind::trace::h4dee703919bfd40a
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x557e9a2de740 - std::backtrace_rs::backtrace::trace_unsynchronized::h457e839f1a563e20
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x557e9a2de740 - std::sys_common::backtrace::_print_fmt::h86a55fb30f8393c8
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x557e9a2de740 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7b3d6cac46d277e1
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x557e9a30158f - core::fmt::write::h127419eb46f2ecc9
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/fmt/mod.rs:1092:17
   5:     0x557e9a2dae15 - std::io::Write::write_fmt::h6010cfbb4726588b
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/io/mod.rs:1578:15
   6:     0x557e9a2e07bb - std::sys_common::backtrace::_print::h79b4f9652330cc9d
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x557e9a2e07bb - std::sys_common::backtrace::print::h330bb326a76af8cf
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x557e9a2e07bb - std::panicking::default_hook::{{closure}}::heb6a42a7d50a472e
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:208:50
   9:     0x557e9a2e0283 - std::panicking::default_hook::h17e521ba6d68d6e1
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:225:9
  10:     0x557e9a2e0edd - std::panicking::rust_panic_with_hook::h70db735e3a6e70cb
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:591:17
  11:     0x557e9a2e0aa7 - std::panicking::begin_panic_handler::{{closure}}::h777c71c8e5a7e25c
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:497:13
  12:     0x557e9a2debfc - std::sys_common::backtrace::__rust_end_short_backtrace::h3e9bf30168899554
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x557e9a2e0a09 - rust_begin_unwind
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:493:5
  14:     0x557e9a2ffcf1 - core::panicking::panic_fmt::h5322a082d19786c3
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/panicking.rs:92:14
  15:     0x557e9a2ffb13 - core::option::expect_none_failed::h354eaa93a51d71b8
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/option.rs:1329:5
  16:     0x557e9a19d4dd - core::result::Result<T,E>::expect::heb48d018268ee0e4
  17:     0x557e9a19a7a0 - std::thread::spawn::h074d6679c0772f47
  18:     0x557e9a1adafd - zbus::azync::connection::Connection::receive_specific::{{closure}}::h6ec67f88432c7119
  19:     0x557e9a1abb4e - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hbc88bc08143b0c69
  20:     0x557e9a17e4d9 - async_io::driver::block_on::hc328be5aaeb50c39
  21:     0x557e9a1ac867 - zbus::connection::Connection::receive_message::h784628813309cd84
  22:     0x557e9a243b72 - zbus::object_server::ObjectServer::try_handle_next::h9fe0a9876df18e30
  23:     0x557e9a002587 - asusd::start_daemon::ha0f714b4a9686382
  24:     0x557e9a001373 - asusd::main::hf26ceba184a6b6b3
  25:     0x557e9a003e06 - core::ops::function::FnOnce::call_once::h5d3027d6b19c08dd
  26:     0x557e9a003d1c - std::sys_common::backtrace::__rust_begin_short_backtrace::h089ee6c3e397d8e2
  27:     0x557e9a005b5c - std::rt::lang_start::{{closure}}::h55e0553332b6cb66
  28:     0x557e9a2e12da - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hbcc915e668c7ca11
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/ops/function.rs:259:13
  29:     0x557e9a2e12da - std::panicking::try::do_call::h6b0f430d48122ddf
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:379:40
  30:     0x557e9a2e12da - std::panicking::try::h6ba420e2e21b5afa
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:343:19
  31:     0x557e9a2e12da - std::panic::catch_unwind::h8366719d1f615eee
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panic.rs:431:14
  32:     0x557e9a2e12da - std::rt::lang_start_internal::h965c28c9ce06ee73
                               at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/rt.rs:51:25
  33:     0x557e9a005b4e - std::rt::lang_start::h05154b4d3c2b5a87
  34:     0x557e9a002ec3 - main
  35:     0x7fea21c4fb75 - <unknown>
  36:     0x557e99ffd2ee - _start
  37:                0x0 - <unknown>

Where the lines:

  16:     0x557e9a19d4dd - core::result::Result<T,E>::expect::heb48d018268ee0e4
  17:     0x557e9a19a7a0 - std::thread::spawn::h074d6679c0772f47
  18:     0x557e9a1adafd - zbus::azync::connection::Connection::receive_specific::{{closure}}::h6ec67f88432c7119
  19:     0x557e9a1abb4e - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hbc88bc08143b0c69
  20:     0x557e9a17e4d9 - async_io::driver::block_on::hc328be5aaeb50c39
  21:     0x557e9a1ac867 - zbus::connection::Connection::receive_message::h784628813309cd84

indicate that zbus isn't handling a failure in a way that will prevent crashing.

In GitLab by @levans on Sep 15, 2020, 23:02

Some apps may wish to integrate a D-Bus connection into their event loop, but don't use Rust's async/await nor the associated runtimes.

Making zbus useable for such apps mostly implies providing two bits of API:

• a non-blocking version of Connection::receive_message, that returns std::io::ErrorKind::WouldBlock if there is nothing to be read rather than blocking waiting for a message to arrive
• access of a file descriptor, that the app can then register into its own event loop (backed by epoll or equivalent). I see that Connection already implements AsRawFd, so I suspect this is already possible?

Would that be in-scope for zbus?

In GitLab by @danieldg on Aug 13, 2021, 01:30

At the moment, if two Proxy objects and wait on both of them for a signal or property change, the order in which you get the signals is not defined. This could be an issue if there is in fact a caused-by relationship between the two signals resulting that the user code relies on.

Possible concrete example: the Inner part of an Interface is updated by a task that polls the NameAcquiredStream to get a list of all names of a certain pattern (say, org.mpris.MediaPlayer2.*). A client registers a name, waits for dbus to acknowledge it, then sends a request to the interface that expects it to be registered using that name. However, the task scheduler decides to run the ObjectServer task first and so the interface will reject the request - even though it's valid.

Caching after lazy activation has the same issue - the NameAcquired on the well-known name might be processed after the first signal from the owner of that name, resulting in the proxy rejecting the mismatching signal.

~~Not sure how much of a problem this is, but it does have the ability to cause problems in some code - and it may become more important depending on how property caching works.~~

Related: #178

~~A possible solution to both #178 and this would be to run the connect_foo closures in the MessageReceiverTask. Then you just need to document that all of the Stream APIs have the potential to lose or reorder inbound messages.~~

Update: this also applies to method returns that populate a cache, such as GetAll for properties cache or GetNameOwner/NameAcquired on proxies associated with a well-known name.

In GitLab by @li.yu.sh0211 on Jan 13, 2022, 17:35

Here is error details

MethodError(OwnedErrorName(ErrorName(Str(Owned("org.freedesktop.DBus.Error.Spawn.ChildExited")))), Some("Process org.freedesktop.systemd1 exited with status 1"), Msg { type: Error, sender: UniqueName(Str(Borrowed("org.freedesktop.DBus"))), reply-serial: 2, body: Signature: [
        s (115),
] })

same method working for blocking proxy though, need help ...

In GitLab by @MaxVerevkin on May 25, 2022, 16:05

I create a Connection, then I subscribe to some events using DBusProxy::add_match(), then I create MessageStream from said connection.

When I finally receive a message, I think it would be intuitive if I could write something like

let message = stream.next().await
if let Ok(signal) = PropertiesChanged::try_from(message) {
    // ...
}

Maybe I'm doing something wrong, and this is already possible? And what is the recommended way to deal with messages from different interfaces?

In GitLab by @PolyMeilex on Aug 12, 2020, 04:28

Hi, first of all, thanks for the awesome crate, it is so much better in comparison to other alternatives, great work.

So the issue is:

When I use zbus in a standard app everything works as expected, but when I try to run my dbus server as a systemd service it does not work on initial connection.

What I mean by that is that systemd will automatically start service associated with dbus service name. So for example, if I call SayHello method (using dbus-send) on org.zbus.server it will start the service responsible for handling it, and our dbus server will return the requested data.

It works as expected when testing with dbus-rs server example

But with zbus server example it never returns data, it starts as expected and just hangs, and after some time we get Error org.freedesktop.DBus.Error.NoReply, when service is already started we can send the request again and then it will return data as expected, so there is some problem with initial startup call, that zbus ignores. Actually, the event never reaches function associated with it, so in the above example say_hello is never called

EDIT: I'll test it with low level example and I'll let you know if this helps

In GitLab by @danieldg on Jul 24, 2021, 20:38

Currently, if dbus sends a large enough burst of messages to us, we start dropping the oldest ones with no indication that this happened on any Stream implementation. While this mostly just causes timeouts in anyone making method calls (or exposes the lack of timeout handling), any caching that expects to be invalided by signals will be silently incorrect - which will likely result in some very hard-to-debug issues once property caching becomes a thing.

I'm not sure what solution is best here: there's a lot of code that relies on the fact that a given Connection object might never use its Stream impl, and overruns on those receivers should be ignored. The presence of non-draining Connections also makes it difficult to set a very high value for max_queued as you are basically guaranteed to store that many Arc objects unless you always drain the Stream from any inactive Connection object.

Tokio's broadcast channel will notify receivers if there was an overflow; maybe this feature needs to be added to async_broadcast? A property cache could use such a notification to invalidate itself and re-run GetAll.

Alternatively, a way to disable overflow and explicitly mark some Connection instances as not-used-for-Stream (using async_broadcast::InactiveReceiver) would allow this to be handled by temporarily blocking incoming messages until the queue has shrunk. That behavior would need to be opt-in because it has a good chance to cause deadlocks if some Stream is not being polled (likely because its task is blocking on a different await).

In GitLab by @ludo-c on Nov 19, 2022, 24:55

Hello,

As discussed on Matrix, it sometimes happen that the SignalStream created from the receive_ method from the generated async Proxy does not produce any message.

That's a little bit rough, but this sample code reproduce it after some minutes:

• https://github.com/ludo-c/fake-listener
• https://github.com/ludo-c/fake-producer

Steps to reproduce are in the listener readme : https://github.com/ludo-c/fake-listener/blob/main/README.md

After few minutes, the log ERROR fake_listener] Signal received. isn't showed anymore, and logs are only:

1232022-11-18T22:49:15.203537Z TRACE receive_msg: 122: Message received on the socket: Msg { type: Signal, sender: UniqueName(Str(Borrowed(":1.18160"))), path: ObjectPath("/ludo_ic/daemon/producer"), iface: InterfaceName(Str(Borrowed("ludo_ic.daemon.producer"))), member: MemberName(Str(Borrowed("MySignalEvent"))), body: Signature("ii") }
2022-11-18T22:49:15.203669Z TRACE receive_msg: 131: Message broadcasted to all streams: Msg { type: Signal, sender: UniqueName(Str(Borrowed(":1.18160"))), path: ObjectPath("/ludo_ic/daemon/producer"), iface: InterfaceName(Str(Borrowed("ludo_ic.daemon.producer"))), member: MemberName(Str(Borrowed("MySignalEvent"))), body: Signature("ii") }
2022-11-18T22:49:15.203793Z TRACE receive_msg: 107: Waiting for message on the socket..

in loop.

For what it's worth, stopping and restarting the producer solve the issue, but that's of course not the good solution (I have no control on the producer in the real case).

I hope you will reproduce it too.

Do not hesitate if you have any questions.

Thank you very much !

Edit: I reproduce it on Ubuntu 22.04.1 LTS.

In GitLab by @tyrylu on Nov 2, 2022, 17:02

As quickly mentioned in the dependency update issue, I'd personally replace the xml parsing crate. It would make cargo audit happy, and if wanted, it would allow getting rid of the enums which handle the possibly overlapping lists in the XML definitions, yes, of course at a potential cost... What do you think, should I proceed with a MR? And would you change xml APIs as well?

In GitLab by @fluke on Jan 18, 2022, 01:23

I don't know if this is an issue, more likely It's that I'm unsure of how best to do this.

The following is everything reduced down to an example:

#[dbus_proxy(
    interface = "org.freedesktop.login1.Manager",
    default_service = "org.freedesktop.login1",
    default_path = "/org/freedesktop/login1"
)]
trait Manager {
//...
    /// Inhibit method
    #[inline]
    fn inhibit(
        &self,
        what: InhibitThis, // Problem point, this is `s`
        who: &str,
        why: &str,
        mode: &str,
    ) -> zbus::Result<std::os::unix::io::RawFd>;
}

#[derive(Debug, PartialEq, Clone, Serialize, Deserialize)]
pub enum InhibitThis {
    Shutdown,
    Sleep,
    Idle,
    HandlePowerKey,
    HandleSuspendKey,
    HandleHibernateKey,
    HandleLidSwitch,
    Invalid,
}

impl From<&str> for InhibitThis {
    fn from(s: &str) -> Self {
        match s.trim() {
            "shutdown" => Self::Shutdown,
            "sleep" => Self::Sleep,
            "idle" => Self::Idle,
            "handle-power-key" => Self::HandlePowerKey,
            "handle-suspend-key" => Self::HandleSuspendKey,
            "handle-hibernate-key" => Self::HandleHibernateKey,
            "handle-lid-switch" => Self::HandleLidSwitch,
            _ => Self::Invalid,
        }
    }
}

impl From<InhibitThis> for &str {
    fn from(s: InhibitThis) -> Self {
        match s {
            InhibitThis::Shutdown => "shutdown",
            InhibitThis::Sleep => "sleep",
            InhibitThis::Idle => "idle",
            InhibitThis::HandlePowerKey => "handle-power-key",
            InhibitThis::HandleSuspendKey => "handle-suspend-key",
            InhibitThis::HandleHibernateKey => "handle-hibernate-key",
            InhibitThis::HandleLidSwitch => "handle-lid-switch",
            InhibitThis::Invalid => "invalid",
        }
    }
}

impl TryFrom<OwnedValue> for InhibitThis {
    type Error = zbus::Error;

    fn try_from(value: OwnedValue) -> Result<Self, Self::Error> {
        let value = <String>::try_from(value)?;
        return Ok(Self::from(value.as_str()));
    }
}

impl TryFrom<InhibitThis> for Value<'_> {
    type Error = zbus::Error;

    fn try_from(value: InhibitThis) -> Result<Self, Self::Error> {
        Ok(Value::Str(zvariant::Str::from(<&str>::from(value))))
    }
}

impl TryFrom<InhibitThis> for OwnedValue {
    type Error = zbus::Error;

    fn try_from(value: InhibitThis) -> Result<Self, Self::Error> {
        Ok(OwnedValue::from(zvariant::Str::from(<&str>::from(value))))
    }
}

impl Type for InhibitThis {
    fn signature() -> zvariant::Signature<'static> {
        Signature::from_str_unchecked("s")
    }
}

I'm sort of jumping around trying to find the solution here. InhibitThis needs to be s dbus type, and the derives usually turn in to u. I imagine I need to manually ser/de?

I also tried:

    /// Inhibit method
    #[inline]
    fn inhibit(
        &self,
        data: SomeStruct,
    ) -> zbus::Result<std::os::unix::io::RawFd>;
}

but the signature ends up being (ssss) when ssss is required. There's a lot of cases like this in logind, so any tips would be greatly appreciated.

The object attribute in the dbus_proxy macro is a nice quality-of-life enhancement, but only seems to work on DBus methods. When trying to use it on a DBus property, it produces errors like this:

error[E0308]: mismatched types
  --> src/wifi/iwd.rs:60:5
   |
60 |     fn adapter(&self);
   |     ^^^^^^^^^^^^^^^^^- help: consider using a semicolon here: `;`
   |     |
   |     expected `()`, found `Result<_, _>`
   |
   = note: expected unit type `()`
                   found enum `std::result::Result<_, _>`

This is from Device in the following code:

#[dbus_proxy(
    interface = "net.connman.iwd.Adapter",
    default_service = "net.connman.iwd",
    assume_defaults = false,
)]
pub trait Adapter {
    #[dbus_proxy(property)]
    fn powered(&self) -> Result<bool>;

    #[dbus_proxy(property)]
    fn set_powered(&mut self, powered: bool) -> Result<()>;

    #[dbus_proxy(property)]
    fn name(&self) -> Result<String>;

    #[dbus_proxy(property)]
    fn model(&self) -> Result<String>;

    #[dbus_proxy(property)]
    fn vendor(&self) -> Result<String>;

    #[dbus_proxy(property)]
    fn supported_modes(&self) -> Result<Vec<String>>;
}

#[dbus_proxy(
    interface = "net.connman.iwd.Device",
    default_service = "net.connman.iwd",
    assume_defaults = false,
)]
pub trait Device {
    #[dbus_proxy(property)]
    fn name(&self) -> Result<String>;

    #[dbus_proxy(property)]
    fn address(&self) -> Result<String>;

    #[dbus_proxy(property)]
    fn powered(&self) -> Result<bool>;

    #[dbus_proxy(property)]
    fn set_powered(&mut self, powered: bool) -> Result<()>;

    #[dbus_proxy(property, object = "Adapter")]
    fn adapter(&self);

    #[dbus_proxy(property)]
    fn mode(&self) -> Result<String>;

    #[dbus_proxy(property)]
    fn set_mode(&mut self, mode: &str) -> Result<()>;
}

Adding -> Result<OwnedObjectPath>; fixes the error and allows this code to compile, but it seems the object attribute is ignored entirely.

Based on all this, I'm guessing the object attribute simply isn't implemented for properties. If possible, it would be a nice enhancement to have.

In GitLab by @danburkert on May 6, 2023, 20:06

The dbug_proxy! macro provides the object annotation generating a proxy return type for methods which return an object path - it would be nice if there were an equivalent annotation for handling methods that return an array of object paths.

In GitLab by @bilelmoussaoui on Apr 26, 2023, 10:09

It ends up pulling tracing/ tracing-core / tracing-attributes indirectly. As in the libraries I wrote on top of zbus, I explicitly added a tracing feature, I would love if that feature would also control zbus's future tracing support.

In GitLab by @SeaDve on Mar 16, 2023, 15:44

Currently, there is zbus::Message::from_raw_parts. However, it is private.

For the use case, Bustle has DBus messages serialized in a pcap file. There is currently not a convenient way to parse the bytes from each packet from the pcap file into a zbus::Message.

Link

• GDBusMessage.new_from_blob

In GitLab by @bouk on Mar 13, 2023, 14:53

This transport forks off a process and connects its standard input and standard output with an anonymous Unix domain socket. This socket is then used for communication by the transport. This transport may be used to use out-of-process forwarder programs as basis for the D-Bus protocol.

This can be used with systemd-stdio-bridge to connect to the systemd bus on another system over SSH.