Poettering: Why systemd?
Poettering: Why systemd?
Posted Apr 29, 2011 13:17 UTC (Fri) by AlexHudson (guest, #41828)Parent article: Poettering: Why systemd?
Posted May 4, 2011 14:45 UTC (Wed)
by blahdong (guest, #74701)
[Link] (27 responses)
http://monolight.cc/2011/05/the-systemd-fallacy/
Posted May 4, 2011 14:55 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (22 responses)
Posted May 4, 2011 18:21 UTC (Wed)
by jubal (subscriber, #67202)
[Link] (21 responses)
Would you make the minimal effort and look at the the site, you'd find that the author is not anonymous.
Would you actually read the article, and not only the first sentence, you'd realise that you just attacked a straw man.
Sadly, it seems you did neither.
Posted May 4, 2011 18:24 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (20 responses)
Posted May 4, 2011 18:32 UTC (Wed)
by vriesk (guest, #71607)
[Link] (9 responses)
Posted May 4, 2011 19:09 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (8 responses)
What kind of incoherent statement is that and where are you getting it from? I read it entirely and don't find any merit in any of the claims like I said. I have already highlighted the fact that systemd is of benefit to servers despite the author's claim. Even Lennart's sysadmin series covers a a number of them. If you want one more, systemd uses cgroups to keep track of all processes spawned by a service and can kill all of them when a service is stopped. The blog suggests directly using cgroups for this purpose and forgoing the useful integration altogether. That makes no sense to me.
Posted May 4, 2011 21:09 UTC (Wed)
by tgr1 (guest, #74710)
[Link] (7 responses)
thanks for your input. I'm the author of that post and I'm by no means anonymous - my name is right there on the site.
Generally, you have two (or more) tools to easily manage cgroups: mkdir and echo. Obviously, changes made that way can't be made permanent without shell scripts executed during the boot process. There is no reason not to use cgroups-related settings in SysV, OpenRC or other existing boot scripts. And you also have libcgroup utils.
However, cgroups support code integrated into PID 1 is the least of systemd's issues. It's not the only redundant feature, unfortunately.
Anyway, I welcome the point of view of a Fedora contributor. I do understand why these arguments seem to have no merit for you. Remember I explicitly stated that systemd may be useful to desktop and embedded vendors.
OTOH, I still fail to see any real benefits of systemd to servers. Nothing that can't be achieved with readily available dedicated tools - without bloating init.
Streamlining the boot process is a cool thing to do, but not at the cost of abandoning the simplicity of classic script-based boot processes. Unix and POSIX are not dogmas, nor are they sacred. Questioning and/or modifying these standards in an evolutionary process is one thing, but throwing away a huge part of them in one go is a bit worrisome to say the least.
Posted May 4, 2011 21:32 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
Sure, cgroups has a bunch of disparate utilities to manage it. However arguing that it makes systemd integration redundant or bloat just doesn't make sense. When you start a service and want to kill all the processes, do you think mkdir and echo is easier than systemctl kill? Honestly? I guess my memories of managing rouge cgi scripts in hosted environments gives me a different perspective here.
My viewpoints here are not merely as a Fedora contributor but someone who started out as a system admin managing thousands of servers over several years professionally.
You argue on one hand that Red Hat is pushing this and simultaneously also want to argue that it is not useful for servers. For one, systemd was started as a part time project of Lennart with participation from Kay (Novell) and Red Hat has a lot more interest in the server than desktops or embedded systems to say the least.
It is not clear to me that you even tested systemd at all other than just reading blog posts and forming opinions. The question really is not whether on can do without systemd on the servers. That can certainly be done but is systemd making it easier or convenient for system admins to manage servers? Does it make features that makes it better?
Th current ad-hoc and distribution specific shell scripts that one has to put up with to manage booting and daemons are nowhere near simple or straight forward. The simplicity of the .desktop style unit files is a huge plus for systemd as evident from
https://lwn.net/Articles/401593/
Posted May 4, 2011 23:01 UTC (Wed)
by tgr1 (guest, #74710)
[Link] (5 responses)
Now, you're attacking a straw man. You know full well you don't kill cgroup-managed rogue CGI scripts with mkdir and echo - you do that with kill, ps, cat, awk, whatever you like. Killing all tasks within a cgroup is as easy as "xargs < /sys/fs/cgroups/cgroup1/tasks kill". Or you can get more specific and only kill those rogue CGIs but not httpd. You can kill them in parallel with xargs, etc. cgroups already track tasks for you if the original parent was moved to a cgroup at startup - even after the parent is gone. Honestly - you can do this conveniently without systemd.
We have yet to see what Red Hat does - as I already mentioned here, we have 2-3 years until the next major RHEL release. It's hard to speculate.
Regarding your question: I did test systemd.
The whole point is that to me (and a lot of Linux ops folks out there) systemd will ultimately make it harder, not easier to manage servers. Obviously, everybody's entitled to their own opinion - and seeing the recent popularity of systemd we may all be actively using it in a few years.
The "ad-hoc" (site-specific) and distribution-specific scripts are easy to read and, more importantly, flexible, the scripts being written in a simple imperative language. .service files may be _shorter_, but they're nowhere near shell scripts when it comes to functionality. That's one of my major points: if you need to change something deep in the startup/shutdown process, you don't have to modify systemd or daemon code and recompile. Plus you need explicit support from the daemons if you want them to be fully compatible with systemd. Of course, a lot of 3rd party vendors will probably be unwilling to support systemd, so you will end up with shell scripts anyway.
Posted May 4, 2011 23:20 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
You can do this *more* conveniently with systemd *and* it is a compile time option. I am already using it and it well worth the integration as far as I am concerned.
"We have yet to see what Red Hat does - as I already mentioned here, we have 2-3 years until the next major RHEL release. It's hard to speculate."
No speculation necessary. Look at the entire history of major Fedora features sponsored by Red Hat and name one which hasn't landed up in the subsequent RHEL. Hint: There isn't one. I can wager a bit that it will land up EL 7 or even earlier.
"The whole point is that to me (and a lot of Linux ops folks out there) systemd will ultimately make it harder, not easier to manage servers"
This seems to be just handwaving. Who are those unnamed Linux ops out there and how is it making it harder for them, exactly?
"The "ad-hoc" (site-specific) and distribution-specific scripts are easy to read"
If you can read say a 100 lines (do remember to count all the include files) better than say 11 lines, sure.
"if you need to change something deep in the startup/shutdown process, you don't have to modify systemd or daemon code and recompile."
Fedora 15 uses systemd by default and noone has presented a single case where it is required to recompile anything. You are just making things up here.
"Plus you need explicit support from the daemons if you want them to be fully compatible with systemd"
No. A few daemons like rsyslog needs a tiny patch and they are all upstream already. Rest of them are already full compatible. systemd is compatible with sysvinit scripts and hence if third party software doesn't get modified, no big deal. Yeah, you might end up with some shell scripts in some cases. So what? This makes the whole contention that systemd is eliminating your precious shell scripts pretty pointless. You can't have it both ways.
Posted May 5, 2011 8:50 UTC (Thu)
by aniou (guest, #74708)
[Link] (2 responses)
Posted May 5, 2011 9:57 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
http://0pointer.de/blog/projects/the-new-configuration-fi...
If you are so against it anyway, feel free to use another init system.
Posted Feb 11, 2014 1:02 UTC (Tue)
by gvy (guest, #11981)
[Link]
> If you are so against it anyway, feel free to use another init system.
Posted May 11, 2011 19:52 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted May 4, 2011 19:25 UTC (Wed)
by aniou (guest, #74708)
[Link] (9 responses)
From my POV systemd is created and maintained by developers who doesn't understood and doesn't care about sysadmins work. See following thread: http://lists.freedesktop.org/archives/systemd-devel/2011-... - "shell scripts used for glue things together. Bueh! It's unclean, it's impure, all daemons should works in one way, OUR WAY".
Posted May 4, 2011 19:43 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
https://lwn.net/Articles/441431/
I have explicitly highlighted two items already. systemd services can call shell scripts just fine if one needs it. Anyone who has bothered to try it out in a system instead of just reading blog posts can figure this out.
ExecStart=/bin/myfavshellscript
Posted May 4, 2011 21:04 UTC (Wed)
by aniou (guest, #74708)
[Link] (3 responses)
Posted May 4, 2011 21:06 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted May 4, 2011 21:22 UTC (Wed)
by aniou (guest, #74708)
[Link] (1 responses)
It isn't nice.
Posted May 4, 2011 21:35 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 4, 2011 20:42 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (3 responses)
I just read that thread and nobody seems to actually say that (or anything to that effect) there.
Posted May 4, 2011 21:05 UTC (Wed)
by aniou (guest, #74708)
[Link] (2 responses)
Posted May 4, 2011 21:31 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (1 responses)
No. I think there is a considerable difference between what Lennart said in that posting (»In my opinion, a database server should be able to take care of its own version upgrades on databases and not push that into distribution-specific shell code«) and what you claim he said (»Shell scripts are stupid and I am right about everything«). In fact, I happen to think that Lennart has a point. Anyway, there are probably lots of things worth criticising about systemd that actually exist. Personally I would suggest that if you must diss Lennart and systemd it would be a much more profitable use of everybody's time to address these instead of inventing your own fictional ones.
Posted May 5, 2011 8:23 UTC (Thu)
by aniou (guest, #74708)
[Link]
Yes, of course, with simple installation, on single machine, witch typical scenarios it's doesn't matter - is databases created from script or by daemon. But uni*xes strength comes from diversity and - again - flexibility. Users and operators probably never deals with non-standard installs, but admins - yes.
Lennart's rants about separate /usr or /var ("Go to Slackware 1.0 then"), surprises with DoS via /run/user (and their "workaround", blah: http://lists.freedesktop.org/archives/systemd-devel/2011-...) clearly shows me that he isn't a sysadmin and don't care about different needs. But he has vision. This isn't enough for reliability and flexibility.
PS. that wasn't fictional case, I took it from official mailing-list.
Posted May 4, 2011 19:53 UTC (Wed)
by njs (subscriber, #40338)
[Link] (3 responses)
Posted May 4, 2011 21:19 UTC (Wed)
by tgr1 (guest, #74710)
[Link] (2 responses)
you seem to have misunderstood the post. I explained the ideas behind every single argument. Yet you're making some unsubstantiated claims yourself - let's go over them. Again: cgroups can be easily used without systemd or other PID 1 support - that's it. If the section on dependencies seems confused to you, I really have nothing to add other than a suggestion that you read up on System V init - and/or state what exactly is confused. automounter: did you ever see it fail on a live (server) system - not on a workstation you can just happily reboot? Well, I did. Red Hat and servers: obviously, having just released RHEL 6, they have 2-3 years until the next major release. I guess we have to wait and see what they decide. Nowhere did I claim RH is pushing systemd down anyone's throat.
Posted May 5, 2011 2:25 UTC (Thu)
by njs (subscriber, #40338)
[Link] (1 responses)
Yes, but they cannot be easily used to reliably manage all the various daemons etc. on your system without substantial integration effort to make sure that everything ends up in its own cgroup, new tools to manage those cgroups and match them up with the relevant daemons, etc. That's what systemd provides. You can't just say that some software is useless because the new features it provides are based on an already existing kernel API and other software could also potentially be written to provide those same features.
> If the section on dependencies seems confused to you
I understand System V init, but I can't understand what that paragraph in your blog post is saying. AFAICT, you don't like systemd because (1) you think dependencies are important, and (2) serial is just as good as parallel because only end-to-end speed matters. Systemd, of course, provides a much richer (and more reliable, etc.) way of managing dependencies than previous systems, and the whole point of parallel is that it improves end-to-end speed. So I can't reconcile your argument with how any of the stuff being talked about actually works.
> automounter: did you ever see it fail on a live (server) system
Sure, but I've seen tons of things fail on live systems. Hard drives, database servers, network drivers, you name it. There's definitely an interesting discussion to be had here, about the current reliability of the Linux autofs implementation and about its long term prospects for robustness (i.e., after Fedora and SuSE and everyone start pounding on it much more heavily and fixing bugs in the process). But just saying "I have seen this thing fail once and also I am a Serious Person who manages Serious Servers, not like you effete desktop users" is not an argument.
> Nowhere did I claim RH is pushing systemd down anyone's throat
You said that despite systemd's obvious brokenness, it would still be an "arduous fight" to keep it off our systems, because of "Red Hats financial backing".
Posted May 11, 2011 20:02 UTC (Wed)
by nix (subscriber, #2304)
[Link]
1) it failed because of a kernel bug causing the automounter to fail where mount(8) of that filesystem would succeed. Such bugs are not common, and the right solution is simply to fix it. Kernel bugs could have arbitrarily horrible effects: merely breaking the automounter seems like quite a minor one. And the rest of the system still works.
2) it failed because mount(8) of that filesystem failed (perhaps it is an infinitely-hanging NFS mount and you forgot to tell it to time out faster). This would have hung a conventional serial boot completely, leaving you out in the cold. With systemd, the rest of the system still works.
systemd seems like an improvement to me here.
Poettering: Why systemd?
I encourage you to read article with opinions about systemd design flaws:
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd? (and kill off other implementations, period!)
You clearly underestimated Department of Redhat, our smart one.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
"shell scripts used for glue things together. Bueh! It's unclean, it's impure, all daemons should works in one way, OUR WAY".
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?