Poettering: Why systemd?

Posted May 4, 2011 14:55 UTC (Wed) by rahulsundaram (subscriber, #21946)
In reply to: Poettering: Why systemd? by blahdong
Parent article: Poettering: Why systemd?

Anonymous blog posting with a incorrect claim right off the bat that systemd is not useful for servers when so many of the features are designed towards servers? Color me interested ... not.

Poettering: Why systemd?

Posted May 4, 2011 18:21 UTC (Wed) by jubal (subscriber, #67202) [Link] (21 responses)

Rahul,

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.

Poettering: Why systemd?

Posted May 4, 2011 18:24 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (20 responses)

I read the entire posting and don't find a real merit. It seems someone decided to read a few blog entries and talk about it without looking any further or any real usage. About section is empty. That is enough time wasted.

Poettering: Why systemd?

Posted May 4, 2011 18:32 UTC (Wed) by vriesk (guest, #71607) [Link] (9 responses)

So, you're saying that you read it without actually reading it or something? The claims there are quite serious and if they're incorrect, it would be kinda nice to explain why. If they're correct, systemd is screwed.

Poettering: Why systemd?

Posted May 4, 2011 19:09 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (8 responses)

"So, you're saying that you read it without actually reading it or something?"

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.

Poettering: Why systemd?

Posted May 4, 2011 21:09 UTC (Wed) by tgr1 (guest, #74710) [Link] (7 responses)

Rahul,

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.

Poettering: Why systemd?

Posted May 4, 2011 21:32 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

You need to fill in your about section in your blog. I don't want to go around looking for a name elsewhere but thanks for responding here

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/

Poettering: Why systemd?

Posted May 4, 2011 23:01 UTC (Wed) by tgr1 (guest, #74710) [Link] (5 responses)

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.

Poettering: Why systemd?

Posted May 4, 2011 23:20 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

"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] (2 responses)

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] (1 responses)

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? (and kill off other implementations, period!)

Posted Feb 11, 2014 1:02 UTC (Tue) by gvy (guest, #11981) [Link]

And I was foolish enough to blame monit authors for including smtp client within it.

> If you are so against it anyway, feel free to use another init system.
You clearly underestimated Department of Redhat, our smart one.

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.

Poettering: Why systemd?

Posted May 4, 2011 19:25 UTC (Wed) by aniou (guest, #74708) [Link] (9 responses)

What's wrong with tgr's article? Tell me, please. Don't wrote "I don't find real merit", tell: "They lacks merit because ...". I want arguments, not propaganda - I'm really tired of reading manipulations, like this table: http://0pointer.de/blog/projects/why.html. For example: "Conditional execution: by file existance". WTF? When it's not embedded into C-routine it's doesn't count? It's insanity. Or manipulation ("More, more, I need more red squares for init column!").

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".

Poettering: Why systemd?

Posted May 4, 2011 19:43 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

It appears you missed out.

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

Poettering: Why systemd?

Posted May 4, 2011 21:04 UTC (Wed) by aniou (guest, #74708) [Link] (3 responses)

But... it's "wrong way"?
See: http://lists.freedesktop.org/archives/systemd-devel/2011-...

Poettering: Why systemd?

Posted May 4, 2011 21:06 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

It isn't the recommended way since systemd cannot babysit the process anymore but if you want to do it anyway, systemd allows that. If you want to ignore the recommendation, nothing is stopping you.

Poettering: Why systemd?

Posted May 4, 2011 21:22 UTC (Wed) by aniou (guest, #74708) [Link] (1 responses)

So... I have choice between inflexibility (someone may be stunned by this, but yes, sometimes admins needs non-standard behavior) or missing functionality and lack of support in problematic situation ("you doing it in wrong way, pal! sorry!")?

It isn't nice.

Poettering: Why systemd?

Posted May 4, 2011 21:35 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

What inflexibility? If you use shell scripts, you don't get some of the extra benefits of systemd but you are no worse off than when you are using sysvinit. The support and functionality is equivalent in that case

Poettering: Why systemd?

Posted May 4, 2011 20:42 UTC (Wed) by anselm (subscriber, #2796) [Link] (3 responses)

"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.

Poettering: Why systemd?

Posted May 4, 2011 21:05 UTC (Wed) by aniou (guest, #74708) [Link] (2 responses)

You probably missed this: http://lists.freedesktop.org/archives/systemd-devel/2011-...

Poettering: Why systemd?

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.

Poettering: Why systemd?

Posted May 5, 2011 8:23 UTC (Thu) by aniou (guest, #74708) [Link]

Lennart's opinion about "valid" daemon's behavior is very, very wrong. And this is not opinion from more-or-less anonymous reader - this is opinion systemd creator and developer. Sorry, I don't see any pros from (for example) MySQL that creates missing databases itself. But I see drawbacks thats may lead to subtle and annoying situations.

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.