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.
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.
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
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.
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.
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.
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.
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
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
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.
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
deleted by creator
Where are those alternatives? I have not seen anything that is Baustoff convincing yet…
It is not a project owned by redhat… the lead guy not even works there anymore. So the more interesting question is: What happens if Microsoft closes down the project? The answer: It will be forked.
deleted by creator
We fork it… like people are doing with LXD/LXC… https://linuxcontainers.org/incus/
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
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.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?
systemd is cancer.
And it would be cancer because…?
Same reason as for all those years these old people are holding a grudge for…
It is not Unix philosophy (nothing is these days), it does not solve any problem they ever had (it does), it is no improvement over what we had before (it is) and even makes some broken and moronic things harder (it does), it is insecure (it improves overall system security), and it is one monolithic blob (it is not). Before systemd nothing depended on the init system (true, but then it did nothing useful that made having such a dependency worthwhile), and before systemd we were all free to use other init systems and distributions did not pick one for their users (they always did, offering additional inits only as unsupported iption just likenthey do now).
That’s the typical list you get.
Oh, and it was shoved down all our throats by the mighty Lennart himself, backed by several multi billion dollar companies that brided thousands of distribution developers to destroy Linux (it was not).
Funnily enough it is pretty much the same BS we had when that monster of complexity called sysv init was introduced into distributions, replacing a simple script with a forest of symlinks. Of course the community was much smaller then and so we had a loser number of idiots to shout at everybody else.
It seems that, in many people’s view, it’s better to have janky scripts starting systems, having to delegate logging management and service monitorization to the services themselves or cumbersome tools poorly used by most distros such as logrotate? Systemd offers a good thing, easy configuration and IT DOES fix a LOT of issues. People who never tried it won’t see how better it is, just try it… like I did 10 years ago.
One of the moments where we see the true power of systemd is when we use it for containers and suddenly realize that the tools used to manage the system such as
systemctlandjournalctlcan be used to inspect and affect a container without even having to enter it. Another equally interesting moment in the systemd journey is when you’ve an ARM system with 512MB of RAM or even less and you figure out that it will save you precious resources for other things.Not at all: I listed the arguments you will get for that question of yours. They all are bogus, as I tried to explain between the parens.
I also updated my reply to make it more clear. It wasn’t “aimed at you”.
http://web.archive.org/web/20140428103624/http://boycottsystemd.org/
Just to name a few reasons.
The fact the original website is no longer available tells us a LOT about it. Maybe the server running it crashed because it didn’t have proper service monitoring… or all the init jankiness was wasting so much resources the guy paying for the server run out of money :D
Now in all seriousness: I don’t disagree with most points however, systemd also provides a TON of functionally that was never this easy and stable. Also if you consider the grand scheme of things Docker and whatnot are a bigger virus than systemd is or will ever be and the irony is that systemd does run containers with less overhead :).
No need to drag that BS from the archives. It was never correct nor convincing.
How on earth can you say that? Systemd, while not perfect, creates a system that helps newbies come in and understand Linux, helps Linux grow. Afterwards they can shift to a non systemd distro, but systemd provides a valuable tool.
Hmm that’s an interesting take on systemd. Not sure if anyone would be pivoting to a non-systemd distro after experiencing it… Well I’ve been using Linux before systemd and I wouldn’t switch back to what we had before simply because it makes my life easier in so many ways.
But yes, I see how less fragmented and more approachable a systemd distro will look for a beginner.
creates a system that helps newbies come in and understand Linux, helps Linux grow.
Not sure about this.
A new user probably don’t care (and rightly so) about how a certain service is started or stopped, it just need to work, which was true even before systemd.
Actually, its an opaque system that makes it much harder to understand what is going on because it’s a declarative file that is consumed in a non-obvious way by code written in c which is not going to be remotely comprehensible to them. Most people are apt to google for the magic incantation that appears to match their problem without understanding anything.
Not only are simple and easy not the same they are opposing interests in most actual practices.
I had an extremely simple Funtoo (Gentoo derived) installation it had bios boot -> 4 line grub.cfg with explicitly specified kernel and initrd. Making a kernel involved cding to the directory where the new kernel was making it copying a file and changing a text file to point to the new kernel. Understanding how software was built was work because you actually have to specify things you want vs don’t want but it was extremely simple. In fact everything was like that from boot, build, services. Anyone who took a few hours could probably trace it from the first line of grub.cfg to the last service starting up.
I have a more complicated void install that uses rEFInd -> zfsbootmenu . When a new kernel is installed dkms rebuilds modules and dracut handles preparing the boot up, updating automatically creates a snapshot and zfsbootmenu makes it possible to boot into a prior version of your OS. I set none of it up it was configured by an installer and when I messed something up it was a LOT more work to understand how it works and it was impossible to trace it from end to end without googling and reading documentation.
I have a single board computer running a derivative of Ubuntu. The official installation procedure that you are supposed to be able to do remotely doesn’t work at all so I plugged a monitor and keyboard to it loaded the image to a sd card and booted and ran the commands it said to run and it works without issue. It’s opaque but easy to use and if it ever doesn’t I’ll probably just reinstall the image from scratch and run the commands it said to run.
I would recommend Ubuntu/Mint if you just want to do things. If you actually want to understand it for its own sake I would recommend something simple instead of easy.
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…
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. :)
