multirun VS systemd

I recently switched to multirun [1] which in my case is superior to supervisor. I don't have to create any config files anymore, and it behaves exactly as i want it to: If one on the processes dies the complete container will die and docker's restart-policy takes place.

[1] https://github.com/nicolas-van/multirun

Personally, it's not that the alternatives are so awesome.

It's when i meet against some awful design choices in systemd, like how it decides to wait forever rather than hard fail, and by wait forever, i mean wait for 30 seconds, no, 1 minute 30 seconds, no 5 minutes... you get it.

Or you can easily lock yourself out when there's a typo in /etc/fstab.

Or the hardcoded 5 minute timeout for sysv-generator: https://github.com/systemd/systemd/blob/main/src/sysv-genera...

God forbid you used cgroupsv1 for anything when poettering unilaterally decided to punish everyone with a 30 second delay for using it.

If you stray off of the intended opinionated path, be prepared for the least user-friendly experience linux has to offer. You might even get some abuse from the developers if you try to ask for help, but they've probably toned it down since CoC became a thing (I hope).

You might wonder why we use Supervisor instead of alternatives like Systemd, PM2, or containerized solutions like Docker. Here’s a quick comparison:

> You cannot use it for values that you want to return from the function

I would say this is only half true. With some macro magic you can actually also return the values :)

https://github.com/systemd/systemd/blob/0201114bb7f347015ed4...

To be fair though, you probably meant without any such shenanigans.

tbf this is a really common pitfall and arguably a design mistake in Linux/POSIX, opening files should be a straightforward operation without pitfalls. Even established programs mess this up all the time, see https://github.com/systemd/systemd/issues/30690 and https://github.com/magic-wormhole/magic-wormhole/issues/363

It looks like systemd-nspawn is gaining rootless support, see https://github.com/systemd/systemd/issues/30239

Until then, I'm not sure if there is anything lightweight. If you don't need lightweight, there is Podman.

As per the article mentions of resolving AAAA IPv6 records, a feature was just merged into Linux's systemd-resolved last week.

https://github.com/systemd/systemd/pull/34165

So you can do.

RefuseRecordTypes=AAAA

So there, your DNS won't ever query for IPv6 AAAA records.

(in fact you can refuse any DNS questions like MX, SRV, TXT as well with:

RefuseRecordTypes=MX SRV TXT)

Note - I started adding that feature because some applications were "misbehaving" and querying AAAA records when IPv6 stack was disabled.

On Linux, a privileged process can change the memory address which the kernel (/proc filesystem) reads argv/etc from... prctl(PR_SET_MM) with the PR_SET_MM_ARG_START/PR_SET_MM_ARG_END arguments. Likewise, with PR_SET_MM_ENV_START/PR_SET_MM_ENV_END.

The API is ugly, and since it needs CAP_SYS_RESOURCE many programs can't use it... but systemd does: https://github.com/systemd/systemd/blob/2635b5dc4a96157c2575...

This shouldn't cause the kind of race conditions we are talking about here, since it isn't changing a single arg, it is changing the whole argv all at once. However, the fact that PR_SET_MM_ARG_START/PR_SET_MM_ARG_END are two separate prctl syscalls potentially introduces a different race condition. If Linux would only provide a prctl to set both at once, that would fix that. The reason it was done this way, is the API was originally designed for checkpoint-restore, in which case the process will be effectively suspended while these calls are made.

The article doesn't even mention this: systemd is not well written software, and far from behaving robust and consistently. Take some time, look through the currently open issues on Github, see for yourself whether you consider this stable software. Machine hanging indefinitely during poweroff/reboot is one of the classics.

[1] https://github.com/systemd/systemd/issues

Idk, when systemd became the main thing I hated it too. But mostly because it was different and I didn't know how to use it. But then I learned and you know what? I agreed. This took awhile though and I had to see the problems they are solving. Otherwise it looks really bloaty and confusing. Like why have things like nspawn? Why use systemd jobs instead of using cron? Why use systemd-homed instead of useradd?

Well a big part of it is security and flexibility.

I write systemd services now instead of cron jobs. With a cron job I can't make private tmps[0]. Cron won't run a job if the computer is off during the job time. Cron can't stagger services. Cron can't wait for other services first. Cron can't be given limited CPU, memory, or other resource limitations.

Nspawn exists to make things highly portable. Chroot on steroids is used for a reason. Being able to containerize things, placing specific capabilities and all that. This is all part of a systemd job anyways. It really makes it a lot easier to give a job the minimum privileges. So often nspawn is a better fit than things like docker.

Same goes for homed. You can do things like setting timezones unique to users. But there's so much more like how it can better handle encryption. And you can do really cool things like move your home directory from one machine to another. This might seem like a non-issue to most people but it isn't. That whole paradigm where your keyboard is just an interface to a machine (i.e. a terminal, and I don't mean the cli. There's a reason that's called a terminal "emulator"). This is a really useful thing when you work on servers.

Look, there's a reason the distros switched over. It's not collective madness.

[0] https://www.redhat.com/en/blog/new-red-hat-enterprise-linux-...

https://systemd.io/

We all know that systemd and dbus are beast of their own, but what I didn't know was that just a simple change on our own service files would lead me to hours of exploration, some documentations that are not properly documentated (don't judge, we all have done that.), and to my surprise, the answer again was very simple.