SD_BUS_MESSAGE_GET_TYPE(3)
π SD_BUS_MESSAGE_GET_TYPE(3) π
okay bestie, welcome to sd_bus_message_get_type β the manual page, part of the whole sd-bus universe, and honestly? she's a little legend. this one's all about querying bus message addressing/credentials metadata, which sounds like a lot but is literally just "hey, what kind of message is this and who's it from". you're gonna slay this, i promise π«Ά
β¨ SYNOPSIS β¨
#include <systemd/sd-bus.h>
int sd_bus_message_get_type(sd_bus_message *m, uint8_t *type);
sd_bus_error* sd_bus_message_get_error(sd_bus_message *m);
int sd_bus_message_get_errno(sd_bus_message *m);
sd_bus_creds* sd_bus_message_get_creds(sd_bus_message *m);
int sd_bus_message_is_signal(sd_bus_message *m, const char *interface,
const char *member);
int sd_bus_message_is_method_call(sd_bus_message *m,
const char *interface,
const char *member);
int sd_bus_message_is_method_error(sd_bus_message *m, const char *name);
like, seven whole functions in one page. she's an overachiever π
πΈ DESCRIPTION πΈ
sd_bus_message_get_type() drops the type of a message into the output parameter type, and it'll be one of SD_BUS_MESSAGE_METHOD_CALL, SD_BUS_MESSAGE_METHOD_RETURN, SD_BUS_MESSAGE_METHOD_ERROR, or SD_BUS_MESSAGE_SIGNAL. where does that type come from? either you handed it over as a parameter when you made the message with sd_bus_message_new(3), or it got set automatically when the message was created with sd_bus_message_new_signal(3), sd_bus_message_new_method_call(3), sd_bus_message_new_method_error(3) and similar functions. autopilot, iconic β¨
sd_bus_message_get_error() hands you back the error stored in the message m, if there even is one. no error? it returns NULL. and sd_bus_message_get_errno() gives you that same error stored in the message m, but as a positive errno-style value. no error? it returns zero. ngl that's the whole diff between those two. errors get mapped to errno values according to the default mappings plus any extra error mappings you registered β see sd-bus-errors(3) and sd_bus_error_add_map(3) for the receipts π
sd_bus_message_get_creds() returns the message credentials attached to the message m, and if like, no credentials are attached to the message, it returns NULL. bestie, listen: ownership of the credentials instance is not transferred to the caller, so do not free it. it's not yours, leave it alone π
sd_bus_message_is_signal() checks if message m is a signal message. if interface is non-null, she also checks if the message has the same interface set. if member is non-null, she also checks if the message has the same member set. also peep sd_bus_message_new_signal(3). returns true when all the checks pass π¦
sd_bus_message_is_method_call() checks if message m is a method call message. if interface is non-null, it also checks if the message has the same interface set. if member is non-null, it also checks if the message has the same member set. also see sd_bus_message_new_method_call(3). returns true when all checks pass π
sd_bus_message_is_method_error() checks if message m is an error reply message. if name is non-null, it also checks if the message has the same error identifier set. also see sd_bus_message_new_method_error(3). returns true when all checks pass β
π RETURN VALUE π
on success, these functions (except sd_bus_message_get_error() and sd_bus_message_get_creds(), those two are the exceptions, don't come for me) return a non-negative integer. on failure, they return a negative errno-style error code.
and sd_bus_message_get_errno()? she always returns a non-negative integer, even on failure. main character energy, truly π
π Errors
the errors you might get back mean these things:
-EINVALβ the message parametermor an output parameter isNULL. basically "girl where is it" π
π§ NOTES π§
so 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. standard stuff, lowkey easy π
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 (just not at the same time, bestie, that's the whole point). multiple independent objects may be used from different threads in parallel β that part's fine π
the code described here uses getenv(3), which is declared to be not multi-thread-safe. what that means for you: code calling the functions described here must not call setenv(3) from a parallel thread. highly recommend only doing your setenv() calls during an early phase of the program, back when no other threads have been started yet. do it early, avoid the chaos π«Ά
π HISTORY π
sd_bus_message_get_type(), sd_bus_message_is_signal(), sd_bus_message_is_method_call(), and sd_bus_message_is_method_error() were added in version 240. a whole era.
sd_bus_message_get_error(), sd_bus_message_get_errno(), and sd_bus_message_get_creds() were added in version 246. glow-up round two β¨
π SEE ALSO π
systemd(1), sd-bus(3), sd_bus_message_new(3), sd_bus_message_set_destination(3), sd-bus-errors(3), sd_bus_error_add_map(3)
k that's the whole page, you ate that. this one's from systemd 261.3, manual page SD_BUS_MESSAGE_GET_TYPE(3) β go forth and query your message metadata, bestie ππ¦π
π¦ where this page comes from
- ubuntu stonking: libsystemd-dev 261.3-0ubuntu3 Β· LGPL-2.1-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms