It uses a completely different paradigm of process chaining and management than POSIX and the underlying Unix architecture.
That’s not to say it’s bad, just a different design. It’s actually very similar to what Apple did with OS X.
On the plus side, it’s much easier to understand from a security model perspective, but it breaks some of the underlying assumptions about how scheduling and running processes works on Linux.
So: more elegant in itself, but an ugly wart on the overall systems architecture design.
It uses a completely different paradigm of process chaining and management than POSIX and the underlying Unix architecture.
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.
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.
Do you mean a hang on boot when trying to mount? For that I use the nofail option in fstab. I also use the x-systemd.automount option so if something is not mounted for whatever reason, it tries to mount it when something attempts to access it.
That’s all handled with adding the x-systemd.automount option 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.
It uses a completely different paradigm of process chaining and management than POSIX and the underlying Unix architecture.
That’s not to say it’s bad, just a different design. It’s actually very similar to what Apple did with OS X.
On the plus side, it’s much easier to understand from a security model perspective, but it breaks some of the underlying assumptions about how scheduling and running processes works on Linux.
So: more elegant in itself, but an ugly wart on the overall systems architecture design.
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.
Lol, no. Way more code in Systemd. Also more CVE per year than in some bad (now dead) init/svc’ lifetime.