Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
Poettering: Why systemd?
Posted May 4, 2011 18:32 UTC (Wed) by vriesk (guest, #71607)
Posted May 4, 2011 19:09 UTC (Wed) by rahulsundaram (subscriber, #21946)
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)
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)
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
Posted May 4, 2011 23:01 UTC (Wed) by tgr1 (guest, #74710)
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)
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)
Posted May 5, 2011 9:57 UTC (Thu) by rahulsundaram (subscriber, #21946)
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)
Posted May 4, 2011 19:25 UTC (Wed) by aniou (guest, #74708)
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)
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.
Posted May 4, 2011 21:04 UTC (Wed) by aniou (guest, #74708)
Posted May 4, 2011 21:06 UTC (Wed) by rahulsundaram (subscriber, #21946)
Posted May 4, 2011 21:22 UTC (Wed) by aniou (guest, #74708)
It isn't nice.
Posted May 4, 2011 21:35 UTC (Wed) by rahulsundaram (subscriber, #21946)
Posted May 4, 2011 20:42 UTC (Wed) by anselm (subscriber, #2796)
"shell scripts used for glue things together. Bueh! It's unclean, it's impure, all daemons should works in one way, OUR WAY".
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)
Posted May 4, 2011 21:31 UTC (Wed) by anselm (subscriber, #2796)
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)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds