systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run globally to the front of the filename". it's provided an extensible platform with which higher level orchestration frameworks like ansible / ignition can easily templatize services or other system configuration.
since the beginning of systemd people have moaned about how complex it is and how we're reinventing the wheel. yet time and time again the people actually working on the project show that the solution they've come up with is the result of the problem they're facing on a daily basis. it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back", maybe think about whether or not you have a legitimate issue not being addressed by the solution proposed or if you are just getting rage baited by a headline.
This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename.
The init system was probably peak of systemd, after that they started reinveting things in a more complicated way. Do we really need journald, systemd-boot, machinectl, systemd-networkd, sd-bus, systemd-resolved, systemd-nspawn? Do people actually use it all? Are there any metrics to show how many systems have it installed and in use?
journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there.
My memory of this time was that every single application had its own unique method of handling logs and its own unique location for storing them. So sure, once you found the logs you didn't have to Google how to find the relevant dates if the application is using logrotate as you describe, but finding the logs in the first place was always a challenge. Systemd is nice in that it provides a single place where all logs go and a single interface for navigating them.
I think my biggest gripe with journalctl is (and this may just be because I'm novice at using it) that discovering what sort of logs are on the system feels a lot more complex.
With regular logs, I can go to /var/log, ls the dir, and get a nice list of what's being logged. There will be, for example, an `apache.log` file that has all the logs relevant to apache.
It's just journalctl -u apache -f, assuming your distribution calls the unit file "apache", and the last few messages of the logfile appear with systemctl status apache
And you don't need to worry about "is this service rotating logs appropriately?"
The important thing for me at least isn't he `-u apache` but rather knowing that `apache` exists as one of the installed services on this box.
In the old ways, that was apparent because of the presence of the log file.
Granted, this isn't the problem it used to be for us, however, it would come up because we'd have our services named things like `foo-ws` and knowing that `foo-ws` existed on a given box might be tricky were it not for the log files.
In which shell?
bash & zsh are supported by upstream: https://github.com/systemd/systemd/tree/main/shell-completio...
Works in fish, I'll have to remember that one
With `ls -l` I can see file modification dates. How do I do it with journalctl? And why do I need to that that in the first place?
Journald would be perfect if I didn't have to know a thing about it. Work in background, move stuff from stdin/stdout to /var/log/journald/service.log, move old stuff in /var/log/journald/archive/service/2024-04/15.log.gz. I'd be happy. Why do I need this cryptic CLI I don't understand. It brings nothing but pain.
correct me if i’m wrong, but i believe the point that is trying to be made is;
a system user/admin has an intuition about files. saying that ‘journalctl -f -u’ (fu, indeed :) and whatever else is inherently undiscoverable, and is a.. basically orthogonal mechanism for handling what should be a simple task. i.e., viewing some logs. it’s far easier to compose and extend from files (what if i only care about the mtime of the log, for instance), than this.
look, i think systemd isn’t.. terrible. i also think it’s suffered a bit of complexity fetishisation, and it seems as though that this resulting complexity may have become invisible to you.
run0 doesn’t seem like a bad idea. but i am wincing a bit at the thought of unrestricted javascript determining access control.
I mean "systemctl status" shows all services and their hierarchy, there's also "systemctl list-unit-files" if you want to see things that aren't part of the current target (runlevel).
It's much easier in the systemd world to see the state of the system, the state of the service, and the logs of a service because it enforces this consistency.
Ah, good to know. I figured it might be the case that I just needed to RTFM.
honestly that's such a niche problem to have that i dont think it's worth throwing the baby out with the bathwater. anyways you shouldn't be discovering installed services by logfile presence, it should be something like querying your package manager.
I wouldn't say it's a niche problem. I also miss being able to go to /var/log and see instantly what's going on.
There should be a command like "journalctl --top" that would list all logging services with amount of logs, oldest and latest log times, and last few lines of each, to improve that experience. Maybe there is already a way to do something similar?
`systemctl list-unit-files` is too difficult?
I appreciate that someone's invented shoes you inflate and snap. I can see some advantages.
That said, when I'm in a hurry and going to do a thing that I've been doing every day of my life, I'm really not a big fan of having to stop what I'm doing and reexamine a tool I've used all my life to figure out how to use it. I learned this stuff decades ago and I'm not anxious to relearn how to do it for a fractional improvement, and I'm not even really 100% sure that this new "inflate and snap" shoe model is actually an improvement, except for very specific use cases.
Don’t think of it as relearning a tool, think of it as learning one tool which works for everything. You no longer have to implement your own log rotation, compression, etc. or work out which configuration each program needs to do that in the manner you expect – for example, “is it safe to rotate a log file?” requires you to know implementation details on each program.
For how long?
I've been around for decades at this point with people telling me how the newest and greatest thing will obsolete everything that came before it.
The best way to look through logs is still to materialize them in as text in a files hierarchy and use find with grep to look for issues.
Debian switched to systemd about 12 years ago, so at least that long.
A quick google indicates that it was made default in debian 8 in 2015, which is 9 years ago, not 12.
Perhaps it was available prior to then, but so were daemontools, upstart, and probably a variety of other alternatives.
Yes, you're right. I saw when it was added not when it became the default. Still 9 years suggests it's not going to disappear overnight!
One thing to remember is that a lot of people use the testing distribution so they would have seen it before the Debian 8 release changed the default. The debate in the community took ages but one factor in concluding it was that people were using it for years without it being anything like the more hyperbolic predictions some opponents made.
Find came out in 1974.
I’ve been doing this for decades, too, but I don’t miss having to deal with everyone inventing multiple log hierarchies, different rotation conventions, compression strategies, etc. not to mention all of the other things which systemd removed from daily toil around process management.
Yeah, this is a bit of an odd complaint. If I were this bothered by having to type those, I'd just make an alias to "journalctl --follow --nopager"` and would have forgotten about it years ago.
Never tried it, but if the complainer wrote: tail -f *.logs
Which involves glob’ing. I assume it allows to monitor several services at the same time.
Can systemd do that?
Yes, journalctl -u postgres -u redis -f etc
Or just `journalctl -f` to follow all logs.
It's the basic function what journalctl -f does by default: follow the global log all jobs write into. -u etc are for filtering that.
You sure would have forgotten about it when you tried to get onto another machine without the magic set of aliases
I am also prepared for someone to chime in that "log egress tools exist" to move up the Maslow's Hierarchy of Log Needs
'journalctl -u service -f' takes many seconds to start showing logs (even with 4GB journal size limit which not that much). 'tail -f /var/log/service' works without a noticeable delay (be it 1kb or 100Gb log file). For me it's a huge regression.
While I'm very pro journalctl, this is very true. They should put some work into the initial read performance on big journals.
This and many other discussions misses the point that most people that don't like systemd have with it.
It can largely do everything it replaces, but differently, in some cases with improvements. Every year it increases its scope of 'problems' its solved.
But the issue is it hasn't _ACTUALLY_ solved a problem for me in about a decade, its only introduced problems. Its replaced things that worked perfectly for me and millions of other users for years/decades with something that... also works... but differently. Now to accomplish the _SAME_ outcome without any personal benefit I have to re-learn their new and usually opinionated way.
There was a time I could log into a system, find logs, parse dates and do everything in these discussions reletave to logs, rotation. Regardless of service because the standards were close enough and the basic tooling (tail/find/tar/grep/awk etc.) worked everywhere always, and you never had to google even if the service was one you never worked on before.
For systemd its the opposite, its almost a guarantee you have to google something along the line when interacting with new systems and services. And as soon as their newly enforced opinions and way of doing things is getting comfortable they go and replace something else that was also working... perfectly fine.
If it actively solved problems for the majority of users we wouldn't hate it so much. Instead it requires more mental overhead than anything other than XORG to deal with and constantly manage than anything else in the linux ecosystem.
Not my memory at all. In almost all cases the logs were in /var/log and written by syslog. Unless the whole service was in a chroot directory, or the program was written by an amateur who didn't follow logging conventions.
Oh the joy it is to have a corrupted log file which the program that wrote it refuses to even read.
Once you deal with that you’ll realize journald is just in the way and needs to be modified to output a human readable log by default.
The follow argument is identical to tail `-f`. `sudo journalctl -f -u <service name>`
And what would be the equivalent to, "Oh, I don´t know the name of the log for this process I can see in 'ps aux', let me cd into /var/log and see what filenames I can find ... or grep everything until I can find a couple of words that make some sense so I can keep digging further"?
The lack of explorability in journalctl, the "need" to keep everything locked behind their own flavor of tools and magic file types, is what makes the rest of us abhor them.
[2]: https://www.freedesktop.org/software/systemd/man/latest/syst...
These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem.
The problem with systemnd is it assumes that it's possible for all needs to be predicted and accounted for ahead of time. While "look around at directories and files, and grep within them" works after the fact without any special knowledge or tools. The person who wrote the log file did not need to know how someone will maybe try to access it 23 years later on a different OS. It's just a regular file that can be read by anything over any kind of channel on any os. The person finding themselves needing to read the file does not need to have any particular command installed, or installable, or runnable. It does not require the happy path in order to work.
I have a joke I always say, often self-deprecating making fun of my own self for the way I do things sometimes, but also when I'm trying to commiserate with a customer so they don't feel intimidated by "the expert" or "the engineer": "37 easy steps!"
Every answer that starts with "it's simple, just journalctl ..." is FUCKING 37 easy steps. The very name of the program itself is a trainwreck. journalctl... it takes me 18 seconds just to type it.
systemd is great for managing exquisitely washed masses of drone vms. It's utter and complete shit for direct administration, operation, development, debugging, flexibility, or custom integrations.
No they don't. They are good answers. If you want answers to a more general problem, then ask. This is not an emotive topic.
They may be correct answers, in that they accomplish a task.
They suck in that the proposed method for accomplishing the task is a suck-ass downgrade from the previous ways the new way proposes to displace.
I beg to differ about emotive, because absolutely the other side of this fence behaves every bit as butt-hurt when challenged as I just did. You yourself just said these crappy commands were good, as a purely unfounded assertion. They are great because you just say they are great. That is even less objective than my rant. I at least explained what exactly I find so bad. Tell me more about not emotive.
Very well: I didn't say the commands were good or great. If you attempt a little objectivity you'll see it.
If you attempt a little objectivity, you will see that addressing the answers (vs the commands) was in my first response.
Before even going into the nature of the commands, I said that the answer does not match the question. The answers addressed details, while the details in the question were merely examples.
Missing the point is actually merely one of the at least two dimensions along which the answers suck. Thank you for reminding me about that.
No, the answers addressed the two scenarios in the question. That's why they don't "SUCK". They are good answers to the question as asked, and not the question as you dreamed it. If you spent ten words on asking the question of your dreams, rather than having a go at people for not answering it (whatever it is), you might have an answer.
To be clear -- you can just dump out all the logs to text and then use your standard grep toolkit on them. You can also dump them out to JSON, and use jq on them -- something you can't do with text logs on disk.
And as far as learning the options goes, learning the basics of systemd and journalctl is much easier than learning how to, say, use a source control system effectively.
(And it's definitely worth trying out new source control systems -- for example, I think most people should at least check out Jujutsu, and many people are going to like it more than Git. As simple as Jujutsu is to use, learning it takes a lot longer than learning journalctl.)
I didn’t answer the general question because I don’t care, I have no dog in this fight. Im just happy to provide information.
I like systemd and have found it extremely useful. If it doesn’t fill a need for you then use something else.
Agreed. I’ve tried to get used to it on Debian 12 for personal VMs. I just can’t. I don’t care. grep and awk are always going to be available, and I know how to use them.
It's way better than the previous status quo: now, more or less whatever distro I'm on, there's one command which answers that question directly, not a process of guessing how this system happens to be set up. You can guess and grep through most any kind of problem, but I don't see why anyone would want to do it as anything but a last resort, and to me that fits '37 easy steps' far more than the 1 consistent step in these replies (notice how none of them say 'oh, but on debian...'?).
Well `-u` refers to the unit file, so I would start with `sudo systemctl status` which lists the status of active unit files. I bet I could find the unit name I'm looking for there. If not, then `sudo systemctl list-units` should have it. (and you can grep the output of both)
Systemd and Journald are less opaque than I used to think. Even if you don't want to learn the commands, all of its unit files (and the relationships between them) are available through the filesystem. Most of your unit files will be in `/etc/systemd/system`, and the active relationships between units are expressed through soft links.
How would you exclude certain units from your logs? Let's say that Auditd is spamming your logs, and you just want to exclude those?
Can you filter on search? How do you prevent applications from writing to Systemd at all?
I would start with `man systemd`, or maybe `journalctl —help`.
If you don’t want a service to log to systemd, then don’t run it in systemd?
I think you can also configure the journal per unit right? Don't remember how exactly, at the very least you can stream logs to a different system.
There are also services which will just use their own logging convention for some reason. Honestly it's easier just to go with journalctl for everything you can.
systemctl does not have the Unix nature.
Huh, isn't grepping journalctl output pretty much the same? It even prefixes messages by the binary name.
Pedantically, they're the unit name which only sometimes matches the binary name
Actually no, they are prefixed by the binary name and the PID number. Technically they are prefixed with: `<date> <host> <binary>[<pid>]`.
You can then use `systemctl status <pid>` to identify the unit if you need to.
I would imagine this is configurable, and this might be the configuration chosen by my distribution (since I have not changed it myself). It would actually be nice to show the unit name instead of the binary/PID combination, though not strictly necessary.
EDIT: Ooh, systemd 239 adds `journalctl -o with-unit` to do this exact thing. There are lots of other formats you can choose from as well.
EDIT 2: Unfortunately there's no way to set this as default, you must use `-o with-unit` each time or set up a shell alias :-\
You do have to learn a few new things, yes. But it's not too difficult. We all have to learn new things sometimes.
I spent around 15 minutes a few weeks ago learning how to do a few things with journalctl, and I came away from it with a great appreciation for its power.
systemctl status <pid> will show you the unit and helpfully the last few lines of log from it. Journalctl -u <unit name> will then show you the full logs
With services using journald, there's no "name of the log" because everything's in the journal, so that part isn't a problem. Rather than "is this in auth.log or syslog or thisservice.log", it'll always be in the journal.
You can filter journal entries by unit (-u) or by service identifier (-t). Often, though, I find it really useful to be able to see the adjacent entries from other services at the same time, since that can give some indication of what's happening on the system that caused an issue.
journalctl --grep, or more conveniently, journalctl and then / to search.
It's explorable by dozens of different axes, and if all of those aren't sufficient, you always can get the whole thing as text and run any command you like on it, or get it in structured form and do structured queries on it.
I've recently become a fan of the `-x` flag to journalctl, which adds additional context to log entries and even suggests remediations at times. I've identified and fixed several issues on my Linux systems that way. Kind of hard to get that with tail -f!
Ooh nice. What are some examples of things it will catch?
My goto is journalctl -xf. Best of both worlds :)
How does it work? Can I pipe non-journald logs into the -x flag to take advantage of this lookup?
My 2c, I definitely prefer systemd boot+networkd, fine with journald, don't use the others enough to have an opinion.
Same. Init system is awesome, love .ini files, networkd is as simple as it can be, journald is fine. Love systemd-nspawn for simple containers as it feels more lightweight than docker. Especially for quick one-offs where I don't need isolated networking you basically have chroot on steroids with "systemd-nspawn -D /path/to/fstree".
Others point out that journalctl supports `-f` and `-n` for determining how much journal to return, but for me what's great about journalctl is that I do not need to know where the program is logging to, how it rotates logs (or how it doesn't), or anything else. The program does not need special permissions to a log location in /var/log or /usr/var/log or ~/... or anything else, it just outputs using stdout and it gets captured. When I want to look at logs, I just use the same moniker that I use to control the service: its unit name. It is so incredibly nice- I do not want to go back to the bad old days of spelunking through /var/log and friends.
To be clear, if you pipe journalctl somewhere, it will automatically skip the pager and just work. `--no-pager` is most useful for when you want to print some unpiped content in an automated script to avoid having a non-existent user exit the pager.
I remember, and sometimes still have to deal with, programs that _didn't_ dump their logs in /var/log, forcing me to figure out where the log are in the first place
systemd-nspawn is actually pretty great, and is mostly just a tool that exposes functionality that systemd already needs for other reasons. IIRC it was originally developed to aid in testing systemd itself, and was initially shipped as an unsupported extra in case other people found it useful.
systemd-resolved is the only way I've ever been able to get dockerd to play nice with Tailscale DNS; it's also the best way that I've found to get a system to pick different upstream DNS servers depending on domain. The alternative is hand-rolling it with dnsmasq or something similar.
I admit I haven't really seen a huge advantage to using systemd-networkd over NetworkManager yet, but for servers with relatively static network configurations, I greatly prefer systemd-networkd over any of the various implementations of ifupdown.
Those old init scripts were pretty boilerplate and not that hard to write. And in the case of OpenBSD (and maybe other BSDs?) the scripts for /etc/rc.d are usually just a few lines.
With the traditional init system I knew what was going on, and if I didn't, find and grep were your friends. With systemd I'm googling everything every time. The systemctl man page is over 1,100 lines. OpenBSD's rcctl man page is 119 lines.
I'm sure there are use cases for systemd but for running a server that provides a single or a handful of services, it seems like complete overkill.
I'd agree with your message if systemd was just an init system.
It's not difficult to use some parts of systemd without using others. Is it any different than something like coreutils, another package of linux utilities that are synergistic but usable seperately? Nobody complains about coreutils being bundled. Even the rewrite in rust crowd bundle them.
It really is not. This "sudo replacement" (which under the hood is systemd-run) will apparently require quite a bit of the systemd stack to operate. That is not something you have access to in many lightweight container distros or on other non-systemd distros.
And coreutils is expected because most people use GNU/Linux. Coreutils is that GNU userland part. And either way, the majority of coreutils are GNU implementations of standard unix components. You can use most software that depends on coreutils on other *nix platforms like BSD for this reason.
I doubt you'll need to run systemd as pid 1 to use this.
Oh you do: this work completely differently from sudo, there is no suid binary involved, instead it does IPC to the systemd pid 1 and asks it to spawn you process, attached to your current terminal. So if you don't have systeme as pid 1, it'll have noone to talk to.
Whether you like that or not is for you to decide.
IPC will likely be over d-bus. The new process will fork off a systemd which is almost always pid 1, but it might not have to be.
are there any non-systemd DBus options anymore? I had a hard time a year ago setting up Gentoo because there were no maintained options at that time.
There are. Gentoo has actually always used the FreeDesktop reference implementation instead of sd-bus (the systemd implementation).
FreeDesktop also maintains a list of implementations (also including bindings so you have to read to find which ones are full impls vs libdbus bindings).
https://www.freedesktop.org/wiki/Software/DBusBindings/
No. The real nightmare is systemd integration with dbus.
No, it hasn't.
You forget, the reason systemd was originally rationalized for its insertion into our trees was "boot times are too slow". Its chameleon-like nature and ability to solve the hastily described problem du jour seems to be its only consistently touted feature.
Bash scripts that start processes are ephemeral. If it's signal handling you want, that was your program's problem. Either that or your program didn't fork itself, which is a fish of an entirely different feather.
And now we have this sprawling mess of complexity and headache.
Same thing is happening with Wayland. It reduces features adds complexity and solves no new problems but here it comes.
How is Wayland more complex than X?
The resulting wayland environments are more complex because wayland itself refuses to define/include features that desktop systems are expected to have. This results in a sprawling mess of competing and incompatible interfaces for those gaps that other parts of the implementations (desktop environments) now have to compensate for by including multiple implementations of the same thing based on all these different interfaces.
Stop using the wrong words. You're saying Wayland is too simple and feature incomplete.
Wayland by itself is simplier -- it is done by "outsourcing" everything a window system should do to the window manager. There is where the complexity kicks in.
Wayland was a mis-fire in terms of user friendliness for the first decade or so. But it is still a big step up from the mess that was a typical xserver back in 2010.
The irony here is Wayland is part of a huge effort to decomplex an xserver into component parts. A really commendable initiative; the path forward while maintaining the X protocol probably was impractically hairy.
The Wayland protocol design had some glaring flaws, but saying that it adds complexity is unfair. It oversimplified; it would have benefited from some flexibility in providing a standard mechanism to let people inspect the buffers graphics buffers to be composited.
In theory, yes. In practice, I had a lot of trouble ordering things correctly in non-trivial cases.
I can only speak for myself, but I don't want the abysmal sysvinit scripts back. I just want a simple process supervision suite which is true to the UNIX way of doing things. The sysvinit/systemd dichotomy is false.
Runit and s6 are both very real alternatives to systemd. They lack a ton of features, but they are a way to reliably run services. They do use shell scripts, but not for the reasons sysvinit did. They are extremely simple and have a very small attack surface as a result. Runit itself is a spiritual descendant of daemontools which predate systemd by great many years.
The problem with systemd is that it's a mediocre solution to many problems. UNIX deserved better.
[Edit: whitespace]
The other pieces are also pretty excellent. Ifup gave me no joy & was very limited. Systemd-networkd is a wonderful option with vast & great capabilities, that meshes well with the init process & it's style. Systemd-timesyncd is fine, I dunno, works for me. Systemd-journald is probably the weakest of the batch but mostly because it's not very ambitious; I loath that there's no way to really deal with super-active programs hogging all the logspace, short of configuring a second journald instance for that program, which ain't no joy to setup. Systemd-home is a cool set of features for portability. Systemd-nspawn is a bit ahead of its time & looks a little weird now but was a very novel & powerful thing to have built in to most systems. Systemd-resolved is a pretty good local DNS that handles mdns and much weirder cases easily. Systemd-boot is a really nice easy to work with uefi boot loaders that's worlds easier to deal with than uboot or gasp grub.
All of these are taken em or leave em. But they're good expectations to have. I love the bazaar model, but Linux used to have so few common expectations, used to manage various bits so poorly. And now there's a much better base of capabilities, which have universal patterns of management that tend to apply to them (how etc files are laid how, being dbus and maybe varlink accessible). Linux hadn't been growing; when you came to a random systems you expected enormously little and typically got it, and what extras were available were scattered/random and often not particularly high quality or capable software. Systems has extended a much bigger base of competency & capability. That we can plug in a USB drive and systemd-home can create an isolated dynamic user out of that & let that user securely run their environment there is a neat as heck expectation. That our network manager supports setting up such a wide range of bridges and tunnels and taps and tuns is fantastic, is excellent. I don't have words for people turning their noses up at this better world; this is so much more competent & capable a world than where we were, gives us so much we all can now take for granted, and it's been done smartly, more mono-repo than monolithic, such that you can do alternatives. But many of these pieces are utterly without peer. And the consistency of operation you get, the predictability of use, from being under the same umbrella, is an ergonomic wonder that is unmatched.
Is there a good overview of these pieces and what they're responsible for and how they fit together?
I had a quick skim of the docs on systemd.io and there are quite a few documents but they don't seem particularly organized and I couldn't see a good architecture overview.
I hate to be this guy but the man pages have it all
There's some terminology to learn, but overall it's pretty approachable.Edit; and as far as architecture goes they are all _separate_ programs. It's not a single large "systemd"
In a similar vein, systems like openrc use "shell scripts" as well, but can generally be written declaratively[1]. This provides greater flexibility when it comes to creating one-shot services or services that require a little setup before running, as you can just re-define the start() function, rather than requiring one to make a separate shell script for it, or dependency tree, like you'd have to in systemd land.
"sysvinit" is an ill-defined concept, anyway, as every distribution had their own scripts and tooling around actual services, and sysvinit was generally only responsible for starting getty and launching the distribution's actual service system. How initscripts were created and how you managed them depended significantly on the distribution.
[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-vpn/tails...
Debian's sysvinit scripts can also be declarative. https://github.com/DanielAdolfsson/ndppd/blob/master/ndppd-i...
The full system also cares about dependencies and parallel running. And this is not recent, but the black legend will never die.
Bonus: by having the shipped scripts under /etc, tools like etckeeper can show your changes as well as updates, all in one place.
Yeah, basically I've found that the people the more vocal against systemd are either not really knowing how it works behind the scenes, and just criticizing for the sake of it (or because other people do so), or criticizing from an ideological point of view (do one thing and do it well). They see systemd as an octopus, not following the unix ideology. Which I don't really agree tbh
The issue is that it's not just ideological. "Do one thing and do it well" is important because if you want to port software to another platform, it's a lot easier to port a single dependency component over to make it work than it is to port over the entire framework.
This is a serious problem and it makes it way harder to make things cross platform.
Systemd was written specifically for Linux, hard depends on a list of features provided by the Linux kernel and leverages them to do its work. Porting it to another kernel is a rewrite. Lack of portability is in this case a design tradeoff.
Sure that is the case for systemd itself but it's not the case for most projects that happen to use things systemd provides.
There is very little benefit for most userspace software to tie itself to systemd and by extension linux when otherwise it could be portable to any unix or unix like platform. Especially when an alternative, portable solution already exists and is well established.
The argument was that this design of systemd makes it hard to write applications that are portable, so that systemd is effectively a very big net negative to the open source ecosystem, because it causes massive fragmentation.
I think this is a really old statement. I’ve used systemd since it was made default in Fedora back in 2011 (Lovelock, anyone?) - at what point am I qualified to have an opinion, after having used it personally for 13 years and professionally for 8.
systemd is scary for 3 reasons.
1. it is inscrutable. Debugging it is nearly impossible, so you had better hope you don’t get a buggy release, especially with how hostile the devs can be.
2. it is large, and growing. Lots of things it claims are optional are in reality: not really. This is fine until uou get something that really doesnt work well (systemd-resolved is consistently the largest reason I have connectivity issues, wether it be because it interferes with docker inter-container networking or because it needs to time-out when trying DNSSec to continue- or if it fights with my vpn provider for power over my resolvers etc). Due to my distro being very tied to it: I gotta keep using it and working around it.
3. The interface is irreplaceable. Why are their 13 init systems? Because init is a closed scope. To be a sucessful init you need to spawn processes and do it cheaply. Supervising processes after start? Noble, and there were implementations that could do that (CDDL licensed SMF from Solaris for example). However we have already reached the state where it will be literal man-decades of work to replace systemd as we will need to make any replacement bug compatible with systemd itself. Its the ultimate show stopper.
The implementation is the reference. Which is a large departure now from what came before.
I love systemd.
Me too. The best thing about Linux.
It's a re-implementation of Apple's launchd. I've always liked it though
It is much more than just a re-implementation of launchd. I can't grab a link right now, but Lenart wrote a long blog post about the philosophical decisions behind systemd, and he goes into detail about what he liked from launchd and what he did not like. It is called "rethinking PID 1"
A much improved version of launchd, yes.
100%
Systemd unit files make Linux feel like a rational OS.
Only if your marker for a rational OS is NT.
Not the parent commenter. Windows has a lot of rubbish user-level interaction which belie how good an OS NT really is. Anyone who blindly disses it because 'Windoze' and 'M$ bad' is not really worthy of any attention whatsoever.
NT isn't terrible with some very well designed systems, that is quite true. It is however good for a completely different list of reasons that *nix is. Trying to conflate the two is a pottering's errand.
You're presuming to speak for an awful lot of people there, on a topic that would be difficult to measure.
Now you're overgeneralizing, and doing so in a dismissive and patronizing way.
Here are a few examples of problems I have with systemd:
System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted.
Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope --property=Delegate=yes <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable.
At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back.
There are more examples, but I'm tired of re-living them and don't really want to write a book. I hope these few are enough to convey my point:
Systemd has been a net negative in my experience. It has made my life markedly worse, without bringing anything I needed. Based on conversations, comments, and bug reports I've seen over the years, I get the impression that many others have had a similar experience, but don't bother speaking up about it any more, because they're tired of being dismissed, ignored, or shouted down, just as I am.
I would welcome a reliable, minimal, non-invasive, dependency-based init. Systemd is not it.
Systems isn't blocking the shutdown. Systems is being blocked by a service. Since you are saying that you can't track down the exact service, you must be using a container runtime like docker or LXC which is not transmitting the kill signal properly to the container to shut it down. The container itself then keeps running for whatever reason. This entirely depends on your particular setup and has very little to do with systemd.
That is not what I said.
ctrl-alt-del skips iirc?
Ah yes I remember back when you just put the system hostname in /etc/hostname. Now we have hostnamed!
Which is now borderline impossible to tame. Google "change hostname ubuntu" and take a look at the results and comments.
I'm still trying to figure out whether I like nftables more than iptables. Both are pretty complex to manage IIRC (I've only touched nftables a couple of times though, and not recently)
Well, it has "NFT" in the name so it must be good!
I don't resent systemd for existing, but I don't want to be forced to accept Lennart's shitty design decisions and it's clear he wants me to be since he successfully agitated for other critical components to hard depend on it. I want the option of opting out, which Lennart would deny me if he could.
At the end of the day, I just run Void (or MX Linux if I want something more Debian-flavored) and get on with my life.
Void Linux and now Guix have been a godsend.
Its refreshing to see that just hate systemd because "its not UNIX way" is not anymore. I see better discussions under this post and in other places around the web.
I guess that depends on whether or not you consider the great number of CVEs caused by it don't matter enough.
Systemd was meant to replace Ubuntu's upstart, not sysv init. And it indeed systemd was better designed than upstart.
Sysv init is a horrendous hack. People should NOT use that. Upstart had limitations but is okay, and certainly much better than sysv init. Systemd is okay too (but has much more features).
Also as an historical note, both upstart and system was inspired by Apple's launchd.
NixOS was an early adopter of upstart but it later migrated to systemd (alongside Ubuntu itself)
Systemd isn't just one thing lol