- cross-posted to:
- selfhosted@lemmy.world
- cross-posted to:
- selfhosted@lemmy.world
After a few conversations with people on Lemmy and other places it became clear to me that most aren’t aware of what it can do and how much more robust it is compared to the usual “jankiness” we’re used to.
In this article I highlight less known features and give out a few practice examples on how to leverage Systemd to remove tons of redundant packages and processes.
And yes, Systemd does containers. :)
You must log in or register to comment.
Do we have to bring this up again? It’s just boring.
systemd is here and it isn’t going anywhere soon. It’s an improvement over SysV, but the core init system is arguably less well-designed than some of the other options that were on the table 10 years ago when its adoption started. The systemd userspace ecosystem has significantly stifled development of alternatives that provide equivalent functionality, which has led to less experimentation and innovation in those areas. In many cases those systemd add-on services provide less functionality than what they have replaced, but are adopted simply because they are part of the systemd ecosystem. The core unit file format is verbose and somewhat awkward, and the *ctl utilities are messy and sometimes unfriendly.
Like most Red Hat-originated software written in the last 15 years, it valiantly attempts to solve real problems with Linux, and mostly achieves that, but there are enough corner cases and short-sighted design decisions that it ends up being mediocre and somewhat annoying.
Personally I hope that someone comes along and takes the lessons learned and rewrites it, much like Pulseaudio has been replaced by Pipewire. Perhaps if someone decides it needs rewriting in Rust?
The core unit file format is verbose and somewhat awkward, and the *ctl utilities are messy and sometimes unfriendly.
While I agree with the rest I don’t particularly believe in this. The unit format is well structured and solves many pitfalls of previous approaches, it also supports configuring a myriad of different things from mounts to sockets and the network in a nice way.
I find systemctl to do a much better job than any alternative that comes stock with distros. I’m looking at you service
deleted by creator
Thanks for summarizing my feelings on systemd in a less inflammatory way than if I had written it myself.
I’ve found that most distributions have implemented it properly and for the most part it works quite well and stays out of my way, it’s only when for some reason you have to dive into the minutiae of a unit file and getting into all the dependencies and stuff that it gets annoying quickly.
The dependency system takes a bit to understand but compared to like upstart it was a massive improvement.
Everybody gangsta until
A start job is running for ... (10s / 1min 30s)Or, even worse,
A start job is running for ... (10s / no limit)lol, that brought back memories
I don’t see how exactly that is systemd’s fault.
You are blaming it for having proper dependency handling?
I’m blaming it for making it a pain in the ass to debug dependency problems and for having the confusing, non-intuitive, overly verbose and redundant syntax that probably caused the problem in the first place.
Like, who the hell can memorize all the subtle differences in behavior between
After=,Requires=,Wants=,Requisite=,BindsTo=,PartOf=,UpHolds=and then all their “reverse” equivalents?You’re right that the difference isn’t overly obvious. However, for most services,
Wants=is enough. I think some of these (likeRequisite=) came from actual users’ demands where they had to solve corner cases in their setup that systemd did not allow with the existing features. I think especiallyUpheldBy=is a smart addition; it adds restarting to a service only if that services is used as a dependency for the one it upholds.
I installed OpenBSD and never looked back. This isn’t an option for everyone but I encourage those who have these kinds of feelings to have a look.
One of the big complaints of systemd detractors I read is that it’s “monolithic” and “taking over everything” and this “shouldn’t all be part of init”
You might want to point out that all the features outside of systemd-as-init are optional and can be replaced or ignored if you don’t want them. They also don’t run as PID 1
You do have to use systemd-journald, but you can also just forward it to syslog if you want
all the features outside of systemd-as-init are optional and can be replaced or ignored if you don’t want them
Yes, but the point of the article was kind of the opposite - simply try all the systemd tools and components and see how much better things can get.
Sure, but if you’re trying to convince the groups that hates systemd, a preamble of “these don’t run in PID 1 and are just extra features you might find useful” could help
That’s fair.
yeah but the OP’s point was not
systemd brings much functionality. It can’t follow unix philosophy because unix is 50 years old. the whole community drama about this systemd VS sysV VS OpenRC VS whatever comes up, is funny. There are distros that are systemd-free if you wish so much to avoid it.
There are shrinking in numbers, especially for mainstream distros, tho…
deleted by creator
This was refuted long ago. Systemd isn’t a single binary file doing everything, it’s a project that has many different binaries doing many different things. The only difference is that they are developed under one project to ensure they integrate well with each other. What your doing is like complaining that glibc tries to do everything, I mean it does open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit and more… Xorg would be another example of a project that does many things instead of one very well.
Splitting something into multiple executables doesn’t make something not monolithic just like splitting a program into multiple source files doesn’t make it not a monolith. It’s not a monolith when the different component parts can be cleanly factored out, replaced, and used outside of the original context or with different versions of related components This is in fact very hard. Much harder than making a monolith.
For instance the X11 ecosystem isn’t a good example of a monolith because its designed to make it trivial to swap in different loosely coupled components. You don’t worry about needing your window manager and X11 to come from the same commit so they actually work. You can argue that the toolbox that systemd provides it is worth it but arguing that it’s not a monolith just screams I’m not a developer.
Finally a systemd praise post after so many hateful remarks. I knew systemd could do dns resolving but just learned it could handle the entire network stack and replace NetworkManager. I have a question: How can services such as Apache adapt to both NM and systemd at the same time? NM and systemd have different wait-online services. You can also add systemd-analyze for boot time analysis to the list.
How can services such as Apache adapt to both NM and systemd at the same time? NM and systemd have different wait-online services
If you look at the systemd unit for Apache you’ll just find
After=network.target- it doesn’t wait-online at all. Apache doesn’t really care if you’re using NM or systemd-networkd, it simply queries the system (like theipcommand does) to know what’s going on with the network. It was designed as recommended for moderns programs: it is aware that your network might change and listens for the appropriate signals and takes care of the binds dynamically.I knew systemd could do dns resolving but just learned it could handle the entire network stack and replace NetworkManager.
It depends on your use case. I have three machines and use NetworkManager on one of them and systemd-networkd on the others. The latter is great for static configurations, but for a notebook that roams WiFi networks, it doesn’t make the most sense.
systemd has made my life so much easier in so many ways. Other people prefer messing with bash files and there are definitely better alternatives for services like systemd-resolved, but basic service and timer management has improved massively.
I wish there was a good GUI for systemd, though. A lot of configuration options have moved to systemd files now, and for novices it’s hard to find what file does what and how to configure them. Several Linux distros and desktop environments have their own tools that read from/write to systemd files, but they’ll always lag behind the actual systemd resources.
I think an official systemd GUI to manage services and networks would make Linux a lot more usable for people with some computer knowledge but no time or interest in reading man pages. I’d imagine some kind of GUI like Windows has for system services (titled “advanced system settings” or whatever) that can do things like manage network adapters, alter DNS config, start/stop/enable/disable services, the whole deal.
imagine some kind of GUI like Windows has for system services
The problem is that systemd has so many possible options and ways to do things that you’ll either end up with something that “lags behind the actual systemd resources” or a glorified text editor specially made to write systemd units.
deleted by creator
What about entire optional sections? Multiple options with the same name etc?
If systemd can parse them, the GUI can list them. A simple list view with add/edit/delete would work just fine.
Microsoft solved this problem decades ago:
Good old Win32 GUIs with their tabs can do anything. Too bad people don’t want those anymore.
People have been making services for decades and systemd is 13 years old. I kind of feel like it probably has virtually all of the options its ever going to have. Also most of what people would use such a GUI for is to start stop restart enable disable the thing people have been doing for an eternity which doesn’t require even displaying the unit file.
Very interesting article with lots of links that I’m sure to revisit often. I use Linux daily and was not aware of all the possibilities that systemd has to offer.
Some of the cruft I use nowadays to manage Linux machines can be optimized by simply moving over to the systemd equivalent. Of particular interest to me are: triggers, timers, file monitoring, and ntp.
Thank you. NTP and DNS are the easiest to get into. Simply enable the services and move on.
I stopped using resolved as it tends to ignore what I tell it to do and still grab DNS from the router which I don’t want and can’t disable on the proprietary router.
openresolv/Resolveconf was never broken in the first place so I’m not sure what systemd was trying to fix with this.
That’s most likely because… you didn’t read the manual! :D
FallbackDNS= A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Please see DNS= for acceptable format of addresses. Any per-link DNS servers obtained from systemd-networkd.service(8) take precedence over this setting, as do any servers set via DNS= above or /etc/resolv.conf.
Assuming your network is DHCP, edit your config eg.
/etc/systemd/network/10-eth0.network:[DHCPv4] UseNTP=no UseDNS=no UseHostname=noYour system will not pick NTP and DNS servers and also ignore the hostname provided by the router. Also make sure you
ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.confhttps://www.freedesktop.org/software/systemd/man/systemd.network.html#[DHCPv4] Section Options
deleted by creator
not even that for ntp you just set it with timedatectl
systemd-nspawn is basically chroot but better
Way, way better. Nowadays its more “basically” LXC. :P
Having choice is the best part of Linux, but Systemd is something so ubiquitous to Linux that it might as well be called Systemd/Linux instead of GNU/Linux.
When you think of it like that, it feels much less like a bloated behemoth that needs to be de-monopolised and more like an integral piece of the puzzle that is turning the Linux kernel into an functional operating system.
systemd-kerneld 😜
systems always implies Linux, but Linux doesn’t necessarily imply systemd.
I always try to cover most of my stack with systemd components because they actually tend to be quite sane with a very transparent configuration. It’s no surprise a lot of distributions picked it up. As you said, it does exactly that, make an OS based on Linux easily available. Sure you can do the same with a variety of other tools, but just letting systemd do the heavy lifting for you sure is tempting.
That doesn’t mean it’s the only choice. I’d love to try Chimera Linux one day which doesn’t include systemd (in fact it doesn’t include a lot of stuff most other distributions do) but it ticks a lot of boxes for many.
systemd is great, but being disingenious isn’t helping anyone:
chrony -> sd-timesyncd […] one less daemon
just because it ships with systemd doesn’t mean it magically runs without it’s own process
chrony -> sd-timesyncd […] one less daemon
Thanks for pointing that out, it was out of place. :)
Pretty sure that’s how the Steam Deck runs also. At least every custom OS I’ve seen for it is just a ContainerFile and systemd-boot
ah soft reboot ive been waiting for something like that
Very cool. I had no idea systemd sort of has a cron replacement. While in I don’t think I’ll switch from cron in the immediate future, it’s really good to know.
Systemd timers are way, way better than cron. Because can audit them, view when they last run, next expected run, can be set to persist with reboot or not, aggregate logs under journalctl, can do amazing things such as “x minutes after boot”, can be configured not to run again until the last run is complete etc… https://opensource.com/article/20/7/systemd-timers
Fully agreed. But I know how to use cron, I have a life to live, and this switch is way down the priority list.
But it is something I’d like to find the time to do at some point.
Well if it makes you more comfortable let me tell you that the format of
OnCalendaris the same, or very close. I bet that just by looking at the following you know what is does![Unit] Description=Logs some system statistics to the systemd journal Requires=myMonitor.service [Timer] Unit=myMonitor.service OnCalendar=*-*-* *:*:00 [Install] WantedBy=timers.target
You can do most of that with cron as well https://man.archlinux.org/man/fcrontab.5.en. If you want details about successful runs I think you would have to ensure you always logged.
And yes, Systemd does containers. :)
Are systemd duplicates such as containers and systemd-boot are better than the existing ?
It isn’t always about being better. Docker has its use cases more for single binaries, LXD provides a nice interface while
systemd-nspawnis built in and allows you to setup containers with a a common and known unit file. It also allows you to control the containers with the same systemd tools you use for your host machine, zero learning curve and you’re less likely to have to enter containers. Another example, I might not want to install LXD/LXC on a low resource system as it will bring snap and waste resources and systemd fixes that.
All of this shit packed in is why it sucks. Do one thing and do it well. Try setting up a script to run on boot that doesn’t stop executing until you want to turn your pc off and watch all traces of sanity drain from your being. Now try it on freebsd. Much much easier
What’s the problem with that script? That’s such a basic use case and not very hard to do at all in systemd.
Where do you struggle with it? Can we maybe help with something?
Did a couple of times, no issues. Simply add
KillSignal=SIGINTorExecStop=/bin/kill -s SIGINT -$MAINPID & /bin/kill -s SIGINT -$MAINPIDand it will work out.
Systemd together with NetworkManager are two pieces of software I really dislike. They go against the very Unix philosophy. I like being able to piece all the bricks together on my own, not having monolithic pieces of software that try to do everything.
Why using Linux kernel then, install GNU/Hurd…
You make it sound as if it’s a religion … UNIX isn’t a dogma handed down by an infallible being, just a piece of software that made sense for its time. Todays needs are different than the needs 40 years ago, so ofc things have to change.
Eh, they work for me. To each their own.
