Systemd gets a lot of hate but it really solves a lot of problems. People really shouldn't dismiss it. I think it really happened because when systemd started appearing on distros by default people were upset they had to change
Here's some cool stuff:
- containers
- machinectl: used for controlling:
- nspawn: a more powerful chroot. This is often a better solution than docker. Super lightweight. Shares kernel
- vmspawn: when nspawn isn't enough and you need full virtualization
- importctl: download, import, export your machines. Get the download features in {vm,n}spawn like we have with docker. There's a hub, but it's not very active
- homed/homectl: extends user management to make it easier to do things like encryption home directories (different mounts), better control of permissions, and more
- mounts: forget fstab. Make it easy to auto mount and dismount drives or partitions. Can be access based, time, triggered by another unit (eg a spawn), sockets, or whatever
- boot: you can not only control boot but this is really what gives you access to starting and stopping services in the boot sequence.
- timers: forget cron. Cron can't wake your machine. Cron can't tell a service didn't run because your machine was off. Cron won't give you fuzzy timing, do more complicated things like wait for X minutes after boot if it's the third Sunday of the month and only if Y.service is running. Idk why you'd do that, but you can!
- service units: these are your jobs. You can really control them in their capabilities. Lock them down so they can only do what they are meant to do.
- overrides: use `systemctl edit` to edit your configs. Creates an override config and you don't need to destroy the original. No longer that annoying task of finding the original config and for some reason you can't get it back even if reinstalling! Same with when the original config changes in an install, your override doesn't get touched!!
It's got a lot of stuff and it's (almost) all there already on your system! It's a bit annoying to learn, but it really isn't too bad if you really don't want to do anything too complicated. But in that case, it's not like there's a tool that doesn't require docs but allows you to do super complicated things.
> Systemd gets a lot of hate but it really solves a lot of problems.
From my perspective, it got a lot of hate in its first few years (decade?), not because the project itself was bad -- on the contrary, it succeeded in spite of having loads of other issues, because it was so superior. The problem was the maintainer's attitude of wantonly breaking things that used to work just fine, without offering any suitable fixes.
I have an old comment somewhere with a big list. If you never felt the pain of systemd, it's either because you came late to the party, or because your needs always happened to overlap with the core maintainer's needs.
From what I remember that's still the default in the project, but people stopped complaining because the individual distros started overriding the relevant settings.
Thanks for adding the perspective. I was much more of a casual user at the time so didn't see as much of this side. Just knew Arch always being Arch lol
It didn't win on being superior [1] but because it was either systemd or you don't get to to use GNOME 3.8. On more than one distro it was the reason for switching towards systemd.
I will fully admit though that upstart was worse (which is an achievement), but the solution space was not at all settled.
[1] systemd project tackles a lot of important problems, but the quality of implementation, experience of using it, working with it, etc are not really good, especially the further you get from simplest cookie cutter services - especially because both systemd handling of defaults is borked, documentation when you hit that maybe makes sense to author, and whoever is the bright soul behind systemctl kindly never make CLIs again (with worst example being probably systemctl show this-service-does-not-exist)
> systemd project tackles a lot of important problems
Fundamentally, this was it. SysV startup scripts had reached a local maximum decades earlier, and there was serious "overhang". When I said "superior", I really meant that it was superior to SysV, not that it was the best system that could have been imagined.
And I think the frustration was that, because it did solve so many problems, so many groups (like GNOME) were willing to switch over to it in spite of its warts; and this made it impossible for anyone who was seriously affected by its warts to avoid it. "If you don't like it, don't use it" not being an option was what drove so much of the vitriol, it seems to me.
As I said in that comment from 2019, if the maintainers had had Linus Torvald's commitment to backwards compatibility, I don't think there would have been any significant backlash.
Why did GNOME and basically all the large distros all jump with both feet in on using systemd? Because it was better. It was simply significantly better than all the alternatives. For the vast majority it was a no-brainer upgrade. The holdouts were the one's who had simple needs and were already happy with what they had. The rest of the world jumped on systemd. Because it was better.
GNOME and systemd teams were in many ways joined at the hip, and GNOME unilaterally decided that from 3.6 to 3.8 they would switch certain APIs from one already deployed widely (polkit and related) to one that was documented like north korea is democratic (logind) which also didn't work in isolation from systemd.
Trying to run GNOME 3.8 without logind caused significant problems and instabilities, trying to implement the same APIs turned out a futile endeavour though one OpenBSD guy got sufficiently motivated and kept patching GNOME for OpenBSD for years - though too late for the forced switch.
The large distros jumping "both feet" on systemd were essentially Fedora/Redhat (where it originated and who was employing major maintainers), and IIRC SuSE. Arch was still seen as something of niche and - crucially - was very neophyte about adopting systemd related ideas for significant amount of time with little regard for stability.
The holdouts were not just those who were happy with debian/redhat simplistic run-parts script. They were also those interested in solving the problems in different way. Hell, systemd was pretty late to the party, the major difference was that it had funding behind it
The only issue I'm having with systemd is that it's taking over the role of PID 1, with a binary produced from an uncountable SLOC, then doing even more song and dance to exec itself in-place on upgrades. Here's a PID 1 program that does 100% of all of its duties correctly, and nothing else:
#define _XOPEN_SOURCE 700
#include <signal.h>
#include <unistd.h>
int main() {
sigset_t set;
int status;
if (getpid() != 1) return 1;
sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, 0);
if (fork()) for (;;) wait(&status);
sigprocmask(SIG_UNBLOCK, &set, 0);
setsid();
setpgid(0, 0);
return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}
If you have your init crashing wouldn't this just start a loop where you cannot do anything else than seeing it looping? How would this be better than just panicking?
Don't restart it. Let it crash, but take note of the situation, whatever may help investigation, maybe send out a page, flush pending writes to disk, reboot gracefully, etc. Kernel panic should be the last resort, not the default.
And I want 192.168.1.1 as the IP of my workstation on corporate LAN. Both requirements are completely arbitrary.
I guess if you really need that information, you could wait4 and dump pid/rusage to syslog. Nothing more to see here; these are zombies, orphans, by definition these processes have been disowned and there's nobody alive to tell the tale.
Timers are so much better than cron it's not even funny. Managing Unix machines for decades with teens of thousands of vital cron entries across thousands of machines, the things that can and do go wrong are painful, especially when you include more esoteric systems. The fact that timers are able to be synced up, backed up, and updated as individual files is alone a massive advantage.
Some of these things that "worked for 50 years" have also actually sucked for 50 years. Look at C strings and C error handling. They've "worked", until you hold them slightly wrong and cause the entire world to start leaking sensitive data in a lesser-used code path.
Not sure I'm on the same page with you on the cron. I have a similar experience but I'd rather say that cron was something that never gave me headaches. Unlike obviously systemd.
Cron has given me a ton of headaches. Between skipped jobs on reboots and DST, inability to properly express some dates ("First Sunday of the Month" is a common one), and worst of all, complete inability to prevent the same job from running multiple times at once, it's been regular headaches for a shop who has leaned very heavily on it. Some cron daemons handle some of these things, but they're not standard, and AIX's cron daemon definitely doesn't have these features. Every job has to be wrapped in a bespoke script to manage things that systemd already does, but much worse.
systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me.
> skipped jobs on reboots and DST
> prevent the same job from running multiple times
I'd say these are not bugs but rather a matter of realizing how cron works - just like with systemd-anything. So if you know DST is coming, a wise thing would be to not plan jobs in the rollover window. But yes, I agree that this thing is rudimentary - and thus simple - and thus reliable and independent, like the rest of unix was supposed to be.
> job has to be wrapped in a bespoke script
Well yes. Again, this is by design and well known.
> systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me
Good for you - and I mean it! For me systemd was an obnoxious piece of shit which I have avoided for many years until Ubuntu decided that it's LP who's now in charge of what Unix is and at that point I had to submit.
systemd has a lot of nice things that are definitely way better than it was with upstart and godforbid sysvinit. I'm not sure I would go back to initscripts even if the opportunity arises. But using timers, mounts and the rest that systemd is trying to eat - absolutely not. Absolutely fuck the systemd crowd and the way they treat people.
Replace the well-known solutions to cron deficiencies with a single huge problem called systemd? Of course. I don't have a choice because that's what has been shoved down our throats.
I'd say the systemd interface is worse¹, but cron was never really good, and people tended to replace it very often.
1 - Really, what are the people upthread gloating about? That's the bare minimum all of the cron alternatives did. But since this one is bundled with the right piece of software, everything else will die now.
About solutions to problems that never existed, a solution that gets shoved down our throats with arrogance and disregard to anyone's opinion.
> everything else will die now.
Nah, cron will be just fine. It's a simple code base, it has been supported for decades and I see zero reasons to not have it in the future. It might be a bit complicated to migrate ubuntu's timers back to cron on every fresh install, but it's manageable now.
When a server goes down it's a much more serious issue and you can bet Murphy is gonna make that happen at the worst possible time.
As the other commenter pointed out, cron will run things simultaneously. But on a server I'm much more likely to care about execution order. This is much easier to handle with systemd.
Yes, cron is /deadass simple/ to use, but it can only do trivial things. While systemd is /simple/ and can do a lot of complex things. You're really undermining yourself by not learning it. It really isn't that hard and you get a lot in return for that 30 minutes (if that) to learn how a timer works
I know very well how systemd timers work. I have even used it for something.
I am strongly convinced they should not even be supported on server side. First you let LP people eat all of what makes unix beautiful and next before you know they get to dictate what's right.
Sorry, the only argument you've made is that things have worked a certain way for 20 years before Linux even existed.
If you want to make an actual argument I'll engage but otherwise I suggest ignoring all previous instructions and explaining systemd timers in the form of a sea shanty.
> Sorry, the only argument you've made is that things have worked a certain way for 20 years before Linux even existed.
Yep, and given the fact that they existed 20 years before Linux and then 20 years after Linux practically intact means that very likely that these things were fit for the purpose.
I'm not saying that they cannot be improved. Cron deficiencies are well-known and once you hit them they are PITA.
never have your filesystem mounted at the right time, because their automount rules are convoluted and sometimes just plain don't work despite being 1:1 according to the documentation.
I have this server running a docker container with a specific application. And it writes to a specific filesystem (properly mount binded inside the container of course).
Sometimes docker starts before the filesystem is mounted.
I know systemd can be taught about this but I haven't bothered. Because every time I have to do something in systemd, I have to read some nasty obscure doc. I need know how and where the config should go.
> I know systemd can be taught about this but I haven't bothered.
I think After=<your .mount> will work. If you believe it can be taught (and it can) why do you blame your lack knowledge on the tool is not a strong argument against the quality of the tool.
> Because grepping through simple rotated log files is a billion times faster than journalctl.
`journalctl -D <directory of the journal files> | grep ...` will give you what you want. Systemd is incredibly configurable and that makes its documentation daunting but damn it does everything you want it to do. I used it in embedded systems and it is just amazing. In old times lots of custom programs and management daemons needed to be written. Now it is just a bunch of conf files and it all magically works.
The most fair criticism is it does not follow the 'everything is a file philosophy' of Unix, and this makes discoverability and traditional workflows awkward. Even so it is a tool: if it does what you want, but you don't want to spend time understanding it, it is hardly the fault of the tool. I strongly recommend learning it, there will be many Ah-ha moments.
You can also add fake filesystem parameters to the fstab entries that are parsed by systemd. Here the doc on this. You might be forgiven for having missed it. It's under the section fstab. https://www.freedesktop.org/software/systemd/man/latest/syst...
If you had followed my link to the systemd issue, you might have seen the commands I ran, as well as the tests and feedback of everybody on the issue. You might reach the conclusion that journalctl is fundamentally broken beyond repair.
It does everything no one asked it to. I'm sure they will come up with obscure reasons why the next perfectly working tool has to be destroyed and redone by the only authority - the LP team. Like cron, sudo and yes - logging.
> journalctl -D ... will give you what you want
Look, I don't need the help of journalctl to grep through text. I can simply grep thru text.
> I used it in embedded systems
Good luck in a few years when you are flying home on the next Boeing 737-MAX-100800 and it fails mid flight because systemd decided to shut down some service because fuck you that's why.
> it does not follow the 'everything is a file philosophy'
It does not follow 'everything is a separate simple tool working in concert with others'. systemd is a monolith disguised to look like a set of separate projects.
> don't want to spend time understanding it, it is hardly the fault of the tool
It is, if we had proper tools for decades and they did work. I'm not a retrograde guy, quite the opposite, but the ideology that LP and the rest are shoving down our throats brings up natural defiance.
> there will be many Ah-ha moments
No doubts. systemd unit files and systemd-as-PID1 is excellent. It was NOT excellent for the whole time but now it is. The rest? Designed to frustrate and establish dominance, that's it.
My goodness. Absolutely fuck journald - a solution in search of a problem. I have created a bunch of different scripts to init my instances [1] on all projects. I do it differently from time to time, but one thing they all have in common is that journald gets removed and disabled.
> Because grepping through simple rotated log files is a billion times faster than journalctl
This is annoying, but there's a "workaround"
$ time journalctl | grep "sshd" | wc -l
12622
journalctl 76.04s user 0.71s system 99% cpu 1:17.09 total
grep --color=always --no-messages --binary-files=without-match "sshd" 1.28s user 1.69s system 3% cpu 1:17.08 total
wc -l 0.00s user 0.00s system 0% cpu 1:17.08 total
$ time journalctl > /tmp/all.log && time wc -l /tmp/all.log
journalctl > /tmp/all.log 76.05s user 1.22s system 99% cpu 1:17.56 total
16106878 /tmp/all.log
wc -l /tmp/all.log 0.03s user 0.20s system 98% cpu 0.236 total
# THE SOLUTION
$ time journalctl --grep=sshd | wc -l
5790
journalctl --grep=sshd 28.97s user 0.26s system 99% cpu 29.344 total
wc -l 0.00s user 0.00s system 0% cpu 29.344 total
It's annoying that you need to use the grep flag instead of piping into grep but it is not too hard to switch to that mindset. FWIW, I have gotten slightly faster results using the `--no-pager` flag but it is by such a trivial amount I'll never remember it
> Sometimes docker starts before the filesystem is mounted.
Look at the output of `systemctl cat docker.service` and you'll see an "After" "Wants" and "Requires" arguments in the unit. You're going to want to edit that (I strongly suggest you use `sudo systemctl edit docker.service`, for reasons stated above) and make sure that it comes after the drive you want mounted. You an set the Requires argument to require that drive so it shouldn't ever start before
Alternatively, you can make the drive start earlier. But truthfully, I have no reason to have docker start this early.
Here's a link to the target order diagram[0] and Arch wiki[1]. Thing that gets messy is that everyone kinda lazily uses multi-user.target
> journalctl --grep is still much slower than grep on simple files
Idk what to tell you. You had a problem, showed the commands you used and the times it took. So I showed you a different way that took less than half the time to just dump and grep (which you said was faster)
My results don't match your conclusion.
> if you use ripgrep
I've been burned by ripgrep too many times. It's a crazy design choice, to me, to default filter things. Especially to diverge from grep! The only thing I expect grep to ignore are the system hidden files (dotfiles) and anything I explicitly tell it to. I made a git ignore file, not a grep ignore file. I frequently want to grep things I'm ignoring with git. One of my most frequent uses of grep is looking through builds artifacts and logs. Things I'd never want to push. And that's where many people get burned, they think these files just disappeared!
The maintainer also has been pretty rude to me about this on HN. I can get we have a different opinion but it's still crazy to think people won't be caught off guard by this behavior. Its name is literally indicating it's a grep replacement. Yeah, I'm surprised its behavior significantly diverges from grep lol
Given your criticisms of ripgrep, this is just deliciously ironic. What, you're the only one who can criticize the defaults of tooling? Oh my goodness, what a hoot.
In the data I provided, counting the lines in a big log file was 469.5 times faster than journalctl took to output all the logs.
From this information alone, it seems difficult to believe that journalctl --grep can be faster. Both had to read every single line of logs.
But it was on a rather slow machine, and a couple years ago.
Here /var/log and the current directory are on a "Samsung SSD 960 PRO 512GB" plugged via m2 nvme, formatted in ext4 and only 5% used. Though this shouldn't matter as I ran every command twice and collected the second run. To ensure fairness with everything in cache. The machine had 26GiB of buffer/cache in RAM during the test, indicating that everything is coming from the cache.
In my tests, journalctl was ~107 times slower than rg and ~21 times slower than grep:
- journalctl: 10.631s
- grep: 0.505s
- rg: 0.099s
journactl also requires 4GiB of storage to store 605MB of logs. I suppose there is an inefficient key/value for every log line or something.
For some reason journalctl also returned only 273 out of 25402 lines.
It only returns one type of message "session closed/opened" but not the rest. Even though it gave me all the logs in the first place without `--grep`?!
Let me know if I am still using it wrong.
$ sudo hdparm -tT /dev/nvme0n1
/dev/nvme0n1:
Timing cached reads: 33022 MB in 1.99 seconds = 16612.96 MB/sec
Timing buffered disk reads: 2342 MB in 3.00 seconds = 780.37 MB/sec
$ du -hsc /var/log/journal
4.0G /var/log/journal
4.0G total
$ time journalctl > logs
real 0m31.429s
user 0m28.739s
sys 0m1.581s
$ du -h logs
605M logs
$ time wc -l logs
3932131 logs
real 0m0.146s
user 0m0.065s
sys 0m0.073s
$ time journalctl --grep=sshd | wc -l
273
real 0m10.631s
user 0m10.460s
sys 0m0.172s
$ time rg sshd logs | wc -l
25402
real 0m0.099s
user 0m0.042s
sys 0m0.059s
$ time grep sshd logs | wc -l
25402
real 0m0.505s
user 0m0.425s
sys 0m0.085s
PS: this way of using rg doesn't ignore any files, it is not used to find files recursively. But I don't have a .gitignore or similar in my /var/log anyways.
Your measurement procedure is wrong because the `journalctl` command is doing something different. It isn't just reading a plain file, it is reading a binary file. On the other hand, `grep` and `rg` are reading straight text.
> it seems difficult to believe that journalctl --grep can be faster.
Why? It could be doing it in parallel. One thread starts reading at position 0 and reads till N, another starts at N+1 and reads to 2N, etc. That's a much faster read operation. But I'm guessing and have no idea if this is what is actually being done or not.
P.S.: I know. As I specified in my earlier comment, I get burned with build artifacts and project logs. Things that most people would have in their .gitignore files but you can sure expect to grep through when debugging.
Their measurement isn't wrong. It's demonstrating the exact point in question: that if the logs were just stored in plain text, then grepping them would be an order of magnitude faster (or multiple orders of magnitude in the case of ripgrep) than whatever `journalctl --grep` is doing.
How it's doing the search is irrelevant. What's being measured here is the user experience. This isn't some kind of attempt to do an apples-to-apples grep comparison. This is about how long you have to wait for a search of your logs to complete.
The results in your comment aren't measuring the same thing. There's no grep on the /tmp/all.log in the middle code block, which is the thing they're talking about comparing.
My second operation is covering that. The reason my results show better is because they are counting the decompression against journalctl. It is doing a decompression operation and reading while grep and rg are just reading.
Btw, you can choose not to store journald files as compressed.
Where exactly did you test the speed of "grep sshd /tmp/all.log"? The entire point of their argument is that's what's orders of magnitude faster than anything journalctl.
If there are other interactions we've had, feel free to link them. Then others can decide how rude I'm being instead of relying only on your characterization.
> but it's still crazy to think people won't be caught off guard by this behavior
Straw-manning is also crazy. :-) People have and will absolutely be caught off guard by the behavior. On the flip side, as I said 9 months ago, ripgrep's default behavior is easily one of the most cited positive features of ripgrep aside from its performance.
The other crazy thing here is... you don't have to use ripgrep! It is very specifically intended as a departure from traditional grep behavior. Because if you want traditional grep behavior, then you can just use grep. Hence why ripgrep's binary name is not `grep`, unlike the many implementations of POSIX grep.
> Its name is literally indicating it's a grep replacement.
For anyone else following along at home, if you want ripgrep to search the same files that GNU grep searches, then do `rg -uuu`. Or, if you don't want ripgrep to respect your gitignores but ignore hidden and binary files, then do `rg -u`.
It makes sense that folks might be caught off guard by ripgrep's default filtering. This is why I try to mitigate it by stating very clearly that it is going to ignore stuff by default in the first one or two sentences about ripgrep (README, man page, CHANGELOG, project description). I also try to mitigate it by making it very easy to disable this default behavior. These mitigations exist precisely because I know the default behavior can be surprising, in direct contradiction to "but it's still crazy to think people won't be caught off guard by this behavior."
Not gonna lie, that was a bit creepy. We're deep in a day old thread that you have no other comments in. Do you scrape HN looking for mentions of ripgrep?
Forgive me if I'm a bit surprised!
I still stand that silent errors are significantly worse than loud ones
| it's worse to not get files you're expecting vs get more files than you're expecting. In the later case there's a pretty clear indication you need to filter while in the former there's no signal that anything is wrong. This is objectively a worse case.
> The other crazy thing here is... you don't have to use ripgrep!
If it wasn't clear, I don't ;)
I don't think grep ignoring .gitignore files is "a bug". Like you said, defaults matter. Like I said, build artifacts are one of the most common things for me to grep.
Where we strongly disagree is that I believe aliases should be used to add functionality, where you believe that it should be used to remove functionality. I don't want to start another fight (so not linking the last). We're never going to see eye-to-eye on this issue so there's no reason to rehash it.
> I don't think grep ignoring .gitignore files is "a bug".
I don't either? Like... wat. Lol.
> Where we strongly disagree is that I believe aliases should be used to add functionality, where you believe that it should be used to remove functionality.
Not universally, not at all! There's plenty of other stuff in ripgrep that you need to opt into that isn't enabled by default (like trimming long lines). There's also counter examples in GNU grep itself. For example, you have to opt out of GNU grep's default mode of replacing NUL bytes with newline terminators via the `-a/--text` flag (which is not part of POSIX).
Instead what I try to do is look at the pros and cons of specific behaviors on their own. I'm also willing to take risks. We already have lots of standard grep tools to choose from. ripgrep takes a different approach and tons of users appreciate that behavior.
> We're never going to see eye-to-eye on this issue so there's no reason to rehash it.
Oh I'm happy not to rehash it. But I will defend my name and seek to clarify claims about stuff I've built. So if you don't want to rehash it, then don't. I won't seek you specifically out.
> I don't want to start another fight (so not linking the last).
To be clear, I would link it if I knew what you were referring to. I linked our other interaction by doing a web search for `site:news.ycombinator.com "burntsushi" "godelski"`.
> If it wasn't clear, I don't ;)
OK, so you don't use ripgrep. But you're complaining about it on a public forum. Calling me rude. Calling me creepy. And then whinging about not wanting to rehash things. I mean c'mon buddy. Totally cool to complain even if you don't use it, but don't get all shocked pikachu when I chime in to clarify things you've said.
That's a fair clarification. Then you can change what I said to, "calling what I'm doing creepy." I don't think much else changes. My points certainly don't change.
Yes, it is creepy when someone randomly appears just after you allude to them. It is also creepy when someone appears out of nowhere to make their same point. Neither of you were participating in this thread and appeared deep in a conversation. Yeah, that sure seems like unlikely circumstances to me and thus creepy.
> Look at the output of `systemctl cat docker.service`
No. Either the initsystem works in a straightforward way or it doesn't. As soon as we need special commands to just get an impression of what's happening with the service, this init system can - again - fuck off with all that unnecessary complexity.
Init must be simple.
Unfortunately it isn't anymore. Unfortunately, systemd will not fuck off, it's too late for that. Unfortunately we now have to deal with the consequences of letting LP & co do what they did.
> As soon as we need special commands to just get an impression of what's happening with the service,
I agree this is bad design. I do not intend to defend `--grep` just was trying to help solve the issue. I 100% believe that this creates an unreasonable expectation of the user and that piping to grep should be expected.
Although, my results showed equal times piping to grep and dumping to file then grepping that file. IFF `--grep` is operating in parallel, then I think that's fine that it is faster and I'll take back my critique since it is doing additional functionality and isn't necessary. That situation would be "things work normally, but here's a flag for additional optimization."
Is the slowdown the file access? I do notice that it gets "choppy" if I just dump `journalctl --no-pager` but I was doing it over ssh so idk what the bottleneck was. IO is often a pain point (it pains me how often people untar with verbose...).
> you need to use the grep flag instead of piping into grep
I don't. It's the journalctl that does. And it can absolutely fuck off with everything and all of it.
Log files must be in form of text files. This worked for decades and there is no foreseeable future where this stops working or ceases to be a solution for OS log collection.
Systemd is great if your use case is Linux on a modern Desktop or Server, or something which resembles that. If you want to do anything else that doesn't fit into the project view of what you should be doing, you will be met with scorn and resistance (ask the musl team...).
What isn't great, and where the hate comes from, is that it makes the life of a distribution or upstream super easy, at the expense of adding a (slowly growing) complexity at the lowest levels of your system that--depending your perspective--does not follow the "unix way": journalctl, timedatectl, dependencies on/replacing dbus, etc. etc. It's also somehow been conflated with Poettering (he can be grating in his correctness), as well as the other projects Poettering works on (Avahi, Pulse Audio).
If all you want to do is coordinate some processes and ensure they run in the right order with automatic activation, etc. it's certainly capable and, I'd argue, the right level of tool as compared to something like k8s or docker.
My only bugbear with it is that there's no equivalent to the old timeout default you could set (note that doas explicitly said they won't implement this too). The workaround is to run it in `sudo -i` fashion and not put a command afterwards which is reasonable enough even though it worked hard against my muscle memory + copypaste commands when switching over.
> Systemd gets a lot of hate
I'd argue it doesn't and is simply another victim of loud internet minority syndrome.
It's just a generic name at this point, basically all associated with init and service units and none of the other stuff.
I was dismayed at having to go from simple clean linear BSD 4.3 / SunOS 4.1.3 era /etc/rc /etc/rc.local init scripts to that tangled rat king abomination of symbolic links and rc.d sub-directories and run levels that is the SysV / Solaris Rube Goldberg device. So people who want to go back to the "good old days" of that AT&T claptrap sound insane to me. Even Slowlaris moved on to SMF.
Oh yes, please add more! I'd love to see what others do because frankly, sometimes it feels like we're talking about forbidden magic or something lol
And honestly, I think the one thing systemd is really missing is... people talking about it. That's realistically the best way to get more documentation and spread all the cool tricks that everyone finds.
> I'd argue it doesn't
I definitely agree on loud minority, but they're visible enough that anytime systemd is brought up you can't avoid them. But then again, lots of people have much more passion about their opinions than passion about understanding the thing they opine about.
Of course. We suffered with sudo for a couple of decades already! Obviously it's wrong and outdated and has to be replaced with whatever LP says is the new norm.
All of your comments mention something existing for a long time, but X11 and ALSA and IPv4 and many more technologies have been used by people for many decades, and yet they still suck and have a replacement available.
> homed/homectl: extends user management to make it
impossible to have a clear picture of what's up with home dir, where is now located, how to have access to it or whether it will suddenly disappear. Obviously, plain /home worked for like five decades and therefore absolutely has to be replaced.
> Obviously, plain /home worked for like five decades and therefore absolutely has to be replaced.
Five decades ago, people didn't have laptops that they want to put on sleep and can get stolen. Actually, five decades ago, the rare people using a computer logged into remote, shared computers. Five decades ago, you didn't get hacked from the internet.
Today, people mostly each have their computer, and one session for themselves in it (when they have a computer at all)
I have not looked into homed yet, needs are very different from before. "It worked five decades ago" just isn't very convincing.
It'd be better to understand what homed tries to address, and argue why it does it wrong or why the concerns are not right.
You might not like it but there usually are legitimate reasons why systemd changes things, they don't do it because they like breaking stuff.
I'm quite happy with systemd on server side, it eases a lot of things there as well. And I haven't noticed homed on my servers. Did they shove homed down your throat on your servers?
Wait until you want to disable some of the built-in behaviors in Ubuntu. To make things really suck for you, they run some tasks both in crontabs AND in systemd timers. So good luck pulling hair out when you have removed apt updates from all crontabs () around but they still do.
() yeah, it's a bad idea; it was required for a specific installation where every cpu cycle counted.
I mean 5 decades ago people were using terminals, not terminal emulators. They weren't using the internet[0]. 5 decades ago Linux didn't exist, kinda making any argument moot.
[0] idk why people think Arpanet is the internet. For clarification, I'm not my das
Learning curve is not the annoying part. It is kind of expected and fine.
systemd is annoying is parts that are so well described over the internet, that it makes it zero sense to repeat it. I am just venting and that comes from the experience.
never boot into the network reliably, because under systemd you have no control over the sequence.
BTW, I think that's one of the main pros and one of the strongest features of systemd, but it is also what makes it unreliable and boot unreproducible if you live outside of the very default Ubuntu instance and such.
It has a 600s timeout. You can reduce that if you want it to fail faster. But that doesn't seem like a problem with systemd, that seems like a problem with your network connection.
> If you live outside of the very default Ubuntu instance and such.
I'm not sure which of the turds (NetworkManager, netplan) are currently installed with ubuntu and what's their relationship with systemd but I equally hate them all.
My ubuntu initiation script includes apt-get install ifupdown, which actually works unlike those two. And why bother learning because by the next ubuntu release the upcoming fanboys will replace the network stack by whatever they think they like - again.
But the bug we are discussing is probably systemd's, because the network is up and running while systemd still waits for it.
It has the slightly odd behavior with trying to get all configured links up.
This can lead to some unexpected behavior when there's more than one.
But yea, the upstream stance is essentially "don't rely on network to be up before you start. That's bad software. You have to deal with network going down and back up in practice either way."
Which is often not super useful.
If you want that bare bones of a system I'd suggest using a minimal distribution. But honestly, I'm happy that I can wrap up servers and services into chroot jails with nspawn. Even when I'm not doing much, it makes it much easier to import, export, and limit capabilities
Simple example is I can have a duplicate of the "machine" running my server and spin it up (or have it already spun up) and take over if something goes wrong. Makes for a much more seamless experience.
It's a bit tricky and first and not a lot of good docs, but honestly I've been really liking it. I dropped docker in favor. Gives me a lot better control and flexibility.
systemd-nspawn may be invoked with or without privileges. The full functionality is currently only available when invoked with privileges. When invoked without privileges, various limitations apply, including, but not limited to
Here's some cool stuff:
It's got a lot of stuff and it's (almost) all there already on your system! It's a bit annoying to learn, but it really isn't too bad if you really don't want to do anything too complicated. But in that case, it's not like there's a tool that doesn't require docs but allows you to do super complicated things.