21–30 of 254 posts
My eyeballs just exploded... Unreadable.
http://www.steven-mcdonald.id.au/ugly.shtml :D He should still ditch the yellow though.
Earlier quoted context omitted.
I'm not a professional sysadmin, but as a developer with a bunch of virtual servers systemd has only made things far easier. Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... Maybe there's something to be said for "sysadmins who want to be able to model the entire boot process and run-state in their head" but with correct information about dependencies and so on,…
...and that's awesome if you don't need 99.9% uptime and thus need to have absolute faith in your system's stability. However, for mission-critical applications that do it's hard to argue that systemd is a better solution than writing all your scripts by hand. Unless you want to be able to blame systemd if it all goes pear-shaped but I doubt your boss will buy it =)
I'm also a developer and for example one problem I had with my servers on AWS was that my process sometimes happened to start before my volume meant for logs was mounted, which meant that all logs were going to my primary volume, with the server crashing at some point due to out of space errors. Another time I was using a local database meant for local caching and again, sometimes it would fully initialize only after my main process was started.
And because I was using ELB with auto-scaling, it meant that these incorrectly started servers would be connected to the load-balancer, because the main process was suddenly responding to /ping, even though it wasn't ready yet. And then it would receive thousands of requests per second per server, at a moment in time in which the cluster badly needed fresh instances, which led to an unstable cluster. But only sometimes ;-)
My eyeballs just exploded... Unreadable.
> Try to find the answer to "which units are going to be started on next boot?".
Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up)
Also the other states:
> Speaking of which, why is systemctl daemon-reload even a thing?
Because configuration changes while things are running. Otherwise we wouldn't need apache2 reload, nginx reload, haproxy reload, etc. Also, according to the man page:
> After the units have been edited, systemd configuration is reloaded (in a way that is equivalent to daemon-reload).
As for systemctl edit, it allows you to add diffs to the unit file. For example, let's say I am using redis and I want to ensure it always restarts (for whatever reason). Rather than manually editing the unit file (which will have issues if an upstream change happens), I can simply use systemctl edit to add a diff for my change. This way I can still maintain compatibility with the upstream unit file instead of having to deal with potential conflicts. It's not so much babysitting the user as it is a potentially better experience.
The author mentions that he believes the biggest problem of systemd is repeating some mistakes of SysV init, but I think it's actually pretty important that familiarity is preserved to help people upgrade. For example, the author mentions babysitting the users (systemctl edit) and config/daemon reloading as things that could be made automatic, I'm assuming with e.g. inotify change events. But you often want some conf…
With systemd, you do the exact same thing and then call systemctl reload daemon. Is the author making an argument here based some other distributions way of handling System V?
My eyeballs just exploded... Unreadable.
There is a lot of development in the ecosystem dominated by Freedesktop.org, Gnome and (to some degree) large commercial players like RedHat and SUSE. It's more efervescent than it's ever been. Fifteen years ago, I'd have been ecstatic to see so much development being done.
Yet for all this fierce code churning, there's absurdly little innovation. Even in systemd, there's a lot of focus on non-issues like booting without needing a shell, while still inventing service startup notification types because none of the gazillion startup notification types already existent can actually solve precisely the problem systemd claims it solves -- managing complex startup chains.
In the last three or four years, my Linux systems have become increasingly blackboxed, and consequently harder and harder to configure, let along debug when they stop working. Over the span of six months, a tool you just got to learn how to work with (mostly because the documentation seems to have been written by very bored and very verbose monkeys who had only a typewriter to pass the time with) becomes obsolete or is revamped to be unrecognizable. Which would be fine if that actually solved any problems. Instead, it replaces the old set of problems with a new, even more complicated set of problems that developers claim you shouldn't have, while insisting that the old problems were simply due to the old architecture and we'll have none of that now that we have this shiny new thing.
Ironically, systemd is actually one of the better pieces of software to come out of that ecosystem. No, seriously. It's decently documented and as long as you don't need anything more complex than "here, start this daemon after this other daemon started", it does its job.
If you want to peck at something, have a look at Polkit, where someone brilliantly figured out that the best way to configure policies is to write basically undebugable JavaScript code in .rules files.
It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd. I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-…
For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifying way to manage a startup process, and just about anything -- including Yet Another Config File Format -- looks preferable.
I think this is also why so little progress is being made on resolving conflicts over systemd. There really isn't a whole lot of room for compromise; one group simply wants things to stay more or less the same (or evolve incrementally), the other group simply wants to throw it all out and start over.
I bet there would've been a lot less argument and vitriol about systemd if Debian hadn't made the decision to default to it, basically leaving all the crusty sysadmins homeless. Once Debian switched, there was a near guarantee that all of Linux was going to move to systemd. That suits one group just fine, another one not so much.
On the plus side, the BSDs should be seeing a really nice upswell of installations over the next couple of years, which is great, because they've been quietly building some pretty great operating systems that deserve more love.