Recent Features
| |||||||||||||
Poettering: Why systemd?Poettering: Why systemd?Posted May 4, 2011 23:01 UTC (Wed) by tgr1 (guest, #74710)In reply to: Poettering: Why systemd? by rahulsundaram Parent article: Poettering: Why systemd?
You're right about that about page - I need to get around to it. :)
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.
(Log in to post comments)
Poettering: Why systemd? Posted May 4, 2011 23:20 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
"Honestly - you can do this conveniently without systemd."
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.
Poettering: Why systemd? Posted May 5, 2011 8:50 UTC (Thu) by aniou (guest, #74708) [Link]
You said, that systemd doesn't eliminate scripts. In developer's opinion scripts aren't the valid or best way do deal with, but OK - so... could You tell me, WHAT good things systemd brings to me on my servers? I still have scripts (but, at this time I have them on my responsibility) and I have... primitive process respawning? System-wide locale handling? Whoa! Colorized logs? Oh, really, I always want log colorizer in my init!
Poettering: Why systemd? Posted May 5, 2011 9:57 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
I am not going to repeat myself but a few obvious things include automatic restarting of services, cgroup integration, chroot with systemd-nspawn and many more, There is a entire series of blog posts that talks about various features including server side ones. Links on the top of
http://0pointer.de/blog/projects/the-new-configuration-fi...
If you are so against it anyway, feel free to use another init system.
Poettering: Why systemd? Posted May 11, 2011 19:52 UTC (Wed) by nix (subscriber, #2304) [Link]
Also, it's not as if systemd removes -- or could ever remove -- the possibility to replace your binary with a wrapper shell script that does whatever necessary (as INND long has with its rc.news script). If you arrange for that script to not exec the daemon but instead keep running, stop daemonizing, and quit when the daemon does, and systemd can even monitor it automatically, just as if it were a real daemon.
|
|||||||||||||