sd_varlink_error() deliberately returns a negative errno mapped from
the error id on success so callbacks can `return sd_varlink_error(...);`
to enqueue the reply and propagate a matching errno at once. When
varlink_dispatch_method() dispatches a configured error sentinel itself,
it doesn't need that mapping — but it was treating any negative return
as a dispatch failure and logging "Failed to process sentinel" even
though the error reply had been successfully enqueued.
Detect success via the state transition to VARLINK_PROCESSED_METHOD
instead, so only genuine enqueue failures are logged.
(cherry picked from commit
48326af23a1c9d95f9aa2fd66fcecbc7f90ccff5)
* and no replies were enqueued by the callback. */
if (sentinel == POINTER_MAX)
r = sd_varlink_reply(v, NULL);
- else
+ else {
r = sd_varlink_error(v, sentinel, NULL);
+ /* sd_varlink_error() deliberately returns a negative
+ * errno mapped from the error id on success (so method
+ * callbacks can `return sd_varlink_error(...);` to
+ * enqueue a reply and propagate a matching errno in one
+ * go). For sentinel dispatch we don't care about that
+ * mapping — the reply is either enqueued or not, which
+ * we detect via the state transition instead. */
+ if (v->state == VARLINK_PROCESSED_METHOD)
+ r = 0;
+ }
if (sentinel != POINTER_MAX)
free(sentinel);