Systemd isn’t just for booting, we used it for streaming tool

There are many ways to get a video stream going, be it with a camera feed, a media file, or something else. In our case, we already had RTSP streams coming in. What we really needed was a way to push those streams to an RTMP destination.

So the actual streaming part was fairly straightforward. But the real challenge lies in figuring out how to manage each stream session, how to start it, stop it, monitor it, and recover it if something goes wrong. We wanted something simple, reliable, and easy to maintain.

Exploring our options for managing streams

With several tools and approaches available, we had to decide how best to manage the streaming process. Should we build our own process manager? Lean on containers? Or use something already available and integrated into the system? Here’s how we looked at our options.

Option 1: Build Your Own Process Manager

Yeah, you could roll your own process manager. But that means writing a bunch of code to manage processes, restarts, logging... all that stuff. Way too much work for what we needed. So that was a no from us.

Option 2: Containers, like Docker

Docker’s nice. It gives you isolated environments, decent logging, and makes it easy to run stuff. But it’s missing a few key things for us, like setting a timer for how long a process should run, or automatically restarting it if it crashes. Sure, you could hack that in, but again… more work.

Also, containers just have more overhead. For a small task like relaying a stream, starting a whole container feels like too much. With systemd, we’re just running a normal process on the system; it’s faster, simpler, and gets the job done without all the extra layers.

Option 3: Systemd Transient Units

If you’re into Linux, you’ve probably run into systemd. Maybe you love it. Maybe you hate it. Either way, it turns out to be super useful for what we wanted.

Systemd is what boots up your Linux app or service and starts all the background stuff. But it can also manage processes in a really clean way. What makes it even cooler is that you can create “transient units” on the fly, meaning no need to write config files. Just spin up a service with a command and you’re good to go.

From a low-level point of view, systemd uses the same stuff containers use, like cgroups, to manage resource usage for each process. Plus, it comes with built-in logging via journald, and you can even control how long logs stick around.

Here’s what we liked about it:

• Timers – We can limit how long a stream runs.
• Automatic Restarts – If something crashes, systemd brings it back up.
• Logging – We didn’t need to set anything up; the logs were just there.

People complain about systemd being bloated, but honestly, we’re fans.

How Our Streaming Service Works

The architecture is dead simple:

• A stream request comes in.
• Our backend spins up a systemd transient service just for that stream.
• If it crashes? No worries, systemd restarts it.
• We can also set resource limits so one stream can’t hog all the CPU or RAM.
• Logs? Already handled by systemd.

And because systemd is native to basically every Linux distro, it’s fast and super lightweight.

The Downsides

Of course, it’s not perfect. Here are a couple of things we ran into:

It Only Works on One Server

Systemd is great on one box, but it doesn’t know anything about other machines. So if you’re trying to scale across multiple servers, you’ll need to build some of that logic yourself. Tools like Kubernetes handle this out of the box; systemd doesn’t.

What this means:

1. Scaling to multiple servers is harder.
2. If a server dies, you have to handle recovery manually.

Limited Management Tools

Systemd comes with basic CLI tools (systemctl, etc.), but not the fancy APIs or dashboards you get with container platforms. So if you want to build a UI or API to monitor your services, you’ll need to write more custom code.

What this means:

1. Harder to build management interfaces.
2. Might need to script your way around some stuff.

Could you build a scalable, multi-machine setup with systemd? Yeah, totally. But honestly, spinning up Kubernetes might be easier at that point.

Not as Isolated as Containers

While systemd does use cgroups to manage resource usage, it doesn't provide full isolation like containers do. You don’t get separate filesystems, network namespaces, or full process isolation. For us, that wasn’t a dealbreaker; we didn’t need total sandboxing, but if you're running untrusted code or want stronger boundaries between processes, containers are the safer bet.

What this means:

1. Processes can still see and affect the broader system.
2. Not ideal for running untrusted or user-submitted workloads.
3. Security boundaries are weaker compared to containers.