5

(In the context of reading about the systemd D-bus implementation called sdbus (full sdbus API here)):

What does "OOM-safe" mean?

From this blog post, by Lennart Poettering, the author of systemd and sdbus: The new sd-bus API of systemd (emphasis added):

Of the two libdbus is the much older one, as it was written at the time the specification was put together. The library was written with a focus on being portable and to be useful as back-end for higher-level language bindings. Both of these goals required the API to be very generic, resulting in a relatively baroque, hard-to-use API that lacks the bits that make it easy and fun to use from C. It provides the building blocks, but few tools to actually make it straightforward to build a house from them. On the other hand, the library is suitable for most use-cases (for example, it is OOM-safe making it suitable for writing lowest level system software), and is portable to operating systems like Windows or more exotic UNIXes.

And:

To be able to use it in systemd's various system-level components it needed to be OOM-safe and minimal.

I don't just want the acronym meaning, but I need that too. Expound a bit please.

Also, I don't even know what to put for a tag here (someone please help me out and edit the question to have the right tags).

Two of my ideas on what "OOM" stand for are "Object Oriented....Mmmmm (something)" and "Out of Memory".

Further reading on sdbus: this online markdown book here: https://gitlab.com/franks_reich/systemd-by-example#52-systemd-dbus-library-sd-bus

Improve this question
1

1 Answer 1

Reset to default
14

OOM in this context means "out of memory", and "OOM-safe" means that the code is written to explicitly handle low memory situations where malloc() may fail.

That means: the code always checks the return value of malloc() and does something sensible when null is returned.

Most code is not really OOM-safe, it may check for an OOM situation when it does something "big", but small allocations are typically expected to succeed.

This is because it's really annoying (and would lead to ugly, cluttered code) to handle the possibility of running out of memory everywhere and in many cases it is not at all obvious what to actually do in that situation. For many user applications, it is acceptable to have them crash when there really is no memory available.

But for low-level system code, as stated in your quotes, it is necessary to handle low memory conditions everywhere. Because if it crashes, the whole system does, or becomes unusable.

Improve this answer
3
  • 2
    .. however, Linux malloc() never returns null, it will overcommit instead. So I wonder if they've done something else to ensure that systemd continues to operate in OOM situations.
    – pjc50
    Commented Mar 25, 2022 at 12:59
  • @pjc50, I wonder if they're using a statically-allocated or allocated-during-initialization memory pool or something.
    – Gabriel Staples
    Commented Mar 25, 2022 at 13:40
  • @pjc50 That depends on your configuration. Part of the problem is that fork+exec or fork+work is historically common, and was once the proper (aka only) way.
    – Deduplicator
    Commented Mar 25, 2022 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.