Как написать D-Bus сервис, работающий на системной шине, на Rust

[domix32]

let error : String = "Error during data processing: ".to_string() + &err.to_string(); println!("{error}");

format!, не (аналогично тут)? Ну и раз вы все равно его в принты выводите не очень понятно, что мешало на месте это отформатировать. И для ошибок есть eprintln! который пишет в stderror.

Ещё заметил непонятный unreachable! , который стоит явно не к месту.

[FedotovMO]

Спасибо за рекомендации по формату и stderror - поправил в проекте.

unreachable! в этот пример переехал из основного примера с той идеей, что код после serve не должен быть доступен, поскольку там под капотом Loops that dynamically terminate.

[domix32]

unreachable там точно не к месту. Его используют в качестве ассерта в условиях для подсказки какие ветки кода будут исполняться, а какие точно являются некорректными. Паника вместо того чтобы вернуть ошибку звучит как плохой план. Типичиный юзкейс: если вы скармливаете в функцию массив чисел, который гарантированно должен содержать только 0 или 1 в контейнере.

fn foo(vec: Vec<i32>) {
   for v in vec.into_iter() {
      match v {
        0 => process_zero(),
        1 => process_one(),
        _ => unreachable!(), // в эту ветку никогда не должны попадать
                             // иначе считаем введёные даныне некорректными
      }
   }
}

Внутри serve по идее должен быть loop и использовать недостижимое макро в контексте выхода из скоупа как-то странно.

[mayorovp]

Я тоже так думал, что странно, но потом оказалось что never-тип (который !) до сих пор экспериментальный и за флагами, и это всё объясняет.

Так-то да, если бы serve() возвращал не Result<(), Error>, а Result<!, Error> - никакого unreachable бы не понадобилось.

[domix32]

Так верните самостоятельно либо Ok(()) , либо нормальный Err . Ну или функцию войдовой сделайте.

[mayorovp]

Возврат Ok(()) подразумевает, что функция реально может вернуть Ok(()), а это не так.

[IZh]

Запускать сервис при помощи самого демона D-Bus сейчас уже не рекомендуется, так как демон D-Bus умеет гораздо хуже управлять сервисами, чем systemd. К тому же, гораздо лучше, когда родителем процесса сервиса является systemd.

Современный systemd сам умеет активировать сервисы при поступлении запросов на шину D-Bus.

[FedotovMO]

Интересно, спасибо. Надо будет принять это во внимание.

[IZh]

А чтобы за примерами далеко не ходить, в самой Авроре есть около 20 сервисов в каталогах /usr/share/dbus-1/services и /usr/share/dbus-1/system-services, которые используют описанную схему активации. Их легко найти по наличию строки Exec=/bin/false.

[lmaxyz]

Вижу, что сборка происходит на хосте. Планируется ли обновлять rust на движке сборки, чтобы достаточно было в .spec файле прописать `cargo build --release` ? На данный момент он там хоть и есть, но имеет какую-то совсем протухшую версию.

[mayorovp]

Что-то я не смог расшифровать ваш комментарий...

[lmaxyz]

А я увидел слово "Аврора" и почему-то подумал, что статья про то, как написать сервис для авроры. А разработка под аврору происходит с помощью сборочного движка и эмулятора, и вот про движок я собственно и спросил.