140
systemd has been a complete, utter, unmitigated success
(blog.tjll.net)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 20 Feb 2026
140 points (71.3% liked)
Technology
81709 readers
3594 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
I think that's exactly it for most people. The socket, mount, timer unit files; the path/socket activations; the
After=,Wants=,Requires=dependency graph, and the overall architecture as a more unified 'event' manager are what feels really different than most everything else in the Linux world.That coupled with the ini-style VerboseConfigurationNamesForThatOneThing and the binary journals made me choose a non-systemd distro for personal use - where I can tinker around and it all feels nice and unix-y. On the other hand I am really thankful to have systemd in the server space and for professional work.
I'm not great at any init things, but systemd has made my home server stuff relatively seamless. I have two NASs that I mount, and my server starts up WAY faster than both of them, and I (stupidly) have one mount within the other. So I set requirements that nasB doesn't mount until nasA has, then docker doesn't start until after nasB is mounted. Works way better than going in after 5 minutes and remounting and restarting.
Of course, I did just double my previous storage on A, so I could migrate all of Bs stuff back. But that would require a small amount of effort.
what do you use as a prerequisite for the nas A mount? or does it iust keep trying in a loop?
I have a wait-for-ping service that pings nas A, once it gets a successful response it tries to mount.
I lifted it from a time when I needed to ping my router because Debian had a network-online service bug. I adapted it to my nas because the network-online issue eventually got fixed and mounting my shares became the next biggest issue.
It seems like this person might have grabbed that same fix for what I eventually did because our files are...oddly almost exactly the same.
https://cweiske.de/tagebuch/systemd-wait-nfs.htm
thanks!
do you perhaps also have a solution for hanging accesses to network mounts when the server is inaccessible?
Do you mean a hang on boot when trying to mount? For that I use the
nofailoption in fstab. I also use thex-systemd.automountoption so if something is not mounted for whatever reason, it tries to mount it when something attempts to access it.no, I mean the system has been up for a long time, but the server went down, and connection was lost
That's all handled with adding the
x-systemd.automountoption to my fstab entry. If it disconnects it's unmounted, when it's available again it mounts when something tries to access it.I have occasionally needed to restart some services if they didn't like getting disconnected, but as far as mounting goes it's handled pretty smoothly with that option.
I've started doing podman quadlets recently, and the ini config style is ugly as hell compared to yaml (even lol) in docker compose. The benefits outweigh that though imho.
I agree that quadlets are pretty ugly but I'm not sure that's the ini style's fault. In general I find yaml incredibly frustrating to understand, but toml/ini style is pretty fluent to me. Maybe just a preference, IDK.