zectl VS systemd

I came across zectl (https://github.com/johnramsden/zectl/blob/master/README.md) but found the docs quite sparse.

I've been trying to install it on ZFS root with systemd-boot but also have something like zectl for picking snapshots at boot time, so far no luck, seems hella complicated

You'll have to give up GRUB to use zectl . I believe it only works with systemd-boot. I don't know how well it supports multiple operating systems on the same pool. I don't know if your pool can be encrypted.

If you use a tool such as zectl for boot environments, then datasets that don't hold system data like rpool/ must be out of rpool/ROOT.

Anyone using this? https://github.com/johnramsden/zectl

If that doesn't appeal to you, you might want to consider zectl or bieaz. I know zectl has an AUR package, at least.

Is this a reference to https://github.com/systemd/systemd/issues/5644#issuecomment-... ?

ah maybe there's a fully rootless option recently too

https://github.com/systemd/systemd/issues/30239

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