|
|
Log in / Subscribe / Register

Poettering: Why systemd?

[Posted April 29, 2011 by corbet]

Lennart Poettering has put up a lengthy page on why systemd exists. "systemd is also a big opportunity for Linux standardization. Since it standardizes many interfaces of the system that previously have been differing on every distribution, on every implementation, adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. This improves the lifes of programmers, users and administrators alike." (Thanks to Paul Wise).
to post comments

Poettering: Why systemd?

Posted Apr 29, 2011 13:17 UTC (Fri) by AlexHudson (guest, #41828) [Link] (28 responses)

Systemd is incredibly awesome; anyone who hasn't had a play around with it yet should check out Lennart's sysadmin guide. The alternative to chroot it has (systemd-nspawn) is such a huge win for me I can't wait to get it on all my systems.

Poettering: Why systemd?

Posted May 4, 2011 14:45 UTC (Wed) by blahdong (guest, #74701) [Link] (27 responses)

Well I read about systemd. Then I read more about it, especially about the design and the impact it may have on future Linux systems.
I encourage you to read article with opinions about systemd design flaws:

http://monolight.cc/2011/05/the-systemd-fallacy/

Poettering: Why systemd?

Posted May 4, 2011 14:55 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (22 responses)

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.

Poettering: Why systemd?

Posted May 4, 2011 19:53 UTC (Wed) by njs (subscriber, #40338) [Link] (3 responses)

I have no dog in this fight, but that post didn't impress me at all. Lots of incoherent technical arguments (e.g., 'we can already use cgroups to do what cgroups do, so why switch to software the uses cgroups'), obvious misunderstandings (the section on dependencies is just confused), unsupported assertions ("There is no way to do autofs right"), contradictory arguments (systemd is designed only for the desktop; Red Hat is trying to push systemd down our throats -- because Red Hat cares only about the desktop, I guess?). Clearly they have their opinions and that's cool. Making design decisions involves a significant element of hard-to-articulate 'taste', and clearly Lennart's taste pisses their's right off. And goodness knows that Lennart takes rhetorical stances that encourage this kind of low-content response. But I also tend to learn things from Lennart's posts; I didn't from this one.

Poettering: Why systemd?

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

njs,

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.

Poettering: Why systemd?

Posted May 5, 2011 2:25 UTC (Thu) by njs (subscriber, #40338) [Link] (1 responses)

> cgroups can be easily used without systemd or other PID 1 support

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 Hat’s financial backing".

Poettering: Why systemd?

Posted May 11, 2011 20:02 UTC (Wed) by nix (subscriber, #2304) [Link]

Also: if the automounter fails, there are two possibilities:

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?

Posted Apr 29, 2011 13:20 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Yup. We've just replaced SysV-based init infrastructure from our embedded devices and achieved faster boot _and_ smaller total footprint.

Poettering: Why systemd?

Posted Apr 29, 2011 14:02 UTC (Fri) by welinder (guest, #4699) [Link] (84 responses)

Those yes/no tables really places that article in the "advertisement"
category. Untrustworthy advertisement even.

sysvinit does't handle swap? bah!

If you can't trust that the other guys are remotely fairly evaluated
the whole thing becomes pointless. It makes me wonder what is being
hidden.

Poettering: Why systemd?

Posted Apr 29, 2011 14:14 UTC (Fri) by lkundrak (subscriber, #43452) [Link]

I particularly enjoy the "SCM" row in "Misc" table.
(FWIW I share the opinion expressed, and find systemd awesome too)

Poettering: Why systemd?

Posted Apr 29, 2011 14:16 UTC (Fri) by handock (guest, #73633) [Link] (78 responses)

The comparison tables are ridiculous. Almost all entries are handled by sysvinit and Upstart pretty well.

I have tested systemd for a few days and discovered that the (small) gain is not worth the pain. You end up constantly fighting against its design decisions.

The whole kitchen sink approach of systemd goes straight against the UNIX philosophy. (That's why I use minit as my init system. It's small, fast and reliable)

Poettering: Why systemd?

Posted Apr 29, 2011 15:08 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

As far as I understand, you're free to customize any aspect of systemd. Including using old SysV-style initscripts if you so desire it.

Poettering: Why systemd?

Posted Apr 29, 2011 17:18 UTC (Fri) by AndreE (guest, #60148) [Link] (31 responses)

People constantly bring up the UNIX philosophy. I often wonder what exactly that means. If they are talking about each program doing one thing well, then sysv init fails in that it only performs a fraction of task you expect it to.

Or maybe they are referencing the UNIX haters handbook which describes the UNIX philosophy as "good enough".

Poettering: Why systemd?

Posted Apr 30, 2011 7:01 UTC (Sat) by jcm (subscriber, #18262) [Link] (30 responses)

Perhaps you expect your *init* system to do more than it should? To me, it should start and stop tasks when I ask it to, and that's pretty much it. Those tasks can include scripts that do other stuff, like mounting filesystems, cleaning up tmp directories, and so forth, but I don't want the rest hard wired in. It goes against UNIX philosophy, which has lived for 40 years and deserves more respect than it is being given in recent times.

Sorry, but no...

Posted Apr 30, 2011 9:06 UTC (Sat) by khim (subscriber, #9252) [Link]

Perhaps you expect your *init* system to do more than it should? To me, it should start and stop tasks when I ask it to, and that's pretty much it.

Sorry, but this is just soooo wrong. Unix design implies that init should do much more. It must manage all orphaned tasks - for they become childs of init if their parent dies. The fact that most init systems don't bother just means they are inherently broken.

SystemD is not perfect, but it least it TRIES to do what it's SUPPOSED to do. Most other init systems just refuse to do the work.

Poettering: Why systemd?

Posted Apr 30, 2011 9:18 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

I respect the Unix philosophy. I also respect other software design philosophies, and sometimes these come into conflict. I do not hold the Unix philosophy in such high esteem that I will treat it as a trump card in such a conflict.

Poettering: Why systemd?

Posted Apr 30, 2011 10:41 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (27 responses)

From all these talks I figured out that the Unix philosophy is:
1) Everything was already invented and perfect 40 years ago.
2) Everything else must be implemented using shell scripts and pipes.

Correct?

Poettering: Why systemd?

Posted Apr 30, 2011 11:55 UTC (Sat) by HelloWorld (guest, #56129) [Link]

+1
That's pretty much how I feel about it too when people keep whining about how something violates the "Unix philosophy".

Poettering: Why systemd?

Posted Apr 30, 2011 18:42 UTC (Sat) by jcm (subscriber, #18262) [Link] (23 responses)

A lot of problems have already been solved, 10, 20, 30, and 40 years ago. UNIX philosophy is not wrong just because it's old, and re-invention is not required just because some kid graduated college and is looking for something to do to "shake things up". A happy compromise is to extend what's there and re-invent only when really, truly necessary.

And is UNIX philosophy a trump card to me? Absolutely. It got us this far and making billions of dollars.

Jon.

Poettering: Why systemd?

Posted Apr 30, 2011 18:49 UTC (Sat) by jcm (subscriber, #18262) [Link] (18 responses)

Oh, and to add to that, there is today a huge sense of arrogance from a growing minority that they know better (this isn't targeted at systemd, it's a general problem) than everyone else and standards be damned. Everything is too readily dismissed as old and out of date, and standards are dismissed just because they might be hundreds or thousands of pages long, or not updated in a few years. At the same time, those same standards and existing technologies are why you can take for granted that your system will boot or be able to talk to others, or create a soapbox to stand on.

There needs to be a slow train departing from a station somewhere around here. On board the train will be those who care more about "fit and polish" than throwing away well established protocol and tradition.

Jon.

Poettering: Why systemd?

Posted Apr 30, 2011 19:01 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

There exist conservative FLOSS platforms for those who want them.

Poettering: Why systemd?

Posted Apr 30, 2011 21:38 UTC (Sat) by khim (subscriber, #9252) [Link]

Oh, and to add to that, there is today a huge sense of arrogance from a growing minority that they know better (this isn't targeted at systemd, it's a general problem) than everyone else and standards be damned.

Funny, I think it's majority already. And their arrogance is justified. Where are "standard-compliant" technologies like CDE, Motif or STREAMS? Or how about ISO-standard document format? Gone. They are not exactly extinct, but nobody cares about them.

Everything is too readily dismissed as old and out of date, and standards are dismissed just because they might be hundreds or thousands of pages long, or not updated in a few years.

No. They are dismissed when they are not used. C++ standard, for example, is not exactly small - but GCC tracks it religiously because users care about it. When nobody else cares... why the developers should care? Who will benefit if LibreOffice will ever implement ISO/IEC 29500-1:2008? If anything they should implement standard de-facto implemented by MS Office - and this quite different story.

There needs to be a slow train departing from a station somewhere around here. On board the train will be those who care more about "fit and polish" than throwing away well established protocol and tradition.

No problem. Switch to OpenBSD or FreeBSD. These guys are polishing everything to unimaginable degree. Not in a sense "make it actually useful", but in a sense "make everything right" (according to some kind of "right" - different in each case).

Why isn't desktop Linux "finished"?

Posted May 2, 2011 6:32 UTC (Mon) by Cato (guest, #7643) [Link] (15 responses)

I really want a desktop Linux that's easy to configure and also has "fit and polish". Ubuntu used to be this distro, but having upgraded an 8.04 system recently to 10.04.2 LTS, I've found these significant issues, one of them with upstart:

- CUPS won't start reliably due to Upstart, so I have to put a "cups restart" into /etc/rc.local to be sure. Oh the irony, the next-gen replacement for init is forcing me to put hacks in... http://ubuntuforums.org/showpost.php?p=9440474&postco...

- Kernel mode setting doesn't work at all on Intel GMA3100 for recovery mode login with framebuffer (though X does work). This is a very common GPU included in many motherboards (G33 chipset) and worked flawlessly in 8.04.

- keyboard mapping was completely messed up due to an old xmodmap config file being left behind

- there's a still undiagnosed problem where the system hangs (100% CPU, can't run any commands after many minutes)

This is a vanilla Ubuntu system with only standard packages like Firefox and Thunderbird installed, and has run 8.04 very reliably for three years now. Hardware was chosen to be commonly used and reliable, as it's used by an elderly relative who lives some way away.

I've spent a long time fixing these and other issues after the 8.04 upgrade, and I've been using Linux for 10+ years and Unix for much longer.

My point is that if desktop Linux is so badly "finished" in an LTS release that has had *one year* for serious bugs to be fixed, what hope is there for ordinary mortals to adopt it? This isn't an Ubuntu flame, as I'm not sure other distros are any better, unless perhaps they are much slower to adopt new technologies.

I know that Upstart/Systemd and (to some extent) kernel mode setting have advantages, but I'm not convinced that, without real investment in detailed regression testing across a wide range of hardware, Linux distros are really able to deliver this new technology to end users who are not Linux experts.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 8:27 UTC (Mon) by jrn (subscriber, #64214) [Link] (14 responses)

> This isn't an Ubuntu flame, as I'm not sure other distros are any better

I don't know --- have you tried other distro (or other Ubuntu release) livecds? If you are used to Ubuntu LTS and prefer to stick with it, have you tried reporting bugs?

Kernel mode-setting in particular is something where you'll probably find a more up-to-date graphics stack (or one old enough to precede kernel mode-setting altogether) works better. Finding the right fixes to backport to an old graphics stack can be hard, unless there are active users with the same hardware reporting bugs.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 9:36 UTC (Mon) by Cato (guest, #7643) [Link] (13 responses)

Good point about KMS - since most distros will have KMS in the kernel+Xorg already, I think the destabilisation is probably fairly widespread - see http://www.google.co.uk/search?q=kms+hang+linux for examples.

Sounds like KMS probably shouldn't be in an LTS release at all... however, 18 months since its introduction in Ubuntu 9.10 should be enough to stabilise it on an older Intel GPU which has had open source drivers forever.

Of course I should do some bug reports but the sheer number of issues I've had, and seriousness of some of them, make it hard to spend the time logging bugs.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 14:23 UTC (Mon) by bazsi (guest, #63084) [Link] (12 responses)

At least in one case I've found similar problems when _upgrading_. Reinstalling from scratch fixed most of my issues. Especially CUPS rang a bell, but I had similar problems with video (nvidia though).

And I'm not that reinstall if there's a problem kind of guy, but finding obsolete files scattered in .d directories to fix problems takes an immense amount of time.

When I realized the root cause (obsolete packages leaving .d files around), I started to feel they are not such a good idea after all, or at least dpkg/apt should support them better.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 15:08 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (10 responses)

In my experience with Debian, obsolete .d files are typically left behind by packages which have been "removed" but not "purged" (status "rc" in the output of "dpkg -l", or filter "?config-files" in aptitude). They're considered configuration files, and thus not automatically removed along with the package. Purging removed packages with "apt-get purge <pkgname>" or "aptitude purge <pkgname>" should eliminate them.

I agree that the package manager could support such files better. Perhaps there could be a separate directory for configuration files belonging to removed packages pending reinstallation or purge, where they wouldn't interfere with the rest of the system.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 21:05 UTC (Mon) by bazsi (guest, #63084) [Link] (9 responses)

I know. But when you do a dist-upgrade, sometimes packages get obsoleted, and not upgraded. And apt-get dist-upgrade doesn't purge, and cannot be told to purge.

And that's when the battle starts to find out why a function doesn't work.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 21:41 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (7 responses)

dist-upgrade may not purge packages automatically, but it isn't very difficult to simply purge all the obsoleted packages via aptitude after the fact. Set the filter to show partially-removed packages ("l" key -> "?config-files"), select the installed-packages header, press "_" to purge, then "g" twice to apply the changes. Or, if you don't want to use aptitude, you can filter out the package names from "dpkg -l" where the status is "rc" and feed that list to "apt-get purge" or "dpkg -P":

$ dpkg -l | awk '/^rc /{print $2;}' > pkg-list
$ $VISUAL pkg-list # review packages to be purged
# dpkg -P `<pkg-list`

Why isn't desktop Linux "finished"?

Posted May 3, 2011 6:43 UTC (Tue) by Cato (guest, #7643) [Link] (4 responses)

That's not very difficult for a techie Linux user, but for someone who's switched from Windows to Ubuntu, it's very hard to discover what to do, and they are more likely to just run into problems.

Obsolete config files are an issue, but only 1 of the 4 problems I encountered was due to an old config file - the rest are just new features not working properly.

Hence I'm more interested in discussion of why Upstart and KMS are not finished and working well over 18+ months after Ubuntu adopted them and 12 months after use in an LTS release.

Why isn't desktop Linux "finished"?

Posted May 11, 2011 19:06 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

KMS isn't finished because graphics cards are insanely complicated devices these days (by far the most complex device in the system, possibly even including the CPU), are damn close to general-purpose computers in their own right, are in many ways much *more* powerful than the CPU, change very frequently, are often very under-documented, and are variable in their capabilities. In addition massive changes on the userspace side are required just to allow userspace code to get at some of the cards' capabilities (e.g. just supporting OpenGL 2.1 meant implementing a whole compiler, for shaders).

KMS won't be finished for ages. The job is just too huge.

Why isn't desktop Linux "finished"?

Posted May 12, 2011 6:04 UTC (Thu) by Cato (guest, #7643) [Link] (2 responses)

I can see your point - however, from a user point of view, desktop Linux is now much less stable for many graphics cards than it was a few years ago. I'm not that the minor benefits of KMS are worth the apparent years of instability.

Apart from the technical elegance, why did the Linux community decide to make the kernel and even typical recovery boot processes dependent on the GPU, which as you say is very complex, fast changing and under-documented?

I have still not managed to get recovery boot working on Lucid, all thanks to some combination of KMS and framebuffer devices - I've tried many boot strings and made some progress, but I gave up after many hours. On this Intel GMA3100 hardware, which should be well supported, KMS has made things much worse than the previous Ubuntu LTS.

Why isn't desktop Linux "finished"?

Posted May 12, 2011 10:48 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

desktop Linux is now much less stable for many graphics cards than it was a few years ago
Is it? I thought that before I tried KMS, and, y'know, I haven't had a single problem on the three Radeon cards and two Intel that I've tried. (I haven't tried nvidia because I actively avoid them and all their works.)

There was no choice about making the kernel boot process 'dependent on the GPU', if by that you mean using KMS to display the boot process, because the time is coming (and it is not terribly far away) when text-mode support will disappear from these cards. So it's graphics or nothing, and the only non-conflicting way for the kernel and X to display stuff on the screen is KMS, at least if you want to retain any acceleration at all in X.

I'm not that the minor benefits of KMS are worth the apparent years of instability.
The 'minor' benefits include support for any version of OpenGL above 1.5, which is ancient; the possibility to see kernel panics even when X is running (I don't know if this works yet but at least it is possible); much more reliable suspend/resume; and the ability to actually use most of the card's capabilities (it's not a framebuffer anymore, it's a massively parallel computer with an address space partially disjoint from the CPU's, and there is no hope of userspace modesetting modelling any of that).

There was a choice: go KMS, or have almost no improvements in X graphics for the foreseeable future. (Actually it would probably go backwards because the userspace modesetting drivers are not pleasant to maintain.)

Why isn't desktop Linux "finished"?

Posted May 18, 2011 13:26 UTC (Wed) by Cato (guest, #7643) [Link]

I can see the reasons for going with KMS and it sounds like it works for you - however I'm now having to make another trip to upgrade from 10.04 LTS, to solve the "freezes every day or two" problem, which I'm guessing is KMS related though it's hard to tell.

The 10.04 LTS upgrade has been a disaster, the person using has said she wants to stop using Ubuntu as a result. Hopefully going to a more recent Ubuntu (maybe 10.10) will fix the Intel KMS problems.

Can anyone recommend a good Ubuntu or similar distro version (Mint, Mepis, Debian, with reasonably quick security updates) that has KMS working well on Intel GMA3100 or similar, without random freezes? I don't want to try getting a newer Xorg and kernel working on 10.04, as the idea of this PC is to be low maintenance and reliable for the next 2-3 years.

Why isn't desktop Linux "finished"?

Posted May 3, 2011 15:07 UTC (Tue) by jzbiciak (guest, #5246) [Link] (1 responses)

While that may work, you'll forgive me if I note that it isn't particularly obvious or user friendly...

Why isn't desktop Linux "finished"?

Posted May 5, 2011 16:32 UTC (Thu) by Thalience (subscriber, #4217) [Link]

The Synaptic front-end provides a way to do it that is, if not obvious, then at least discoverable.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 22:16 UTC (Mon) by Tobu (subscriber, #24111) [Link]

aptitude purge \~c purges leftover conffiles and data (don't do it for a database though), and install/remove/upgrade commands take a --purge-unused flag that purges while uninstalling.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 16:12 UTC (Mon) by Cato (guest, #7643) [Link]

I agree about upgrading to some degree, that certainly covers the xmodmap issue - however the CUPS failure to start and the KMS failure on recovery mode don't seem to be upgrade config related, and are really down to new features not working properly.

Poettering: Why systemd?

Posted Apr 30, 2011 20:22 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Sure. That's why Unixen totally lost the battle on desktops (the Year of Linux Desktop, yeah). The battle on servers is at best a draw with Windows (ActiveDirectory - an unholy spawn of anti-Unix philosophy totally rules the corporate space).

The only popular Unix flavors: iOS/OSX and Android do not give a **** about the Unix philosophy. So yeah, I'll take sound and elegant solutions versus nebulous 'Unix philosophy' any time of day.

Besides, the exact same debate was previously held on: D-BUS, hal, udev and package management systems (what?!? how can we surrender our ability to move files around to the package manager!?!?!?! ah, these were the days).

You might also consider that YOU are in the minority which tries to retard the progress.

Poettering: Why systemd?

Posted May 1, 2011 4:24 UTC (Sun) by clint (subscriber, #7076) [Link] (1 responses)

> The only popular Unix flavors: iOS/OSX and Android do not give a **** about the Unix philosophy.

And if I care about having control over a working system, I won't run broken crap like that.
It's too bad no one wants GNU on mobile devices.

Poettering: Why systemd?

Posted May 1, 2011 5:38 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

You can have GNU/BusyBox userland on Android devices (I certainly have). But what for? It's useless during normal phone use. I mostly use it over adb shell during debugging and hacking.

And Android runtime by itself is quite configurable and flexible.

Poettering: Why systemd?

Posted May 1, 2011 1:02 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> A lot of problems have already been solved, 10, 20, 30, and 40 years ago.
Solved problems aren't interesting. But there are tons of problems that sysvinit didn't solve and systemd does.

> UNIX philosophy is not wrong just because it's old
No, it's wrong because computers, their environment and their users nowadays bear no resemblance to what they were like when Unix was invented.
Besides, most people who bullshit about the so-called "Unix philosophy" only have *very* vague ideas about what it is.

> A happy compromise is to extend what's there and re-invent only when really, truly necessary.
People did just fine before computers even existed, therefore nothing in computing is strictly necessary. The question is what is sensible and worthwhile. Having an init daemon that is able to kill all processes belonging to a service sounds sensible to me. So does getting rid of unix shell scripting whereever possible

Poettering: Why systemd?

Posted May 8, 2011 6:34 UTC (Sun) by rlarkin (guest, #74787) [Link] (1 responses)

From all these talks I figured out that the Unix philosophy is: 1) Everything was already invented and perfect 40 years ago. 2) Everything else must be implemented using shell scripts and pipes.

Correct?

Almost correct. Almost everything was invented 40 years ago, reaching perfection until about 10 years ago. About 5 years ago Red Hat went on a hiring spree, hiring inexperienced kids from all over the place, and *their* choices are making things worse. And it's not that everything else must be implemented using shell scripts and pipes, it's that for most things shell scripts and pipes are the best choice. Not understanding why this is true doesn't make it less true.

I want my OS and the applications in it to bend to MY use case (meaning the people I support get exactly what they want). Neither you or Lennart Poettering or anyone else knows precisely what that use case is. I have the intelligence and imagination to do that provided I'm working with a sensible Linux distribution. Consider that #3 in your list.

There are people in the world who lack intelligence and imagination and would prefer that *all of us* be forced to choose from the same short list of checkboxes because that levels the field for them. And there are people with the hubris to think that they know what those choices should be. Typically this will be someone with no real OPS experience or experience in one or two environments at most.

Old joke: Manager goes to a Windows admin with a problem, the admin looks in the knowledge base (some screen shots), gives the manager 4 options. Next the manager presents the same problem to his Linux admin who responds "Well, how do you want it to work?" The Unix Philosophy (and shells and pipes) that you denigrate is what makes that possible. Systemd will make this more difficult.

Poettering: Why systemd?

Posted May 8, 2011 9:29 UTC (Sun) by anselm (subscriber, #2796) [Link]

The Unix Philosophy (and shells and pipes) that you denigrate is what makes that possible. Systemd will make this more difficult.

System V init may have been conceptually simple at some point, but in 2011 it is basically a complicated artefact held together by Band-Aid and string. Many Linux distributions have seen the need to pile stuff on top of it (insserv, chkconfig, update-rc.d, …) in order to make it address their requirements. It may be a good thing that they can customise it, but one might be forgiven for thinking that if it apparently needs to be customised through non-standard, distribution-specific tools to be usable, there may be problems in the underlying concept.

Systemd is still quite new and any predictions of what it will or will not be able do once it is »done« are very probably premature. It does promise a way of organising system startup (which System V init does, too) and system operation (which System V init doesn't) in a unified fashion without actually excluding shell scripts and pipes, so it should at least be given the benefit of doubt until it has proved itself.

The funny thing is, when System V init was new, many proponents of the »traditional« method (one large shell script initialised everything) dissed it for being an overengineered, unnecessary mess, and now suddenly it is the embodiment of the »Unix philosophy«?

Poettering: Why systemd?

Posted Apr 29, 2011 19:26 UTC (Fri) by intgr (subscriber, #39733) [Link]

The comparison is ridiculous, yes, but...

> I have tested systemd for a few days and discovered that the (small) gain is not
> worth the pain. You end up constantly fighting against its design decisions.

Making those statements, with no explanation or examples of the pain and (bad?) design decisions is unlikely to convince many people. What does minit do better?

As someone who has written init scripts for RHEL SysV, Debian SysV (start-stop-daemon), Gentoo OpenRC, Ubuntu Upstart and Arch Linux SysV, I have to say that systemd is the best documented AND behaves the most predictably. I haven't tried minit, but I find those qualities much more important than minimalism.

Poettering: Why systemd?

Posted Apr 29, 2011 20:14 UTC (Fri) by mezcalero (subscriber, #45103) [Link] (25 responses)

It could actually be believable if you wouldn't just spread FUDdy insinuations but hard facts, and examples!

Poettering: Why systemd?

Posted Apr 29, 2011 20:51 UTC (Fri) by handock (guest, #73633) [Link] (24 responses)

OK here you go (just a few examples):

Everything is dumped into dmesg by default. Why?
dmesg is for important system events and not for redundant application
messages.

The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.

Just looking at the huge list when you run "mount" gives me the craps.
I would have to hand disable most of the default mount points.
(Just because there's a fancy new kernel feature doesn't mean you have to enable it by default)

There was no sane way to start fcron reliable on my system.
(I've tried everything possible, but it would just start and then hang and not execute any cron jobs)

Poettering: Why systemd?

Posted Apr 29, 2011 21:46 UTC (Fri) by intgr (subscriber, #39733) [Link] (2 responses)

> Everything is dumped into dmesg by default. Why?

It's only dumped into dmesg until your syslog daemon starts and takes over /dev/log. Because early-boot messages ARE important system events. Without this feature, you would lose all messages before the syslog daemon starts.

> The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.

Correct me if I'm wrong, but I think kexec is invoked after all file systems other than root have been unmounted. Since /usr can potentially be a separate file system, kexec should not be there.

> There was no sane way to start fcron reliable on my system.

systemd launches daemons from a cleaner environment than a typical SysV script (doesn't leak user's environment to the daemon). Some daemons are known to crash when HOME is unset. You could try adding Environment=HOME=/var/empty

Poettering: Why systemd?

Posted Apr 30, 2011 5:24 UTC (Sat) by Duncan (guest, #6647) [Link] (1 responses)

>> The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.

> Correct me if I'm wrong, but I think kexec is invoked after all file systems other than root have been unmounted. Since /usr can potentially be a separate file system, kexec should not be there.

[Not a systemd user and likely won't be for awhile, as I'm quite happy on Gentoo and openrc. But I like to stay informed, and if systemd becomes a standard as intended, who knows what might happen 2-7 years down the line?]

I believe the point is the /hardcoded/ bit. Just because /usr /can/ potentially be on a separate fs doesn't mean it /is/, and hardcoding /any/ locations, other than perhaps the location of an initial config file due to the chicken/egg problem of needing the config to find it, is something I'd consider a misfeature.

Now if that's mistaken and the location is only the necessarily and reasonably hardcoded default, with a documented config option to place it elsewhere...

Meanwhile, one thing I've not seen in any of the reviews, etc, yet, possibly because I've frankly not been interested enough to go read the main articles referred to in coverage like this, is how well systemd might operate as a secondary initsys, responsible for a few daemons that ship with decent systemd init configs by default, but not for initialization of the entire system. Does it have a mode that allows that, without the admin having to worry about it unpredictably trying to takeover something it wasn't configured to handle on that system and without being more trouble than it's worth to setup?

Because if it handles that well, I could see it gradually taking over over on a system or distribution, one daemon at a time over a period of years, until there's little reason not to simply dump the previous system and let systemd handle it all. But if it can't handle something like that and switching to it has to be a flag-day event... it's certainly much less likely to get any reasonable consideration here for quite some time.

Poettering: Why systemd?

Posted May 2, 2011 21:03 UTC (Mon) by vonbrand (guest, #4458) [Link]

Meanwhile, one thing I've not seen in any of the reviews, etc, yet, possibly because I've frankly not been interested enough to go read the main articles referred to in coverage like this, is how well systemd might operate as a secondary initsys, responsible for a few daemons that ship with decent systemd init configs by default, but not for initialization of the entire system. Does it have a mode that allows that, without the admin having to worry about it unpredictably trying to takeover something it wasn't configured to handle on that system and without being more trouble than it's worth to setup?

As it stands here today (Fedora to become 15 on x86_64), systemd will fall back on sysvinit's scripts if there isn't native configuration (there are still a few of those left; reengineering a sane init script into a systemd unit is an half hour of work, tops), and running sysvinit's scripts will in turn fall forward to run systemd's daemon control when required. There are some services that still use the old ways, and that works fine. Some fingers are still used to run the scripts for daemon control, also works fine. There is no "flag day" involved.

Poettering: Why systemd?

Posted Apr 30, 2011 1:17 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (14 responses)

> Everything is dumped into dmesg by default. Why?

Do you find it better if they go to /dev/null like they used to go?

Note that those messages go to kmsg only as long as no full rsyslog is up, i.e. we provide logging already during the first moments of early boot. Which is a fantastic feature, which has not been available anywhere before. Since rsyslog as first thing after boot dumps kmsg to disk you end up with a complete set of log files from the earliest moment of bootup. Starting with F16 you will be able to use "dmesk -k" btw to limit the output to kernel generated messages, to get a more traditional dmesg output. You can even make "dmesg" an alias for this, in case you say that early boot msgs are evil shit and you never want to know details about stuff that went wrong during early boot.

> The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.

Then your OS is broken. /usr/bin is not available during late shutdown, hence placing kexec there is just wrong.

> Just looking at the huge list when you run "mount" gives me the craps.

Mount points are just mount points. If you really have an issue with kernel file systems, then ffs complain to the kernel folks, not us. We just make them available to userspace.

> There was no sane way to start fcron reliable on my system.

Uh? It's a service like any other. Just place a tiny .service file or sysv script for it in the right dir, and it will just work. If it doesn't file a bug. If it just hangs, file a bug against fcron.

Really, try harder.

Poettering: Why systemd?

Posted Apr 30, 2011 6:15 UTC (Sat) by handock (guest, #73633) [Link] (6 responses)

> Do you find it better if they go to /dev/null like they used to go?

They didn't.

>> The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.

>Then your OS is broken. /usr/bin is not available during late shutdown, hence placing kexec there is just wrong.

No. It just highlights the problem with systemd. In any other init system
I could just edit a small shell script and change the path. In systemd
I have to edit a C file and recompile and link. (And BTW calling external
programs from C is not the same as your advertisement suggestion:
"Built-in kexec support". And this goes for a lot of items on your list)

The other possibility (and apparently your favorite) is to force every Linux
user to place kexec in /sbin, similar to your brilliant idea to move /var/run to /run
just because you cannot handle a simple /var mount-point in systemd.

> Mount points are just mount points. If you really have an issue with kernel file systems, then ffs complain to the kernel folks, not us. We just make them available to userspace.

No. Nobody forces you to mount every available kernel fs by default.

> Uh? It's a service like any other. Just place a tiny .service file or sysv script for it in the right dir, and it will just work. If it doesn't file a bug. If it just hangs, file a bug against fcron.

Just guess what I did? I've tried many different tiny .service files and they
all didn't work. And fcron doesn't have a problem with any other init system.

Hmm... This is pretty typical :-)

Posted Apr 30, 2011 10:42 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

It just highlights the problem with systemd.

Problem? It's a feature!

In any other init system I could just edit a small shell script and change the path.

Right - and this is the problem.

The other possibility (and apparently your favorite) is to force every Linux user to place kexec in /sbin, similar to your brilliant idea to move /var/run to /run just because you cannot handle a simple /var mount-point in systemd.

Yup. But think about it: why systemd refuses to support /var/run? Is it really impossible to do? No - it's not that hard. But it does not give you any advantages and creates few problems (as was discussed before).

No. Nobody forces you to mount every available kernel fs by default.

SystemD does. This means developers of third-party software can finally stop thinking about cases where someone decided to not mount something.

Balance between configurability (which allows you to solve real problems) and uniformity (which allows you to not lose much time stydying pointless differences) is important - and right now Linux is skewed heavility to the "too much configurability" side. Systemd is trying to fix that balance, but as usual people are affected differently: sysadmins usually favor configurability (since it makes it possible to patch problems when needed), IVSs favor uniformity (since it makes development and testing easier). So far I see curses from sysadmins and praises from developers so it's obvious that systemd does things right: Linux has more then enough sysadmins and way to few ISVs today.

Hmm... This is pretty typical :-)

Posted Apr 30, 2011 19:47 UTC (Sat) by drag (guest, #31333) [Link]

Agreed.

Personally I'd rather have something that reliably works only one way versus something that doesn't work in a bunch of different ways. The problem with a lot of this 'Linux scripting/mentality mentality - oh I can fix it' is that you end up with a shitload of choices that are broken in different manners.

You have to choose which parts of your system you would like broken in order to find a combination of non-broken functionality that will specifically suite your purposes.

It's like:

Welcome to Linux! The UBER OS.
Please make choice 1, You can Choose:
A) I want a system that boots fast
B) Oh I can choose a system that will detect my hardware properly

Congrats, you chose A. Lets hope you don't buy a new USB drive and expect to use it without su'ng to root!

Choice 2:
A) I can choose a system that won't puke and cause my system to hang in case I boot it up with no network
OR
B) Tie my system into LDAP for user synchronization.

Congrats! You choose B. I see that your probably not using a laptop, good thing too because now all your power management stuff is broken since you chose A in the first question! Yay!

Poettering: Why systemd?

Posted Apr 30, 2011 13:22 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (2 responses)

> They didn't.

Ah, right. So your distro is spawning a /dev/log syslog as one of the first things at boot? Can you point me to which one that is?

> No. It just highlights the problem with systemd. In any other init system
> I could just edit a small shell script and change the path. In systemd
> I have to edit a C file and recompile and link.

Yeah, thing is we don't really support broken setups with systemd. Sorry for that. Also, we already made clear that we want to standardize behaviour of Linux, and that includes that we ensure that people fix their broken OSes and for example move kexec to away from a broken path to the right path.

> (And BTW calling external
> programs from C is not the same as your advertisement suggestion:
> "Built-in kexec support". And this goes for a lot of items on your list)

That refers to the fact that we have "systemctl kexec" and thelike.

> The other possibility (and apparently your favorite) is to force every Linux
> user to place kexec in /sbin, similar to your brilliant idea to move /var/run to /run
> just because you cannot handle a simple /var mount-point in systemd.

Hmm, I am not forcing anybody. You can adopt systemd if you wish. I make an offer with systemd, you don't have to take it, it's free software. Note however, that *all* big distros have commited to the /var/run to /run move, including Ubuntu, regardless if they want to do systemd or not. So, complain to them, too, not just to me. Ever thought that maybe if everybody loves /run this might be the right thing and you are just misinformed?

> No. Nobody forces you to mount every available kernel fs by default.

No, but they aren't any useful if they aren't mounted. Note btw, that we actually don't mount them all, to optimize things. We just place automount points in /proc/sys/fs/binfmt_misc and similar places, which are backed by the real fs only on demand, causing the loading of the backing kmod only when needed.

Poettering: Why systemd?

Posted Apr 30, 2011 13:24 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (1 responses)

> > The other possibility (and apparently your favorite) is to force every Linux
> > user to place kexec in /sbin, similar to your brilliant idea to move /var/run to /run
> > just because you cannot handle a simple /var mount-point in systemd.

> Hmm, I am not forcing anybody. You can adopt systemd if you wish. I make an offer with systemd, you don't have to take it, it's free software. Note however, that *all* big distros have commited to the /var/run to /run move, including Ubuntu, regardless if they want to do systemd or not. So, complain to them, too, not just to me. Ever thought that maybe if everybody loves /run this might be the right thing and you are just misinformed?

Oh, and BTW. If your really hate those mount points so much, you can remove them. Just mask their units by linking them to /dev/null in /etc/systemd/system/.

We just ship good defaults, that's all.

Poettering: Why systemd?

Posted May 11, 2011 18:36 UTC (Wed) by nix (subscriber, #2304) [Link]

Shipping good defaults is also profoundly un-Unixlike. How will people learn how to maintain their systems if they don't have to personally grind every hinge into shape?

;}

Poettering: Why systemd?

Posted Apr 30, 2011 13:56 UTC (Sat) by intgr (subscriber, #39733) [Link]

>> The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.
> No. It just highlights the problem with systemd. In any other init system
I could just edit a small shell script and change the path.

And with systemd you can make a symlink from /sbin/kexec to /usr/sbin/kexec, if you really insist.

Editing shell scripts never was the *right* solution to most problems -- when the upstream script changes and overwrites your changes, you're back in square one again. Generally by the time this happens, you've long ago forgotten about your duct tape solution, so you have to solve it again.

Poettering: Why systemd?

Posted Apr 30, 2011 12:36 UTC (Sat) by mp (subscriber, #5615) [Link] (3 responses)

> > The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.

> Then your OS is broken. /usr/bin is not available during late shutdown, hence placing kexec there is just wrong.

But is it really? Separate /usr/ is broken anyway.

Poettering: Why systemd?

Posted Apr 30, 2011 23:29 UTC (Sat) by HenrikH (subscriber, #31152) [Link] (2 responses)

And people placing stuff like kexec into /usr might be the cause of that problem, don't you think ;)

Poettering: Why systemd?

Posted May 1, 2011 10:52 UTC (Sun) by mp (subscriber, #5615) [Link] (1 responses)

Well, yes, they might. It just seemed that Lennart thought the game to be over already, so nothing really broken in making it slightly more true.

Poettering: Why systemd?

Posted May 2, 2011 21:20 UTC (Mon) by HenrikH (subscriber, #31152) [Link]

I see the opposite, as in Lennart trying to actually make a separate /usr be possible. As long as stuff like kexec is in /usr this cannot happen, so systemd is not the one breaking the separation to be honest.

Poettering: Why systemd?

Posted May 2, 2011 7:24 UTC (Mon) by ebiederm (subscriber, #35028) [Link] (2 responses)

> > The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.

> Then your OS is broken. /usr/bin is not available during late shutdown, hence placing kexec there is just wrong.

Wow. If this is true than systemd has a bug here. The only reason kexec -e is called the distribution shutdown scripts is because the patch to /sbin/reboot never made it into sysvinit. All kexec -e really does is a single system call.

Systemd has incorrect hard coded paths to avoid a single system call???

Wow.

Poettering: Why systemd?

Posted May 2, 2011 9:42 UTC (Mon) by michich (subscriber, #17902) [Link]

"kexec -e" does more than a single syscall. It also downs all network interfaces, shaper devices first.

Poettering: Why systemd?

Posted May 2, 2011 15:55 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

Is it really just a single system call? afaics it does all kinds of stuff like uploading a kernel. Not sure I want to get into the business of doing that.

Poettering: Why systemd?

Posted May 2, 2011 9:01 UTC (Mon) by johannbg (guest, #65743) [Link] (5 responses)

>There was no sane way to start fcron reliable on my system.
(I've tried everything possible, but it would just start and then hang and not execute any cron jobs)

The old sysv init and native systemd service files ( which I just converted just to test this ) start and stop cleanly on F15 host running systemd which indicates that the problem resides elsewhere either specific to your system and or what's being shipped with your distro of choosing.

Here are the native systemd service files for fcron which should work on any distro using systemd ( note that relevant paths might need to be adjusted and or any distro specific startup option for the daemon )

To test this..

# vim /lib/systemd/system/fcron.service

[Unit]
Description=Fcron an periodical command scheduler.
After=syslog.target

[Service]
Type=forking
PIDFile=/var/run/fcron.pid
ExecStart=/usr/sbin/fcron -b
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

# vim /lib/systemd/system/fcron_watch_config.service
[Unit]
Description=Vixie cron configuration files script checker for fcron.
After=syslog.target

[Service]
Type=forking
PIDFile=/var/run/fcron_watch_config.pid
ExecStart=/usr/sbin/daemon_fcron_watch_config

[Install]
WantedBy=multi-user.target

Then run systemd daemon-reload to let systemd pick up the native systemd service files.

And to start stop restart and see the status of the service

systemctl start/restart/stop/status fcron.service or fcron_watch_config.service

To enable/disable the service at boot up run

systemctl enable/disable fcron.service or fcron_watch_config.service

I'll leave it up as an exercise for the readers to take a look at the relevant fcron sysv scripts that get shipped with their distro and compare it to these native systemd service files which I provided here to reach an informal decision of which one is more complicated and or harder to understand.

Poettering: Why systemd?

Posted May 2, 2011 9:46 UTC (Mon) by nicooo (guest, #69134) [Link] (4 responses)

If something requires cron (but fcron isn't set to start by default), how would systemd know that it should start fcron?

Poettering: Why systemd?

Posted May 2, 2011 12:46 UTC (Mon) by johannbg (guest, #65743) [Link] (3 responses)

Depending on the behaviour you want you add to the [Unit] section of the service file.

Requires=$foo.target $bar.service

or

Wants= $foo.target $bar.service

or

BindTo= $foo.target $bar.service

see systemd.unit man page for details.

Poettering: Why systemd?

Posted May 2, 2011 22:49 UTC (Mon) by nicooo (guest, #69134) [Link] (2 responses)

So in the file:
service-that-needs-to-run-daily.service

I would have:
[Unit]
Wants=multi-user.target cron.service

If one user has cronie, another dcron and another fcron, how would this work?

Poettering: Why systemd?

Posted May 3, 2011 1:32 UTC (Tue) by phess (subscriber, #74656) [Link] (1 responses)

"Wants=multi-user.target cron.service"

"If one user has cronie, another dcron and another fcron, how would this work?"

Then I guess you should use cron as a target:

mkdir /etc/systemd/system/cron.target

Then add "Wants=cron.target" to your cron daemon's unit file.

After that, your other unit files should only mention cron.target instead of any of {cronie,fcron,vixie-cron}.service.

Poettering: Why systemd?

Posted May 4, 2011 1:40 UTC (Wed) by phess (subscriber, #74656) [Link]

Ooops, sorry for this mistake.
Where my previous comment says:

'Wants=cron.target'
please read
'WantedBy=cron.target'

Poettering: Why systemd?

Posted Apr 29, 2011 20:20 UTC (Fri) by mezcalero (subscriber, #45103) [Link] (6 responses)

Oh, and systemd brings back much of the UNIX philosophy that was long lost. For example, we put an emphasis on socket activation, which was kinda supported by inetd decades back but has since been stripped from most distribution's default install. Socket activation at its core is very much Unix heritage. And we bring it back. If you love Unix, then we have this as present for you.

Also, systemd is modular, you have individual components dealing with different things. That's so Unix, that it can't get any more Unixish.

Of course, if you think Unix philosophy means balkanization, complexity, smorgasbord, and being antiquated, then true, systemd is not Unixish at all.

Poettering: Why systemd?

Posted Apr 29, 2011 21:10 UTC (Fri) by viro (subscriber, #7872) [Link] (5 responses)

Screw that... RTFS(kernel/cgroup.c) and don't forget a _big_ barf-bag; you'll need it. Just having something merged into the tree does _not_ mean that it's not a festering pile of skunk excrements. After all, devfs had been there for a while. So's fanotify. Relying on it is a bad idea. Is that clear enough for you or would you need it spelled out in more details?

Poettering: Why systemd?

Posted Apr 29, 2011 21:15 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

Relying on things that turn out to be steaming crocks sounds pretty Unixy too.

Poettering: Why systemd?

Posted Apr 30, 2011 1:20 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (3 responses)

Hey, if it's really that bad (and I have no doubt it is), then it might be a good thing to fix, not one two continue whining about for years in the past and years to come.

Poettering: Why systemd?

Posted Apr 30, 2011 1:44 UTC (Sat) by viro (subscriber, #7872) [Link] (2 responses)

For values of fix including "rip the FPOS out"? Worked for devfs, eventually... Thanks for the "whining" bit, BTW - nothing like cheap potshots from an arrogant luser. You want it fixed? Be my guest, l-k is -> that way, patches (especially cleaning such a pile of crap up) are always welcome... _You_ want to use the damn thing; I'm perfectly fine configuring it out for all my boxen. IOW, you need to fix that abortion more than I do. Any additional questions?

We'll see :-)

Posted Apr 30, 2011 10:15 UTC (Sat) by khim (subscriber, #9252) [Link]

For values of fix including "rip the FPOS out"? Worked for devfs, eventually...

Well, it worked for devfs because few major distributions relied on it (as I can recall the only distribution which required the use of devfs was Gentoo... and it was not all that major). If systemd will be adopted widely enough cgroups will be kept around in one form or another. In the worst case it'll be just a fork which real distributions use and another one which is mainstream and which noone uses.

_You_ want to use the damn thing; I'm perfectly fine configuring it out for all my boxen. IOW, you need to fix that abortion more than I do. Any additional questions?

Yup. Why do you think users need a fix? As far as they are concerned the thing works. If (and when) you decide to rip "that abortion" out they will have a problem - or you will do. It depends on number of users, really. Upstream linux kernel is pretty much irrelevant for most users already (because there are more Android and embedded users then desktop users - and these kernels often diverge from upstream quite severely), I fail to see why sky will fall on earth if server and desktop will go this way too.

Poettering: Why systemd?

Posted Apr 30, 2011 13:08 UTC (Sat) by adobriyan (guest, #30858) [Link]

> Any additional questions?

What wrong with it?

Poettering: Why systemd?

Posted Apr 30, 2011 6:58 UTC (Sat) by jcm (subscriber, #18262) [Link] (9 responses)

I'm firmly in the "goes against UNIX design" camp also. I'm glad some people find that systemd buys them increased performance, and I'm sure it has some wins, but I didn't ask for my init daemon to be replaced for a third time. This constant wheel re-invention in the Linux space does ultimately have to stop if we're going to settle down and offer a consistent platform third parties can program against. Not to pick on systemd too much, but I cannot recall thinking to myself, "gee, if only my init system weren't so crap". Actually, sysvinit worked just fine, thank you. Sure, my laptop took slightly longer to boot...the *one* time a week I boot it. People who go off on wild tangents about fast booting and other features (outside certain spaces, such as embedded devices) are mostly just those who enjoy watching their system reboot for use in statistics.

Poettering: Why systemd?

Posted Apr 30, 2011 8:47 UTC (Sat) by james (guest, #1325) [Link] (1 responses)

I'm not sure your comment paints Unix in a good light.

Since the early eighties, there has been very little wheel-reinvention in Unix text-mode utilities: since CDE stopped being actively developed, there has been very little wheel-reinvention in Unix graphics.

As a result, commercial Unix has offered consistent platforms for at least fifteen years.

But you wouldn't want to actually use commercial Unix on the desktop, would you? Not without all the GNU and Gnome/KDE re-invented wheels.

Poettering: Why systemd?

Posted Apr 30, 2011 20:07 UTC (Sat) by drag (guest, #31333) [Link]

>As a result, commercial Unix has offered consistent platforms for at least fifteen years.

And as a result nobody in their right mind would want to use a Unix GUI for anything.

Linux is the closest you can get to a decent GUI for a Unix system using traditional protocols. And the only reason it's as good as it is because of massive changes in how it works and a large number of extensions. Virtually nobody programs their applications in the same manner as they did 15 years ago.

Meanwhile the most popular Unix-for-GUI users is obviously OS X and they succeeded where Unix failed by completely abandoning X Windows right off the bat. For Unix geeks they can still get X Windows via xdarwin.

TDLR:

The vast majority of people would rather pay their application developers to rewrite their applications from scratch rather then be forced to use X Windows on a real Unix system.

Hmm...

Posted Apr 30, 2011 9:34 UTC (Sat) by khim (subscriber, #9252) [Link]

I want to disappoint you: you'll never beat the record this way. Try harder.

Here is first sentence:

This constant wheel re-invention in the Linux space does ultimately have to stop if we're going to settle down and offer a consistent platform third parties can program against.

Here is another:

Not to pick on systemd too much, but I cannot recall thinking to myself, "gee, if only my init system weren't so crap". Actually, sysvinit worked just fine, thank you

You managed to put contradictions on adjacent sentences, but real pros can do it in adjacent words!

Jokes aside: one serious inconsistency between different distributions was always the init system. Even when both distributions used similar piles of scripts to manage daemons they never were identical. It was usually impossible to create a single script to use on Debian and RedHat. You can not simultaneously ask to "offer a consistent platform third parties can program against" and say "sysvinit worked just fine". Because it didn't.

I care less about advanced SystemD features, but I really like how it makes it very hard to paper over many problems. The fact that you can not easily ask SystemD to use /var/run is good one: this means ISV can rely on the fact that /run will always be there. My only fear is that people will push Lennart hard to add all these pointless "configurability" features, eventually they'll added and history will repeat itself.

P.S. It's funny how often people complain that "inconsistent platform is killing linux" but then turn around and complain that "I can not reintroduce this particular inconsistency I like". Pick one way or anyther! If you want consistent platform - then SystemD hardcoded paths and automounted filesystems should be fine. If you want to tweak your system as much as you want - then you can just ignore SystemD and live without ISVs attention.

Poettering: Why systemd?

Posted Apr 30, 2011 13:43 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (5 responses)

Hmm, if things are too fast for you, and you are more the conservative type, who's against progress, and rather wants things slow, then maybe the fast paced computer industry is not the right place for you to work in?

There are very few professions where the tools for working have not changed in the last 30 years, by the introduction of the computer (you seem to be appalled by any improvements on top of UNIX, so basically want to stick with 30y old technology). But I think you might be able to find a job opening as sheep herder in Scotland or so, which still works basically the same as 200 years ago. There, things won't be so damn fast as in the computer industry. And if you are lucky then cell phone reception won't be available in the Scottish highlands, and you don't have to see how everything progresses and you don't.

Poettering: Why systemd?

Posted May 1, 2011 23:24 UTC (Sun) by dgm (subscriber, #49227) [Link] (4 responses)

What's the problem with you, Lennart?

What's wrong with pointing that 1) systemd is just another init system, and an incompatible (as in needing to rewrite stuff) one, and 2) Many people don't need or want it?

Are you going to send everyone that disagrees with you to skin sheep to Scotland?

Poettering: Why systemd?

Posted May 2, 2011 0:41 UTC (Mon) by HelloWorld (guest, #56129) [Link] (3 responses)

systemd supports SysV-style init scripts, so why are you saying that stuff needs to be rewritten? Or are you referring to the fcron case? In that case it remains to be seen whether this is actually a problem in systemd or fcron.

Poettering: Why systemd?

Posted May 2, 2011 15:34 UTC (Mon) by dgm (subscriber, #49227) [Link] (2 responses)

No, I mean that to gain something from (and thus justify) changing to systemd you need to rewrite the server's code. Otherwise, what's the point? The optimum thing would have been some automatic mechanism. I don't know if that would have been possible. Maybe I'm too demanding?.

In fairness, I sounds like what we will gain will offset the effort, but for the moment I'm skeptical. Specially after reading how Pottering disregards portability. Systemd is Linux-only by design.

Poettering: Why systemd?

Posted May 2, 2011 20:00 UTC (Mon) by HelloWorld (guest, #56129) [Link] (1 responses)

No, I mean that to gain something from (and thus justify) changing to systemd you need to rewrite the server's code. Otherwise, what's the point? The optimum thing would have been some automatic mechanism. I don't know if that would have been possible. Maybe I'm too demanding?

While this may be a weakness, it is not an incompatibility: stuff that used to work still works the way it used to, so it's not incompatible.

Also, it's not entirely true. Daemons supporting inetd don't need to be patched. See Poetterings systemd talk, around minute 13. A bit later on he also mentions that it would have been possible to avoid the need for patching the daemons by adding features to the kernel to support this feature, but it would have been to hard/messy, so they decided that modifying the individual daemons is easier.

Poettering: Why systemd?

Posted May 5, 2011 16:12 UTC (Thu) by Quazatron (guest, #4368) [Link]

Nice presentation, thank you for the link.

Poettering: Why systemd?

Posted Apr 30, 2011 12:48 UTC (Sat) by neilbrown (subscriber, #359) [Link]

I love that term "Unix philosophy". To borrow a phrase from Douglas Adams, it sounds good without actually tying you down to meaning anything - and I should know, I've used it to try to justify my own point of view a number of times.

Maybe the aspect of "Unix philosophy" that is embodied in init scripts and horribly violated by systemd is to take a moderately good idea and to push it beyond its competence (as I believe was done with signals).

In this case the good idea is shell scripts. The "shell" is an incredibly useful language for doing a certain class of tasks, and an incredibly horrible language from any language-theoretic stand point. Correspondingly shell scripts are incredibly useful, but definitely the wrong way to try to create large maintainable systems.

Shell scripts are particularly good for quick prototypes. The "spell" command is a good example. It was originally a small shell script (cat $1 | tr -s '\011 ' '\012' | sort | uniq | comm -13 - /usr/dict/words) which then grew into a larger shell script which then became an unmanageably large shell script, which then became a compiled C program (was 'ispell' the first, or was there an earlier one?).

Shell scripts were an obvious and correct way to prototype the start-up of services at boot time, but surely we have reached the point where we can move on from the prototype??

From a completely different perspective, as the upstream maintainer for mdadm and (previously) nfs-utils, one of the biggest frustrations is/was that every distro has different init scripts for starting these services so it is very hard to provide support or fix bugs for issues that relate to the boot sequence. In particular there are very important ordering requirements for starting the various NFS related daemons. If you get some of them wrong you will hardly ever notice - until something breaks strangely in a rare-but-possibly situation (e.g. server restarts while client holds a lock). There was no way I could ensure that every distro got this right. The best I could do was document it as carefully as possible.

With systemd this becomes possible. I don't actually know if systemd starts NFS services, and I don't know if it gets it "right". But that is not the point. The point is that it is one standard tool - with the *right* concepts (like socket-based-dependencies) - which I could add the support to if needed, and could fix the support in if it were broken and then every distro that used systemd would get the fix.

I'm convinced that /etc/rc and then /etc/rc.local and then /etc/rcNN.d/ were the right things to do. But we have learnt useful stuff at each step and it really is time to move on - to grow up you might say.

Poettering: Why systemd?

Posted Apr 29, 2011 14:18 UTC (Fri) by sztanpet (subscriber, #60731) [Link]

Everything handles everything via external things, systemd handles swap itself, sysvinit does not. Simple as that, no need to look farther than that.

Poettering: Why systemd?

Posted Apr 29, 2011 20:13 UTC (Fri) by mezcalero (subscriber, #45103) [Link] (1 responses)

sysvinit does not handle swaps. Some distribution supplied init hackery does, but not sysvinit itself.

And dude, of course this is biased, and I said so in one of the first paragraphs. It's my blog after all, not LWN or any other press product which should try to be neutral. I mean, are you really expecting me not point out the points I really believe in?

Poettering: Why systemd?

Posted Apr 30, 2011 14:15 UTC (Sat) by welinder (guest, #4699) [Link]

Well, dude yourself.

In other words, sysvinit handles swap via its plugin system,
typically (==always) in the form of shell scripts.

Don't get me wrong, I think systemd shows a lot of promise. But your
article makes it look like something for sale in a airline magazine.
You know, the extensible paint brush that makes it easy to paint your
bathroom ceiling while sipping tea in the swimming pool.

Poettering: Why systemd?

Posted Apr 30, 2011 6:55 UTC (Sat) by jcm (subscriber, #18262) [Link]

Someone pointed me to this link on today's reddit that uses the same approach to compare vim and Microsoft Word:

http://i.imgur.com/usftZ.png

Jon.

Poettering: Why systemd?

Posted Apr 29, 2011 14:10 UTC (Fri) by gmaxwell (guest, #30048) [Link] (12 responses)

Standardization.

I don't think that word means what he thinks it means.

Poettering: Why systemd?

Posted Apr 29, 2011 14:45 UTC (Fri) by AlexHudson (guest, #41828) [Link]

It got /run done.

Poettering: Why systemd?

Posted Apr 29, 2011 15:32 UTC (Fri) by Lennie (subscriber, #49641) [Link] (10 responses)

While I like a lot of the properties of systemd.

Standardization is not on my mind.

Standardization on Linux maybe, but not on *BSD, Solaris and so on.

Even if Debian would want to adopt it, how will they handle other kernels/ports ? Like Hurd and kFreeBSD.

There are different worlds...

Posted Apr 30, 2011 9:40 UTC (Sat) by khim (subscriber, #9252) [Link] (9 responses)

Well if you work in server space then "*BSD, Solaris and so on" have some meaning. But on desktop... The typical approach is: "We want to be truly cross-platform. We've got Windows and Mac covered. Now the question: should we even think about Linux or not?". People answer "yes" more and more - and this is good thing, but I'm not sure we'll ever see the time where "*BSD, Solaris and so on" will be even considered.

There are different worlds...

Posted Apr 30, 2011 9:49 UTC (Sat) by Lennie (subscriber, #49641) [Link] (8 responses)

Euh... systemd is also 'aimed' at the server- and (judging by one of the comments on this article) embedded-space.

It tries to standardize linux distributions...

Posted Apr 30, 2011 10:48 UTC (Sat) by khim (subscriber, #9252) [Link] (7 responses)

It's not aimed on server and embedded. It's useful there, sure, but it's not the goal. AFAICS the goal is to bring standardization to distributions and make life of ISVs easier. If the server and embedded with adopt systemd - that's good, too, but this is not a big deal. It'll have [nice] side-effect of reducing number of differences beween desktop, server and embedded and [not so nice] effect of further marginalization of other *nix'es, but this is not the goal.

It tries to standardize linux distributions...

Posted Apr 30, 2011 13:09 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (6 responses)

Oh, we want systemd to be integral part of all Linux platforms, from embedded, to mobile, to desktop, to server. The same way as the Linux kernel or udev is useful for the whole bandwith systemd should be too, and that's what we are working for.

Android is pretty big part of embedded world today

Posted Apr 30, 2011 15:52 UTC (Sat) by khim (subscriber, #9252) [Link] (5 responses)

Direct cite from the article:

Unless you run Android (which is a completely different beast anyway), you'll almost definitely run one of these three init systems on your Linux kernel. (OK, or busybox, but then you are basically not running any init system at all.)

Well, busybox and Android pretty much cover most of the embedded development nowadays so it's kind of hard to consider your efforts seriously WRT mobile and embedded if you just ignore them.

Of course systemd is GPLed so I think there are no hope for unification. The most we can realistically expect is few ideas (and may be config files) borrowed from systemd and planted in Android...

Android is pretty big part of embedded world today

Posted Apr 30, 2011 20:11 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Uhm. systemed works fine on Busybox-based systems, at least on my systems.

That's why I said what I said.

Posted Apr 30, 2011 20:56 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

That's why I said "it's useful there, sure, but it's not the goal". You can use systemd for embedded system with busybox and may be possible to adjust it to make it usable with Android too - but the article is pretty clear that these were non-goals when systemd was developed. If these are non-goals then you can not seriously say it was developed with embedded in mind.

The fact that Linux is usable in embedded environment is kind of accident and the same is true for systemd. Let's hope systemd will not repeat the story of linux itself (where bunch of embedded guys created bunch of incompatible forks and it took eons to clean this mess up... and it's still not entirely cleared).

That's why I said what I said.

Posted May 1, 2011 16:11 UTC (Sun) by martinfick (subscriber, #4455) [Link]

How could it have the goal of being used on android? That is just silly, Android deliberately reinvents and controls the entire userspace.

Android is pretty big part of embedded world today

Posted May 1, 2011 0:01 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

Uh, the embedded world is big. MeeGo for example is a OS for phones and other devices, and uses systemd.

Android is pretty big part of embedded world today

Posted May 4, 2011 12:52 UTC (Wed) by vonbrand (guest, #4458) [Link]

Well, busybox and Android pretty much cover most of the embedded development nowadays so it's kind of hard to consider your efforts seriously WRT mobile and embedded if you just ignore them.

And not so far back, embedded meant "software runs on the bare iron, just starts from DOS" (if there was some operating system at all involved, that is). Don't judge by what is dictated by today's limitations.

Poettering: Why systemd?

Posted Apr 29, 2011 15:41 UTC (Fri) by MisterIO (guest, #36192) [Link] (8 responses)

Unfortunately in Debian it still cannot boot directly into a graphical desktop. Till v20 the problem, at least for me, was that it didn't start dbus at all. I don't know what's the problem now(with v25 in experimental), I just tried it and, after seeing that it still doesn't work, I simply reverted back to sysvinit.
In Fedora it works well, but it dirties /etc/mtab!

Poettering: Why systemd?

Posted Apr 29, 2011 19:12 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

On a Fedora 15 system with latest util-linux

ll /etc/mtab

lrwxrwxrwx. 1 root root 12 Apr 25 11:32 /etc/mtab -> /proc/mounts

Poettering: Why systemd?

Posted Apr 30, 2011 3:01 UTC (Sat) by MisterIO (guest, #36192) [Link]

Ah, ok, so it's util-linux's fault, I guess.

Poettering: Why systemd?

Posted Apr 30, 2011 5:57 UTC (Sat) by gurulabs (guest, #10753) [Link] (2 responses)

Regarding /etc/mtab being a virtual file, it's about time that Linux caught up with Solaris 2.5. :)

The need for a txt file on Linux was because /proc/mounts didn't record all the mount options just the basic ones. Now that /proc/mounts keeps track of ALL mount options, /etc/mtab can be a symlink.

Poettering: Why systemd?

Posted Apr 30, 2011 8:12 UTC (Sat) by MisterIO (guest, #36192) [Link] (1 responses)

To me it seems less clear now. It has a lot of useless information. If the system is little, it may not matter, but it may become confusing quite easily. IMO there should be a file where I can see only the mount points of actual partitions(and possibly bind points).
For example, the first lines of /etc/mtab in Fedora now are:
rootfs / etc
/proc /proc etc
/sys /sys etc
udev /dev
then a lot of cgroup, systemd-1, devpts, tmpfs, selinuxfs

None of these are actually useful to me(and most likely to the majority of people out there) and some of them are kind of hilarious(rootfs / , wow, this one is really useful)!

Poettering: Why systemd?

Posted May 11, 2011 18:29 UTC (Wed) by nix (subscriber, #2304) [Link]

It's more truthful now. rootfs is really mounted. Yes, / is mounted on top of it after early boot, but rootfs is always still *there*, and has been since the kernel 2.2 days or maybe even earlier.

Poettering: Why systemd?

Posted Apr 30, 2011 16:23 UTC (Sat) by obi (guest, #5784) [Link]

Not sure what your problem is, but it's likely a problem with your setup: systemd on Debian has been working for me and booting me in my GUI since quite a few months.

I've got some other issues with it on Debian, like it not supporting Debian's crypttab options properly (using scripts for smartcards, usb sticks, and decrypt_derived). But I expect suitable alternatives to appear soon enough.

Poettering: Why systemd?

Posted May 1, 2011 12:41 UTC (Sun) by Eckhart (guest, #74500) [Link] (1 responses)

Your problem in v20 is probably issue #4 in http://wiki.debian.org/systemd#Known_Issues_and_Workarounds

v25: it is in experimental for a reason.

Poettering: Why systemd?

Posted May 3, 2011 13:16 UTC (Tue) by MisterIO (guest, #36192) [Link]

It's not issue #4, as I don't have any of those packages installed.
Like I said, it doesn't start dbus, that in turn may be caused by some other problem somewhere else, I don't know.

Poettering: Why systemd?

Posted Apr 29, 2011 15:46 UTC (Fri) by Banis (guest, #59011) [Link] (2 responses)

It's rather clear we're moving this direction, but could we be a little less obviously bias in the propaganda articles?

Poettering: Why systemd?

Posted Apr 29, 2011 19:35 UTC (Fri) by martinfick (subscriber, #4455) [Link]

Well, it states clearly that it is an attempt to showcase systemd. Could you actually point out the biases you see, so that we can benefit from your insights?

Poettering: Why systemd?

Posted Apr 29, 2011 20:08 UTC (Fri) by mezcalero (subscriber, #45103) [Link]

How can propaganda not be biased? That's like icecream which doesn't make fat. A contradiction in itself.

Also, I made clear that it's one of the creators of systems writing this and that you should take it with a grain of salt hence, in one of the first paragraphs.

Missed some rows

Posted Apr 29, 2011 16:24 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (57 responses)

I think systemd has a lot going for it, but this isn't a fair comparison. For example, this comparison is missing these rows: 

                              sysvinit   Upstart   systemd
Works on FreeBSD?               Yes        Yes?      No
Works on Debian GNU/kFreeBSD?   Yes        Yes?      No
Works on OpenBSD?               Yes        Yes?      No
Works on NetBSD?                Yes        Yes?      No
Works on OpenSolaris?           Yes        Yes?      No
...

Well, you get the point. Systemd is so tied to Linux's extensions that it can't even *run* without a Linux kernel. Lennart Poettering has argued why that's okay, and for many that may be fine. I think systemd is pretty cool in a lot of ways. But if you want an init system that works everywhere, systemd is *NOT* it.

Missed some rows

Posted Apr 29, 2011 16:41 UTC (Fri) by Sho (subscriber, #8956) [Link]

From the linked article: "We'll be comparing the three most relevant init systems for Linux: sysvinit, Upstart and systemd."

Missed some rows

Posted Apr 29, 2011 16:43 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

A valid point. Anyone likely to care is also likely to be well aware of it already, of course.

Missed some rows

Posted Apr 29, 2011 17:11 UTC (Fri) by AndreE (guest, #60148) [Link] (9 responses)

Not such a huge sticking point on Linux Weekly News is it? Should all articles about the open source graphics stack also go out of their way to highlight that the current free software graphics technology is only supported on linux as well? Hell perhaps we should not have any more articles about ext4 and btrfs

It matters to some

Posted Apr 29, 2011 17:30 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (8 responses)

While the name is historically "Linux Weekly News", LWN has been more generally about free software for a very long time. "What is this LWN thing?" says that "LWN.net aims to be the premier news and information source for the free software community". Not just for Linux.

I didn't say it was a sticking point, I said it was an attribute that matters to some, and it's important to note this as a weakness. It's NOT true that absolutely all "current free software graphics technology" is only supported on Linux; last I checked, FreeBSD, NetBSD, and others have GUIs. Sure, there's lots of recent goodness that is Linux-specific, but that doesn't mean there's an absence of anything else.

Since Linux is the majority FLOSS kernel, you could argue that FLOSS no point of FLOSS programs supporting anything else. You could also argue that "standards and portability no longer matter now that we have FLOSS" - i.e., you could claim that open standards were useful when there was no FLOSS, but FLOSS now fills the role of an "executable specification" and specs simply aren't relevant any more. But a lot of people do NOT agree with such arguments; unportable infrastructure like systemd is a BIG problem with this group, and it's important to note that as a downside.

It matters to some

Posted Apr 29, 2011 17:35 UTC (Fri) by jonabbey (guest, #2736) [Link]

If systemd is a truly good design, perhaps the other kernels will implement the features required to support it.

It matters to some

Posted Apr 29, 2011 17:48 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link]

s/that FLOSS/that there's/

It matters to some

Posted Apr 30, 2011 2:18 UTC (Sat) by AndreE (guest, #60148) [Link] (5 responses)

The comparison with graphics system is actually quite appropriate.

In kernel graphics drivers don't exist on the BSDs, so none of the X graphics driver improvements and support in the last 3 years can be utilised by these systems. That means no open source ATI drivers, no open source nouveu drivers, and being stuck using vesa or vga for any recent cards.

Yes, these systems have GUIs, but then again, these systems also have their own init systems.

If you are so against systemd for not being supported on other systems, you must be against the changes in X over the last three years.

It matters to some

Posted May 1, 2011 3:55 UTC (Sun) by VelvetElvis (guest, #69142) [Link] (4 responses)

Well, Debian obviously can not adopt it as it has been a multi-kernel distribution for some years, supporting HURD and FreeBSD kernels in addition to Linux.

It matters to some

Posted May 1, 2011 9:32 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (2 responses)

Systemd is available in Debian GNU/Linux unstable.

It matters to some

Posted May 1, 2011 11:13 UTC (Sun) by HelloWorld (guest, #56129) [Link]

It can't be installed currently though (due to a conflict with udev).

It matters to some

Posted May 2, 2011 10:30 UTC (Mon) by nicooo (guest, #69134) [Link]

I think the issue is that it can't be the default init system unless it also runs on those systems.

It matters to some

Posted May 2, 2011 8:55 UTC (Mon) by AndreE (guest, #60148) [Link]

Ummm, Debian supports KMS and in-kernel graphics drivers though, somehow...

Missed some rows

Posted Apr 29, 2011 17:54 UTC (Fri) by mezcalero (subscriber, #45103) [Link] (34 responses)

Upstart is linux-only too. And i seriously doubt sysvinit in the version that is usually used is actually that portable, resp. is actually realistically used by anybody on those OSes, except maybe debian kfreebsd. I think requesting portability to other kernels for a lowlevel OS component like an init system is not valid in any way. You are trying to create the impression that this was relevant for upstart or sysvinit, but it never was. And it is neither for systemd.

Missed some rows

Posted Apr 29, 2011 18:00 UTC (Fri) by dlang (guest, #313) [Link] (33 responses)

the init binary itself may or may not have been portable, but the stuff needed to start and stop an application was very portable.

Missed some rows

Posted Apr 29, 2011 18:17 UTC (Fri) by martinfick (subscriber, #4455) [Link] (30 responses)

Then why are all the startup scripts different even across linux distributions?

Missed some rows

Posted Apr 29, 2011 18:55 UTC (Fri) by dlang (guest, #313) [Link] (29 responses)

because the distro maintainers each want to do slightly different things and don't take the time to see what the other distros are doing

there are a few things based on distros choosing to put files in different places (which systemd won't fix), but most of it is just different ways of solving the same problem.

there's a lot of third-party software available that includes the init files, and that software has no problems using the same scripts on many different distros (they just decide where to put their stuff and don't care if it's where the distro maintainers would put it)

I expect the same type of thing to start happening with the systemd config within a year or two of it becoming the default.

Missed some rows

Posted Apr 29, 2011 19:08 UTC (Fri) by martinfick (subscriber, #4455) [Link] (19 responses)

> because the distro maintainers each want to do slightly different things and don't take the time to see what the other distros are doing

And this is an advantage of not using systemd?

> there are a few things based on distros choosing to put files in different places (which systemd won't fix), but most of it is just different ways of solving the same problem.

So tell me again where is the advantage of having "different ways of solving the same problem"?

> I expect the same type of thing to start happening with the systemd config within a year or two of it becoming the default.

If the differences are the only thing that will likely cause them to have different config files, then I would say that systemd has done an excellent job! The differences, the policies, are exactly the things that should be configured in these files, not the mechanisms!

To paraphrase your statement, "the shell scripts are a small amount of different policy and large amount of mechanism (all implemented differently)." Finally, with systemd, the policy is abstracted and obvious and the mechanism can be the same, (more common code and likely way better tested in the long run)!

Missed some rows

Posted Apr 29, 2011 21:20 UTC (Fri) by dlang (guest, #313) [Link] (18 responses)

>> because the distro maintainers each want to do slightly different things and don't take the time to see what the other distros are doing

>And this is an advantage of not using systemd?

it's not an advantage, it's reality, and it will be reality with systemd as well, just give it a little bit of time

> So tell me again where is the advantage of having "different ways of solving the same problem"?

if we didn't allow for different ways of solvign the same problem, nobody would ever be able to find a better way (and systemd for example could not even be attempted because the OS wouldn't work with it)

you are taking advantage of the fact that the system allows you to solve things in a new way to create systemd, but then claiming that the freedom to do so isn't important for anyone else.

Missed some rows

Posted Apr 29, 2011 21:46 UTC (Fri) by martinfick (subscriber, #4455) [Link] (17 responses)

> if we didn't allow for different ways of solvign the same problem, nobody would ever be able to find a better way (and systemd for example could not even be attempted because the OS wouldn't work with it)

Who said anything about not allowing different ways? The freedom to do so is great. Does that mean it should be done differently without a good reason? Systemd attempts to unify different ways when it makes sense and when there is no good reason for them to be different. In most of these cases it makes sense, if not, why would the different distros agree to switch? Likely because they agree with the proposed way that systemd solves these problems.

No to mention that most of these old ways are likely broken! Many of them are nasty old hacks because there isn't a good common solution implemented anywhere. For example, do you really think that keeping track of pids in files is a better way to kill a daemon than using cgroups? Such a mehtod is fraught with potential miss kills, I am shocked that enterprise distros allow such behavior... "oops, just killed the company database server when I meant to kill my homebrewed monitoring script". Today, most distro scripts are likely knowingly broken. Do you think the average homebrewed script even has a chance of being only half as broken as a distro script? I suspect that systemd makes writing an unbroken homebrewed startup config possible and likely.

Missed some rows

Posted Apr 30, 2011 0:22 UTC (Sat) by nicooo (guest, #69134) [Link] (16 responses)

> if not, why would the different distros agree to switch?
Which ones? I only know of F15.

> I am shocked that enterprise distros allow such behavior
It worked for enterprise unix.

Missed some rows

Posted Apr 30, 2011 8:16 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Meego has switched in their devel branch. OpenSUSE next version. Mandriva has already switched as well. Keep looking.

Oh, yeah.

Posted Apr 30, 2011 9:51 UTC (Sat) by khim (subscriber, #9252) [Link]

It worked for enterprise unix.

Wow. Talk about ignorance! There are many things which worked for Unix till it got serious competition. Then it lost first desktop, then server and not the bettle for enterprise is in full swing.

I fail to see how "it worked for enterprise unix" can be used as justification. Sure it did - because there was no alternative. Some things "enterprise unix" does are still better then what the Linux does, but the list shrinks over time... and usaged of pid files to manage daemons instead of cgroups is not one of them.

Missed some rows

Posted Apr 30, 2011 11:29 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

Actually, no. The problem with miskills due to PID wraparound are very well-known.

Various 'enterprise' Unixes had workarounds since forever. Like ability to 'lock' PID of a process (so it won't be reused). Or locking PID for several minutes after getpid() calls (so "ps | grep ... | xargs kill" won't kill some innocent process).

Missed some rows

Posted May 3, 2011 1:21 UTC (Tue) by wahern (subscriber, #37304) [Link] (11 responses)

That all seems so convoluted. The whole problem boils down to the size of the namespace and the familiar TOCTOU race condition. The cgroups solution works because it uses a different namespace with well-crafted rules, and really only works in the context of systemd, which is taking on a role--maintaining a persistent, unique, global namespace--part of which should be done in the kernel.

The easiest and cleanest general purpose solution would be to extend the PID namespace to 64-bits, or maybe even 128-bits. Problem solved. This is a common solution for when maintaining and communicating a consistent global state is not practically feasible, which is the case with the historical paradigm of process management on Unix.

I don't know why this has never been done. The existing 16-bit namespace is ridiculous. There should be a kernel compile-time option to increase the pid_t width. Then over the course of several years broken applications that make unwarranted assumptions about pid_t could be fixed. The vast majority of issues are probably with printf formatting; people usually cast pid_t to (int). If PIDs were chosen at random (as on OpenBSD) than the 31- or 32-bits shown would actually be useful, much like Git's truncated hash identifiers. So even most broken apps would only be half broken.

I realize it's a *huge* change, but its simple and straight-forward, the consequences are mostly foreseeable, and with open source software readily addressed by even casual C programmers. GCC could be instrumented to track pid_t conversions, and in a matter of weeks I bet Debian's build system would uncover the vast majority of issues. All of a sudden one of the most ugly Unix warts--that is, fundamentally broken in the context of common usage--disappears.

Missed some rows

Posted May 3, 2011 9:10 UTC (Tue) by leighbb (subscriber, #1205) [Link] (1 responses)

Just so that you are aware, you can actually enable a 22-bit pid by doing:

sysctl -w kernel.pid_max=4194304

Not as much as you were after but bigger than you thought :-)

Missed some rows

Posted May 3, 2011 13:13 UTC (Tue) by wahern (subscriber, #37304) [Link]

Thanks. I was completely unaware.

Missed some rows

Posted May 3, 2011 15:03 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Not really. By going to 32 bits for PID namespace this problem still won't be solved, it will just be harder to trigger.

And larger PID lengths are way too clumsy for humans. That's definitely NOT a good engineering.

Besides, even with 128-bit PID length you'll still have problems with double-forked processes (which are reparented to init).

systemd nicely solves these problems.

Missed some rows

Posted May 3, 2011 18:17 UTC (Tue) by wahern (subscriber, #37304) [Link] (7 responses)

A larger PID wouldn't do everything that systemd does with cgroups. cgroups does two things: (1) provides a larger namespace (roughly 2^(8 * 255) bits, AFAIU) to identify processes, and (2) handles inheritance. But a larger PID would solve in a backwards compatible fashion the one clear issue in Unix process management, the signal-PID race, which is more-or-less the same as the first thing above. Although I'm not familiar with cgroup usage, I think that there's still a race in adding a fresh process to a cgroup, so even systemd could benefit from a larger PID space.

It's really only an unresolvable issue when you have errant, buggy processes. Otherwise, a sophisticated daemon should have a domain socket which takes control messages. But I'm presuming that process management means being able to handle processes that aren't well behaved.

Missed some rows

Posted May 3, 2011 18:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Signals must die, they are a relic of ancient time.

>Although I'm not familiar with cgroup usage, I think that there's still a race in adding a fresh process to a cgroup, so even systemd could benefit from a larger PID space.

Nope. cgroups work on kernel level and so they use proper locking, so PIDs won't be able to leak. Also, one can easily protect processes in a cgroup from an accidental kill (in fact, cgroups can be used as a complete lightweight virtualization solution).

Missed some rows

Posted May 4, 2011 5:03 UTC (Wed) by wahern (subscriber, #37304) [Link] (5 responses)

I'm confused then. Say I have a new process which I want to add to a cgroup. How do I assign the process to a cgroup? All the documentation I can find says to echo the PID to a cgroup control file. But if I'm using a PID--and I'm not the process with that PID--then I'm still subject to a race--the PID can become stale between acquiring the value and communicating it to the cgroup subsystem.

cgroup inheritance I can understand. A process forked from a process already assigned to a particular cgroup atomically inherits membership in the cgroup, just as it would atomically inherit a session id and process group id. But now, say, I want to reassign that process to a different cgroup PID. It seems like there's the same problem as above. What am I missing?

Missed some rows

Posted May 4, 2011 5:44 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

That's a trick question.

You need to somehow have a unique process handle, which PID is definitely not. On Linux it can be done using the /proc/PID/ directory. The sequence would be:
1) Change current directory to /proc/PID
2) Look around and check that this PID is still the correct one. That's safe because if the process its /proc/PID directory becomes empty - and stays that way.
3) Write to /proc/PID/cgroup.

Of course, it's better to create a process directly in the required group in the first place.

Missed some rows

Posted May 4, 2011 8:26 UTC (Wed) by wahern (subscriber, #37304) [Link]

I thought /proc/$PID/cgroup was read-only; to add a process to a group you needed to write to /dev/cgroup/$TASK/tasks. In such case, you're left with a race condition. (I tried confirming or disproving this, but can't even get the example in cgroups.txt to work.)

My proposal was to make PID a unique quasi-handle the same way random UUIDs are unique.

Missed some rows

Posted May 4, 2011 19:31 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses)

> Say I have a new process which I want to add to a cgroup. How do I assign the process to a cgroup? All the documentation I can find says to echo the PID to a cgroup control file. But if I'm using a PID--and I'm not the process with that PID--then I'm still subject to a race--the PID can become stale between acquiring the value and communicating it to the cgroup subsystem.

In the above scheme, if you're the one who's spawning this new process that you want to end up in a cgroup, then you can do
1) fork
2) the child adds itself to the desired cgroup
3) the child calls exec()

That's race-free.

Missed some rows

Posted May 4, 2011 21:08 UTC (Wed) by wahern (subscriber, #37304) [Link] (1 responses)

Sure. But the issue is handling arbitrary, non-well behaving processes. And AFAICT there's still no provably safe way to handle that on Unix systems. With only a 16-bit (or 15-bit, or 22-bit) PID space, it's trivial to write a program to sit around and wait to take advantage of a race. (I don't have an attacker mindset, but I wouldn't bet against the proposition that it could be a useful vector.)

Of course, "who cares" is a valid reply; we've been living with it for 40 years. But that response challenges the value added by systemd's reliance on esoteric Linux subsystems. For example, when we talk about how a service manager is so much better than a race-prone PID file, nobody ever considers that the race condition is easily avoided by not using root. If you create a user per daemon--_www, _ftp, etc--then even if you read a stale PID and signal the wrong process, as long as you're sending the signal with a service-delegated UID then it will never be delivered.

I never brought it up before because it's arguably not very elegant. I'm loath to defend PID files. But if we're going to replace them with something, I'd like it to be generic and tailored to the specific issue, rather than lauding some supposed panacean init replacement.

The past decade in Linux-land has seen a parade of sophisticated daemon services intended to patch over some clunky Unix interface (device management, process management, etc, etc). They each require application developers to change from portable POSIX patterns to using some new API or library or protocol. But they come and go like the wind. Worthy solutions tend to be so obviously beneficial that all the free unices eagerly adopt or mimic them.

Missed some rows

Posted May 5, 2011 1:06 UTC (Thu) by njs (subscriber, #40338) [Link]

I guess I don't understand what you mean by "managing arbitrary, non-well behaving processes".

IIUC, when systemd starts a service, that service gets stuck (reliably, and race-freely) into its own cgroup, from which it cannot escape. Then you can kill it or whatever reliably, even if it's badly behaved (spawning children that double-fork and end up as orphans, forking to a new PID every 100 ms, whatever you like).

If you're trying to go after a process that was started outside of a cgroup, then this doesn't work so well, but not much does. That process that keeps switching PIDs as quickly as possible can't easily be killed even if you have a collision-free PID space.

Missed some rows

Posted May 4, 2011 21:28 UTC (Wed) by mjthayer (guest, #39183) [Link]

> Actually, no. The problem with miskills due to PID wraparound are very well-known.

> Various 'enterprise' Unixes had workarounds since forever.

A workaround I implemented a while ago for "normal" Unixes was for the daemon to place an advisory lock on its pidfile. It only works on filesystems with that feature of course, but by checking that the file is locked before issuing your kill command you greatly reduce the race window.

Missed some rows

Posted Apr 29, 2011 19:57 UTC (Fri) by mezcalero (subscriber, #45103) [Link] (8 responses)

Actually, systemd -- if successful -- will standardize a lot of configuration and the places it is stored it.

I think you have little experience with actually writing sysv init scripts. Making them portable between distributions is irrationally hard, and even LSB headers, which were supposed to improve the situation just made it worse. Most (all?) upstream software I have seen which ships init scripts has different init script implementations for the different distributions.

And no, I see no reason that distros will differ too much on the systemd unit files. Why I come to that conclusion? Well, we have stuff like .desktop files or D-Bus service activation files, and they do not differ between distributions. They are the same everywhere. And they have been around for quite some time now already. With systemd we make service descriptions as easy and portable as .desktop files and D-Bus service files, and thus I see little reason to believe that the distros will try to divert too much from upstream.

Missed some rows

Posted Apr 29, 2011 21:22 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

you are right, I've only been making my living administering unix systems of various flavors for 14 years, so I can't possibly understand what it takes.

someone who comes along and states that we should ignore anything that's not a linux box (and then in practice limits it further by eliminating the entire embedded space) understands the issues better.

Missed some rows

Posted Apr 30, 2011 13:47 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

systemd works just fine on embedded devices. In fact, it works BETTER than SysV-based scripts.

Missed some rows

Posted Apr 29, 2011 22:44 UTC (Fri) by dskoll (subscriber, #1630) [Link] (5 responses)

Most (all?) upstream software I have seen which ships init scripts has different init script implementations for the different distributions.

We use the same init script across all our Linux distros (and even on the BSDs) for our commercial product.

That being said, our product is largely written in Perl, so we wrote the init script in Perl too. That might make some recoil in horror, but it simplifies our life quite a bit, and since you need Perl to run our product anyway... :)

Missed some rows

Posted Apr 29, 2011 23:06 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (4 responses)

Do you believe that the care and effort you put into the portability of your init script is typical or atypical?

Do you have any conditional logic in your perl based init script which fires depending on the environment your script ends up running under?

I don't think he was claiming that it is impossible, I believe the claim is one of pragmatic realities of the accumulating differences across distributions makes a strawman out of any argument about assuming perfect portable initscripts commonly found in the wild.

-jef


Missed some rows

Posted Apr 29, 2011 23:19 UTC (Fri) by dlang (guest, #313) [Link]

I have seen several perfectly portable init scripts on third-party software.

the distro maintainers don't like them, but the software is unconditionally put in one place, no matter what OS it is (frequently under /opt) and the init scripts start and stop the application without any problems.

this isn't just for trivial apps either, all it takes is a decision that you don't care what the 'normal' thing for this particular platform is, (frequently on the basis that the platform is just there to support the application, which is commonly valid) and you don't have to worry very much about the variations between platforms.

Missed some rows

Posted Apr 30, 2011 2:59 UTC (Sat) by dskoll (subscriber, #1630) [Link] (2 responses)

Do you believe that the care and effort you put into the portability of your init script is typical or atypical?

Oh, hey, I'm all for systemd. I think it's a great idea. It won't help us on non-Linux platforms, though. (At least not for a while...)

Do you have any conditional logic in your perl based init script which fires depending on the environment your script ends up running under?

Nope. The Perl stuff is used so we can have pluggable components to start different executables depending on what's installed and on how the particular node is configured. It also rationalizes PATH handling, but there's no platform-specific code.

Managing programs startup using a perl script

Posted Apr 30, 2011 19:49 UTC (Sat) by rvfh (guest, #31018) [Link] (1 responses)

Question is: how will this work with systemd? A service calling your script (which looks to me as a kind of init system in itself)?

Managing programs startup using a perl script

Posted May 1, 2011 6:40 UTC (Sun) by dskoll (subscriber, #1630) [Link]

Question is: how will this work with systemd?

I can't imagine there will be any problems. To the outside world, our script looks like a normal sysvinit script:

script start

script stop

etc...

Missed some rows

Posted Apr 29, 2011 18:37 UTC (Fri) by aleXXX (subscriber, #2742) [Link]

Congratulations to be a supporter ! :-)
Great :-)

Alex

Missed some rows

Posted Apr 29, 2011 20:04 UTC (Fri) by mezcalero (subscriber, #45103) [Link]

Dude, neither the sysvinit init binary is portable, nor the init scripts. In fact the init scripts are the best example for non-portability: you can't even really write them in away to be portable between distros -- let alone kernels/OSes.

In fact you can turn this all around and claim that systemd improves portability here -- the portability between various Linux distributions for upstream packages: because they can just hook themselves into the boot in a single unified way, that is the same on all distros (which have adopted systemd).

So if you say that systemd was worse with portability I say it actually drastically improves it.

Missed some rows

Posted May 1, 2011 2:51 UTC (Sun) by drag (guest, #31333) [Link] (8 responses)

If it doesn't run on Windows it's NOT portable.
If it doesn't run on OS X then it's NOT portable.

It seems to me that in these type of articles people are ready to harp about compatibility of dead and dying OSes, but completely ignore the portability to systems that people actually use.

Out of that chart you posted only FreeBSD and OpenBSD really matter. And those use their own init systems already. If anybody was going to spend the time to port them over to a new init system lets just hope that they choose something that is actually a improvement like Launchd.

GNU/kFreeBSD is a toy OS. Like Haiku or ReactOS it's all nice and interesting in it's own way, but it's not relevant and nobody actually uses it besides a tiny amount of people.

OpenSolaris is dead. It may thrash around for a few more years and it may exit out of the 'Dead Like Hurd' category and move back up into 'Toy OS like Haiku', but it's not going to amount to anything.

Portability doesn't mean the same thing now that it did 20 years ago. I wish people would stop pretending that it does.

Missed some rows

Posted May 1, 2011 18:02 UTC (Sun) by dskoll (subscriber, #1630) [Link] (7 responses)

If it doesn't run on Windows it's NOT portable.

If it doesn't run on OS X then it's NOT portable.

Many Linux developers care only about UNIX-like systems. Windows is certainly not UNIX-like, and OS X is getting less and less UNIX-like with each release.

Bottom line: Windows and OS X aren't even on many Linux/UNIX developers' radars. They simply don't matter. (Sure, maybe in the mass market they're important, but in the little niche of UNIX/Linux software in which I'm content to work and play, Windows and Mac OS X are completely irrelevant.)

Missed some rows

Posted May 1, 2011 18:19 UTC (Sun) by HelloWorld (guest, #56129) [Link] (6 responses)

I guess it's because Mac OS X is getting less and less UNIX-like that it has been certified as a Unix by the Open Group.

Missed some rows

Posted May 1, 2011 18:25 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

Nobody in the real world takes that seriously.

Missed some rows

Posted May 1, 2011 21:22 UTC (Sun) by anselm (subscriber, #2796) [Link] (3 responses)

That means it supports the usual system calls and command line utilities so you can get basic stuff to run on it. It doesn't vouch for the underlying philosophy.

Even Windows NT used to be POSIX certified, way back when, and nobody would have confused that with a real Unix.

Missed some rows

Posted May 2, 2011 13:32 UTC (Mon) by HelloWorld (guest, #56129) [Link] (2 responses)

The so-called "Unix philosophy" most of the time boils down to dogmatism and retrogressiveness, so I honestly couldn't care less about it. Cyberax summed it up pretty well here.

Unlike the people bullshitting about the "Unix philosophy", people like the Mac OS X developers and Lennart Poettering actually have visions about where they want the system to go, and they're not afraid to point out the suckiness of traditional system components like X11 or sysvinit. And this is the reason why Linux and Mac OS X thrive, while nobody gives a fuck about traditional Unix systems and their "philosophy" anymore.

Missed some rows

Posted May 2, 2011 14:40 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

The so-called "Unix philosophy" most of the time boils down to dogmatism and retrogressiveness, […]

I would recommend you take a look at the Wikipedia page on »Unix philosophy«. That should disabuse you of that particular notion.

Note that there is nothing on that page that says »Don't go for better solutions to existing problems.« And with all philosophies, this stuff is not meant to encourage one to stop thinking on one's own. That way lies blind fanaticism.

Missed some rows

Posted May 2, 2011 15:19 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

Having looked at that, I really fail to be persuaded that systemd violates Unix philosophy even half as severely as most of the Lennartware-haters say it does.

Missed some rows

Posted May 1, 2011 21:22 UTC (Sun) by dskoll (subscriber, #1630) [Link]

Exactly! You've finally figured out who is and who isn't relevant in the UNIX world.

Missed some rows

Posted May 5, 2011 20:12 UTC (Thu) by zuzzurro (subscriber, #61118) [Link]

By this argument people should not have chosen linux at 0.12 because it was only running on x86.
If people like it, people will port it, one way or the other.

Poettering: Why systemd?

Posted Apr 29, 2011 17:10 UTC (Fri) by jonabbey (guest, #2736) [Link]

Having been running on Fedora 15 beta for a couple of weeks now, I can see the benefits of systemd in its cleanliness and orderliness.

It sure took some time to get used to having something as essential to Linux as init change after all this time, though.

Poettering: Why systemd?

Posted Apr 29, 2011 23:25 UTC (Fri) by fest3er (guest, #60379) [Link]

I'm still trying to figure out why SysV init and startup scripts are mentioned in the same sentence. They're almost unrelated. With so little of init's functionality being used during startup (starting/stopping daemons, different run levels to do different things), inittab might as well be emptied of all but the init script and startup should be handled in the traditional BSD manner.

Poettering: Why systemd?

Posted May 2, 2011 6:44 UTC (Mon) by PaulWay (guest, #45600) [Link] (13 responses)

As far as I can see, the objections are basically:

"Hey, this is my system, I set it up just so, I've gotten used to all its little quirks and eccentricities, so it must be correct and a Good Thing. We hand-coded our start-up ordering and fixed things by hacking the init scripts and we liked it! I've seen those young turks come along and tell everyone how devfs was going to cure our ills and that kind of gim-crackery. Now some young hotshot who doesn't even have a beard comes along and tells me all that is wrong? Well, golly gee, that just goes against my principles! How am I supposed to learn some new-fangled thing over which I can't exercise complete control in the only way I know how?

"And he comes in here telling us all he's sorted everything out and he's shown all these red boxes against my favourite SysV init system! How dare he! The role of telling people exclusively how they should be doing things is mine, I tell you, mine! Just look at the fact that he claims to solve everything and work perfectly - he must be wrong, only my code does that! He'd better leave off or I'll find whatever standards suit me and shove them up his nose!"

Sorry, ladies and gentlemen, but it just looks like a "Mine's Better" competition at this point. A lot of the arguments are devolving down to 'well your example sucks' and hyperbole, which is never a good sign.

None of the 'advantages' of SysV init have been things I've enjoyed working with for the last 20 years I've been working with Unix systems. I'm sure we'll find out the problems with systemd in the long run, and I'm sure there are things it won't be able to solve, but I do think it's a lot better designed and a lot more comprehensive than SysV.

Have fun,

Paul

Poettering: Why systemd?

Posted May 3, 2011 11:11 UTC (Tue) by sorpigal (subscriber, #36106) [Link] (6 responses)

There's a little "Mine's better" here, sure. I think the negative reaction to systemd is more due to the fact that it lumps into one opaque binary what used to be in many discrete ones, obscuring how the systems works. Then, the author makes attacks on shell scripts (which always read like an attack on control, which I take as an attack on myself).

I like everything about systemd except: (1) it's not simple to understand and therefore I don't understand it and therefore it's worse than sysvinit. (2) It advocates a level of non-negotiable integration between daemons and the init system which effectively entrenches systemd (or something so equivalent that a redesign later becomes extremely non-trivial) as the only possible init system. (3) Its author appears fanatical more than pragmatic. (4) Its configuration files are unpleasantly ugly. (5) It cannot be the universal init system because its author specifically opposes the existence of operating systems which are not Linux, or thinks that they do not deserve support by any daemon which also runs under Linux.

If systemd is good then we should use it for all OSes, or at least all Unix-like systems. If it's not good for that then it's not good.

Poettering: Why systemd?

Posted May 3, 2011 11:31 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (2 responses)

So if the BSDs, or AIX, or Solaris, reject a kernel feature, we should never be able to take advantage of it in init?

Poettering: Why systemd?

Posted May 3, 2011 15:35 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

no, init should support a fallback to another way of working.

it's not even that everyone is demanding that he code all such fallbacks into systemd, it's that he has made it clear that he considers any such fallback to be a waste of time and therefor nobody else would bother to submit any patches.

there's a huge difference between being apathetic about non-linux systems (i.e. you don't care about them) and being hostile (i.e. considering that nobody else should care about them either)

apathy is just fine as long as you are willing to accept patches and support from people who do care about such systems.

Poettering: Why systemd?

Posted May 3, 2011 15:50 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

That's a assumption that flies in the face of reality. For instance, systemd can work without cgroups because patches were submitted. It wouldn't be as functional as when cgroup is available but that is expected.

Poettering: Why systemd?

Posted May 3, 2011 11:41 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

"I think the negative reaction to systemd is more due to the fact that it lumps into one opaque binary what used to be in many discrete ones, obscuring how the systems works"

Have you run a system with systemd at all? Because it has several different binaries to do different things

1) sysvinit was simple in its core but it left a lot of important features outside to bash scripting and every distro had its own convoluted slightly different mess. systemd integrates and standardizes all this

2) not sure what this means

3) not sure what this means either

4) ini file format is way way more simpler than copy pasting boiler plate shell scripts.

An important aspect is that unlike sysvinit, systemd comes with extensive documentation. This is a major advantage that ends up reducing complexity in the practical sense

Poettering: Why systemd?

Posted May 3, 2011 14:18 UTC (Tue) by mjthayer (guest, #39183) [Link] (1 responses)

To 5), it would be lovely if systemd features that depended on Linux-specifics could be made compile-time optionals. I think that would even fit in with Lennart's idea of Linux driving innovation - other OSes could catch up at their own pace if they wished. Although I think that the BSDs have their own versions of some of the Linux-specific stuff that systemd uses.

Regarding the cgroups dependency though - wouldn't it be better to rewrite the daemons that systemd starts to have a "do not daemonise" option, so that all their children just stay in one process group or at least one session, and to keep the cgroups thing as a backup option for the recalcitrant ones? "Roll your own" daemonising seems to me the sort of hack that systemd is trying to make unnecessary.

Poettering: Why systemd?

Posted May 4, 2011 21:39 UTC (Wed) by mjthayer (guest, #39183) [Link]

> To 5), it would be lovely if systemd features that depended on Linux-specifics could be made compile-time optionals.
[...]
> Regarding the cgroups dependency though - wouldn't it be better [...] to keep the cgroups thing as a backup option for the recalcitrant ones?
Rahul answered that replying to a different posting a little bit up - cgroups is now indeed compile-time optional.

Poettering: Why systemd?

Posted May 3, 2011 14:34 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (5 responses)

Shorter: Everything should be standardized, but not if it requires me to change.

Poettering: Why systemd?

Posted May 3, 2011 14:58 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

How do you expect that to really work? Foo distro does A, Bar distro does B. They are functionally equivalent. Either you have to standardize on one or the other or invent something new for standardization and it requires atleast one set of users to adopt something new to them.

Poettering: Why systemd?

Posted May 3, 2011 15:32 UTC (Tue) by cry_regarder (subscriber, #50545) [Link]

I think he was being tongue in cheek...

Poettering: Why systemd?

Posted May 3, 2011 21:33 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

Sorry, I seem to be using a form you're not familiar with. The "Shorter:" means I'm summarizing the previous poster's point. In this case, I'm suggesting that the complainers are only in favor of standardization as long as it doesn't force them to change. I agree that this is an unreasonable position. Since I think increased standardization is a good idea, this means people will have to accept some change.

I guess the situation with systemd reminds me of two other situations I've encountered. One was a disagreement between a mechanic and an engineer about cars. The mechanic liked carburetors because he was confident he could fix a carburetor if it ever broke; the engineer preferred fuel injectors because they were much less likely to break in the first place. It seems to me that the supporters of SysV with traditional scripts are like the mechanic; they like that they know how to modify the scripts but ignore that many of their hacks would be unnecessary with a better designed system.

The other is something that the Gnome maintainers commented about their decision to eliminate many configuration options. They said that many requests for new configuration options were really requests to fix bugs, but that the people requesting the "not broken" option didn't realize that the behavior they were describing shouldn't have been happening in the first place. I suspect, though I'm not sure, that many of the configuration tweaks that supporters of the current system are talking about are really bug fixes. They're asking that we maintain their ability to patch other people's breakage rather than move to a system that isn't so broken to start with.

Poettering: Why systemd?

Posted May 3, 2011 21:38 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

the problem that you (and the Gnome maintainers) have is that you think that there is one definition of 'fixed' that applies to everyone.

a lot of the people who are disagreeing with you think that different people may want slightly different things.

Poettering: Why systemd?

Posted May 3, 2011 21:43 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

It is easy to discuss these sort of these in abstract terms without any room for consensus or even letting the other person really know what the heck is being discussed. So in the particular blog post, there is a long list of things that are being standardized and fixed. If there is a disagreement about any of those, it should be voiced and in specific terms. Anything else is meaningless handwaving.

Poettering: Why systemd?

Posted May 2, 2011 21:41 UTC (Mon) by piggy (guest, #18693) [Link] (1 responses)

What's missing from the blog post that I'd like to read is the rationale for including all of the listed features in an init system. E.g. "Network Loopback device handling"--why shouldn't that be handled by a network configuration subsystem? Or "PAM integration"--what's systemd doing that has anything to do with PAM?

Poettering: Why systemd?

Posted May 2, 2011 22:06 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

The PAM integration is for systemd's user session management.

Poettering: Why systemd?

Posted May 5, 2011 20:31 UTC (Thu) by zuzzurro (subscriber, #61118) [Link] (2 responses)

Until now nobody mentioned the one feature i find most anti Unix-philosophy of systemd (and I'm a big supporter of its whole design and ideas, having used plenty of Unix starting from v6 on a pdp11/34 and seen the evolution of the rc system and witnessed with hope the birth of inetd, with its nice activate on demand concept).

Don't you guys hate the way systemctl runs your $PAGER by default without you asking for it? Gee, I hate that... If i want to type systemctl | less, I will just do it, for $DEITY's sake. The default of running it is just backwards.

Poettering: Why systemd?

Posted May 5, 2011 20:44 UTC (Thu) by anselm (subscriber, #2796) [Link] (1 responses)

Don't you guys hate the way systemctl runs your $PAGER by default without you asking for it? Gee, I hate that...

Yes, that's a complete and utter outrage. Totally, totally against the spirit of Unix. Unbearable. Sickening. This Poettering guy must be a perfect moron – anyone with the least inkling of what is proper knows that all right-minded people just detest the same feature in »man foo«.

Poettering: Why systemd?

Posted May 5, 2011 23:18 UTC (Thu) by zuzzurro (subscriber, #61118) [Link]

Yeah, you're right. Let's just convert all commands to do that.. like ps for instance.., no wait doesn't ls suck too?


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds