I would have already switched, but, apparently, the pipewire authors decided it shouldn't daemonize properly:

https://dev1galaxy.org/viewtopic.php?id=5867

Taking a dependency on systemd is a strange choice for a project who's entire point is ripping out Poettering's second-to-last train wreck.

That doesn't read like taking a dependency on systemd. Rather, Pipewire doesn't have custom code to "daemonize" by itself.

Is there any reason why all individual tools should learn how to daemonize (in addition to or in replacement of running in the foreground)? There's external tools that can take care of that uniformly, and using the latest/greatest syscalls for it. That seems better than every application including this code. As highlighted in the thread, there are other programs that can launch+daemonise another a process (like the aptly named [daemon(1)](https://manpages.debian.org/unstable/daemon/daemon.1.en.html) tool). Seems more like the UNIX way, from the outset.

That tool’s RSS is somehow 170KB (vs zero for a self-daemonizing process).

Also, it’s incredibly complicated. (I looked at the source.)

Here’s a writeup of a simple daemon: https://pavaka.github.io/simple-linux-daemon-tutorial/

Given that it’s typed once (by the daemon author, and not the end user), it seems like a big win vs. daemon(1) to me.

> That tool’s RSS is somehow 170KB (vs zero for a self-daemonizing process).

Why is the RSS relevant? I assume it doesn't need to keep on running. Also, even if it kept running, 170KB is not the end of the world.

> Also, it’s incredibly complicated. (I looked at the source.) Here’s a writeup of a simple daemon: https://pavaka.github.io/simple-linux-daemon-tutorial/

Maybe it's complicated, but perhaps it's trying to replicate daemon(3) without bugs, and for different processes. See the BUGS section in the daemon(3) man page.

> Given that it’s typed once (by the daemon author, and not the end user), it seems like a big win vs. daemon(1) to me.

This seems like a false comparison. It's not the case that the end user writes the code to daemonise in the non-included case. The user would just use daemon(1) or systemd(8) or something else that can daemonise. Or perhaps a service manager that doesn't need to daemonise, like runit(8) (https://smarden.org/runit/) and its ilk.

The more I read about this, the more I want to know why it's so important that pipewire is running "daemonized" (whether it does it itself or not). Can you explain the advantages and disadvantages?