SD_BUS_RE...THOD_ERROR(3)

πŸ’… SD_BUS_RE...THOD_ERROR(3) πŸ’…

okay so bestie, welcome to sd_bus_reply_method_error β€” part of the sd_bus_reply_method_error family in the sd_bus_reply_method_error section of the manual. yes the header truncated the name, no that's not my fault, it's giving "long function name problems" 😭. the actual manual name is sd_bus_reply_method_error and today we're learning how to politely tell a D-Bus caller "girl, no" πŸŽ€


✨ NAME ✨

sd_bus_reply_method_error, sd_bus_reply_method_errorf, sd_bus_reply_method_errorfv, sd_bus_reply_method_errno, sd_bus_reply_method_errnof, sd_bus_reply_method_errnofv β€” reply with an error to a D-Bus method call πŸ’€

like, the call came in, you looked at it, and you're sending back a no. iconic behavior tbh.


🌸 SYNOPSIS 🌸

#include <systemd/sd-bus.h>

int sd_bus_reply_method_error(sd_bus_message *call,
                              const sd_bus_error *e);

int sd_bus_reply_method_errorf(sd_bus_message *call, const char *name,
                               const char *format, ...);

int sd_bus_reply_method_errorfv(sd_bus_message *call, const char *name,
                                const char *format, va_list ap);

int sd_bus_reply_method_errno(sd_bus_message *call, int error,
                              const sd_bus_error *p);

int sd_bus_reply_method_errnof(sd_bus_message *call, int error,
                               const char *format, ...);

int sd_bus_reply_method_errnofv(sd_bus_message *call, int error,
                                const char *format, va_list ap);

six whole functions, all baddies, all doing the "sorry not sorry" reply πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

so. sd_bus_reply_method_error() sends an error reply to the call message. the error structure e specifies the error you're sending, and it gets used exactly as described over in sd_bus_message_new_method_error(3) β€” go read that one, it's the source of truth, iykyk. and here's the cute part: if no reply is expected to call, this function succeeds without sending a reply at all. she just... doesn't. main character energy 🌈

then we got the vibe-check cousins, all defined by ✨analogy✨:

  • sd_bus_reply_method_errorf() is to sd_bus_reply_method_error() what sd_bus_message_new_method_errorf() is to sd_bus_message_new_method_error() 🫢
  • sd_bus_reply_method_errno() is to sd_bus_reply_method_error() what sd_bus_message_new_method_errno() is to sd_bus_message_new_method_error() 🫢
  • sd_bus_reply_method_errnof() is to sd_bus_reply_method_error() what sd_bus_message_new_method_errnof() is to sd_bus_message_new_method_error() 🫢

the pattern is literally right there, bestie. f = formatted, v = you brought a va_list, errno = you're passing an int error. slay.


πŸ‘‘ RETURN VALUE πŸ‘‘

this function returns a non-negative integer if the error reply was successfully sent or if call doesn't expect a reply (yes, both. she's flexible πŸ’–). on failure it returns a negative errno-style error code. no cap.

😭 Errors 😭

the returned errors may indicate these problems, and honestly? mood:

  • -EINVAL β€” multiple ways to disappoint her:
    • the input parameter call is NULL 🫠
    • message call is not a method call message
    • message call is not attached to a bus
    • the error parameter e to sd_bus_reply_method_error() is not set, see sd_bus_error_is_set(3)
  • -EPERM β€” message call has been sealed πŸ”’ (locked, done, no touching)
  • -ENOTCONN β€” the bus to which message call is attached is not connected ⭐
  • -ENOMEM β€” memory allocation failed πŸ’€
oh and also: any error returned by sd_bus_send(3) may be returned too. so like, surprise errors are on the table. πŸ™ˆ

🧚 NOTES 🧚

  • the functions described here are available as a shared library</>, which you can compile against and link to with the libsystemd pkg-config(1) file πŸŽ€
  • all functions listed here are thread-agnostic and only a single thread may operate on a given object at any given time. different threads may access the same object at different times. multiple independent objects may be used from different threads in parallel. so like... share the object, but take turns. periodt. πŸ’…
  • the code described here uses getenv(3), which is declared to be not multi-thread-safe. which means: the code calling the functions described here must not call setenv(3) from a parallel thread. the recommendation is to only do calls to setenv() from an early phase of the program when no other threads have been started. do it first, do it alone, do it early 🌸

πŸ”₯ SEE ALSO πŸ”₯

systemd(1), sd-bus(3), sd_bus_message_new_method_error(3)


and that's the whole page bestie ✨ this lil slice of wisdom comes to you from systemd 261.3, page SD_BUS_RE...THOD_ERROR(3) β€” go forth and error-reply responsibly, mwah πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from