- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
ew ai “””art”””
Fucking slop images contributed less than nothing to the article.
/etc/init.d, uh, finds a way
Logged logs logging loggily
Go off, king. Great points. I can’t bring myself to give a shit about anything this person has to say if they feel the need to interject Marvel quips into their own article.
this one is gonna be controversial.
Yup.
If you shoot the competitors and reject questions and dissent, then you win. Good job, IBM !
Didn’t expect this topic to still be that controversial… Maybe I’m too young to know, but how was IBM involved?
Systemd killed my father, but it’s okay because he was Darth Vader anyway.
Any recommendations for a good book or online resource to learn about systemd? Not “how to use it” or “ten tricks for systemd users”, but how it works, what makes it tick, basically a systematic overview, end then a dive into the details.
I’m not experienced at it either and don’t know the best resources.
But what I can usually recommend in case you don’t want to see the usual “THIS-IS-A-PIECE-OF-THE-PUZZLE—COME-BACK-REGULARLY-FOR-MORE-CONENT” stuff, but more in depth stuff: Enter “filetype:pdf systemd” in your search engine. Google or DuckDuckGo will then only spit out pdf files about that topic… And the people who write PDF files are usually more experienced with the topic than those who write blog posts or “how to’s”.
Let me know if that helped in your case… :)
OK, first impression: loads of PPTs turned PDF. Not a single book far and wide…
You’ve got a point here, although this topic would do well as a wiki or similar linked documents.
Diving into Systemd would be a book written by Nietzsche.
I don’t think I could name one thing that systemd improved for me. But I can name at least one major annoyance that made things worse for me.
The real issue is the backwards incompatibility which essentially forced everyone to switch instead of being able to choose.
For that alone I will keep disliking it.
Not specifically about systemd, but some things can’t be backwards compatible because they might want to just do things different.
Nobody was forced to change, the distros saw the options and decided in favor of systemd, the same they decide a million other things.
Nobody was forced to change,
Red hat dominated the market and pushed it on out. You must remember this, don’t you?
I’d encourage you to go read the discussions Arch Linux and Debian before deciding to go with systemd
I honestly don’t get what people were so up in arms about, besides just not wanting to change what already worked for them.
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’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.
Technically, sysv everything was just a file full of instructions for the shell to parse and initialize. Human readable “technically”. It was simple and light weight. SystemD is a bit heavier and more complex as a system service binary. But that load and complexity is generally offset by added features that are extremely nice to have. Providing much more standardized targets and configuration iirc.
I had to search and dig trying to figure out how to set up services properly for my distro, back in the 90s. And when/how to start/restart them. There wasn’t one way to do it all. SysD made it all much more standard, simple, and clear. It’s biggest sin, is that it’s one more binary attack surface that might be exploited.
Why are binaries uniquely attackable in a way that init scripts aren’t?
Nobody is packaging a standard init script across all distros, basically. A script is expected to be unique per machine or at least per admin setting up a set of machines. A binary could have a secret exploit installed in it that nobody can see/audit before it’s too late.
At least that’s the theory. Personally I love systemd
Init scripts are just scripts. Technically, they don’t introduce any unique vulnerabilities of their own. Just the flaws in the shell itself or server binaries. A poorly written script absolutely can and will still fuck your day up.
SystemD is a program. Which could introduce its own unique buffer overflows or use after free opportunities. I’ve not heard of any. But its possible. However, its standard set of interfaces and systems make the risks of writing your own bad scripts or just using other people’s random bad scripts like we used to much less an issue.
I haven’t been an opponent but I must admit, when you have headless machine of different arch (so no chroot) you try to make connect to LAN and start sshd, managing those links in those directories feels more like shooting in the dark. In that case simple scripts in a dir were easier
When the drama started, the argument of my anti-systemd friend was that it goes against unix philosophy of one program do one thing only. But eventually even him turned on and become a fan.
can someone please tell me how to make .mount files start at boot for smb shares ffs? is the only thing systemd is failing for me.
I dont know what you are doing, but I have my smb shares simply in fstab and never heard of any .mount file
On modern systems, fstab entries are read by systemd and .mount files are automatically created for each entry. 😄
i am making them in salt-stack systemd templates/pillars. i will see what i miss when i do a fstab one.
Systemd can use .mount files to make services and stuff depend on the availability of a mount. They can either be created by hand or are created automatically from fstab.
thanks everyone.
IIRC You simply write/change the fstab as in every system. Then you say “systemctl daemon-reload” once, and this (re)creates your .mount files. Then “mount -a” or whatever you need.
https://wiki.archlinux.org/title/Samba#As_systemd_unit
That’s the guide I followed on my desktop and laptop.
thanks,
Can you see if its trying and failing by using journalctl?
no matter what i do it only does on try.
Network not ready by time the mount is executed?
yup,
I have a service that pings the server:
cat <<EOF | sudo tee /etc/systemd/system/ping-smb.service [Unit] Description=Blocks until pinging 192.168.1.10 succeeds After=network-online.target StartLimitIntervalSec=0 [Service] Type=oneshot ExecStart=ping -c1 192.168.1.10 Restart=on-failure RestartSec=1 [Install] WantedBy=multi-user.target EOF sudo systemctl enable ping-smb.serviceAnd then I make the fstab entry depend on it:
x-systemd.requires=ping-smb.serviceI had something similar when I used to mount an NFS share. I had a bash line that would loop ping and then mount once ping succeeds. Having a separate service that pings and making the mount dependent on it is probably the better thing to do. Should also work when put in
Requires=in a.mountfile.
