LWN: Comments on "Systemd and Fedora 14"

Systemd and Fedora 14

foom — Tue, 07 Sep 2010 15:08:01 +0000

From reading some manpages:
http://0pointer.de/public/systemd-man/systemd.service.html
http://0pointer.de/public/systemd-man/systemd.unit.html

It sure sounds like they control completion ordering.

"After= ensures that the configured unit is started after the listed unit finished starting up, Before= ensures the opposite, i.e. that the configured unit is fully started up before the listed unit is started"

And, see the description of Type= on the systemd.service page.

Some questions that do 3d6 fire damage

rahulsundaram — Mon, 06 Sep 2010 17:10:36 +0000

I am sure there is 98.7 % chance of sound. Much better than ALSA's 76.5% :-)

Some questions that do 3d6 fire damage

nye — Mon, 06 Sep 2010 16:41:46 +0000

I'm sure those things would be lovely, if there was more than 50% chance that the piece of shit would produce any fucking sound at all.

Systemd and Fedora 14

Darkmere — Mon, 06 Sep 2010 08:15:29 +0000

I thought the before/after only worked for start-ordering, not completion?

I don't care if you've started the network service+network filesystem handshake, the services using files in that area may only be started after they are finished, not before.

This sort of interaction happens in reality, mostly you can pass it off like "so fix the service so it notices the new filesystem" but my reality wearing an administrator hat is... different from that.

Systemd and Fedora 14

rahulsundaram — Mon, 06 Sep 2010 07:04:48 +0000

man systemd.service shows Before=foo and After=boo for manual ordering. I think that would work for you but do drop your feedback to systemd developers in case, we can fix this automatically somehow.

Systemd and Fedora 14

Darkmere — Mon, 06 Sep 2010 06:19:55 +0000

I've played a bit with F14 alpha but have issues running it (related to nouveau drivers and my specific hardware, really) and I wanted to interject a question:

Traditionally, we have had certain things in/out-of order due to non-strict dependency issues though still "needed", for example, starting a (deny all) firewall before network, as well as waiting with samba/ftp-servers until after network-access or filesystems are available.

Such "soft" ordering doesn't appear to be on schedule for systemd, so, how will this work in the end? Fex. I want to restart some daemons that aren't perfectly well behaved if they are to work on files residing on a network drive (has happend quite a few times), previously it's been a case of manually reordering things, in systemd, I'm not quite sure anymore.

Installing both

corbet — Sun, 05 Sep 2010 23:47:36 +0000

Systemd is now working fine for me on Rawhide, but I have to wonder: why wouldn't you at least make it possible to have both systems installed, even if you're determined not to install both by default? This is a big, scary change; having the upstart fallback makes it easy to work around any crippling problems and greatly lowers the risk of the transition. The two can coexist for now; carrying that ability forward for one cycle would seem to make a lot of sense.

What am I missing?

Systemd and Fedora 14

AdamW — Sun, 05 Sep 2010 16:24:32 +0000

"Oh, and nothing's stopping you from defining a unit that runs a shellscript, if that's what you 'need' to do to get something done."

in fact, we're already doing this in F14. firstboot in F14 uses a 'native' systemd unit file, which actually just sets an environment variable and then runs /etc/init.d/firstboot...(don't ask me to explain why, it's sort of complicated. :>)

Systemd and Fedora 14

AdamW — Sun, 05 Sep 2010 16:21:57 +0000

A few notes.

One, systemd isn't just default in Rawhide at present, it's default in F14. If you install F14 Alpha, or update an F13 system to F14, you get systemd.

Two, the arrangement whereby systemd and upstart are installed side by side is only temporary and will only last until we make the final decision whether to ship systemd in F14. At that point it'll be changed so only the one we choose will be installed by default, and only one can be installed at any time.

Three, most of the bugs mentioned in this post are fixed now and were only transitory, they only affected you if you happened to update to a version with the bug. They don't affect the Alpha, and they shouldn't affect any installs of the Alpha updated direct to the current systemd release (9-3), or any systems updated straight to current F14 state.

Systemd test day

AdamW — Sun, 05 Sep 2010 16:15:57 +0000

Thanks for the plug, but note the Test Day has now been rescheduled to September 7th - this coming Tuesday - so we can use the results in deciding whether to go ahead with systemd for the beta and final releases. The page is now at https://fedoraproject.org/wiki/Test_Day:2010-09-07_Systemd

Systemd - What does it really provide?

foom — Sun, 05 Sep 2010 14:05:52 +0000

"this daemon fast-starts, never wait for it and assume it started correctly as soon as you run it"

Because that has a race condition: the other app can still try to access it too soon. "Sooner" is not soon enough, it has to be done *first*. And you can't guarantee that it'll be done first unless you have a manually maintained dependency graph (or linear startup ordering), like you need today.

That is why systemd is such a great idea: it totally removes the need to worry about dependencies most of the time. You just start programs, and if they depend on something else, they block waiting for the something else to get automatically started too, without needing to explicitly mark the dependency.

Systemd - What does it really provide?

WolfWings — Sun, 05 Sep 2010 10:48:08 +0000

From what I understand, primarilly systemd opens up all the sockets/ports/whatever that components need as early as possible, so they can all fire off their crap at the same time and rely on the kernel's networking queues and what-not and blocking read/write calls to pause stuff the minimal amount possible.

Wouldn't the same thing be possible in every case by cleaning up the daemons in question so they simply open their sockets and set them up sooner themselves? I seem to see a lot of stuff that 'preloads' everything before firing off a single socket() call, so yes, you need to load stuff in the right order or things will crash and fall to pieces.

So why not push the fixes to let stuff be started up more in parallel downstream to individual packages, then just make the init daemons able to be told "this daemon fast-starts, never wait for it and assume it started correctly as soon as you run it" more or less? We seem to be abdicating the responsibility of the developers of the component packages for bootup speed, and trying to hide it instead of encouraging/forcing bottlenecking packages to get their act together.

Systemd more robust?

gmatht — Sat, 04 Sep 2010 11:32:55 +0000

I just remotely upgraded a desktop machine to Lucid. After rebooting, I couldn't ssh into the machine anymore. I drove round and found that the machine couldn't mount the windows partition anymore. It was waiting on a prompt asking if I wanted to Skip mounting this drive or Manually fix the problem. I was thinking of reporting a bug as it seems to be bad policy to wait indefinitely on non-fatal errors.

However it sounds like a switch to systemd would fix all these sorts of problems. From my understanding, sshd, gdm and everything else that is actually important wouldn't wait for a windows partition to be mounted under systemd.

Some questions that do 3d6 fire damage

nix — Fri, 03 Sep 2010 18:21:36 +0000

you can't require that lennart (or whoever wants to move things forward) stays backwards compatible with each and every use case in existance.

The scary thing about pulseaudio is that modulo broken hardware, broken kernels (both alas common), or people doing things that just can't be virtualized in userspace (there are a few such with OSS and they break with aoss too, only ALSA's in-kernel OSS emulation helps), pulseaudio really does support almost everything. If there's a network protocol out there used for sound servers in more than a handful of boxes, PA seems to support it, and it's sufficiently modular that adding more is pretty easy.

Systemd and Fedora 14

nix — Fri, 03 Sep 2010 18:09:38 +0000

Uh, nothing I said stated that programs that are meant to be run by sysadmins should *not* reside in sbin/. a->b -/> b->a, y'know.

Systemd and Fedora 14

nix — Fri, 03 Sep 2010 18:05:53 +0000

What? No, /usr was where the second 20Mb hard disk was added. :)

Please...(again)...

mpr22 — Fri, 03 Sep 2010 15:03:34 +0000

My gut reaction is that some parts of the system are so "core" that if you don't trust a candidate for one of those parts enough to make it the default, you shouldn't even make it a conveniently visible option in anything you're going to call a "release".

PID 1 is one of those parts.

Systemd and Fedora 14

ABCD — Thu, 02 Sep 2010 18:42:22 +0000

If /bin is on a separate filesystem from /, then you wouldn't even be able to mount /bin because you wouldn't have a /bin/mount program that could mount it.

From a footnote in the latest FHS: Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path.

Systemd and Fedora 14

robbe — Thu, 02 Sep 2010 12:05:53 +0000

I assume you are confounding that with the /$d vs. /usr/$d (for values of d in {lib, bin, sbin, ...}) distinction. A system is expected to be able to boot into a more-or-less usable mode without /usr.

Except for embedded systems I don't have access to any machine that would be able to boot without /bin. For example, all shells are located there.

Systemd and Fedora 14

Randakar — Thu, 02 Sep 2010 09:35:22 +0000

Actually putting the symlink in /sbin IS worse than putting it in /bin.

/sbin is intended to be the place where crucial system utilities live that always should be available, AFAIK. When this distinction was made in the (distant) past the idea was that /bin could live on a different filesystem from root. /sbin would contain everything one might need before /bin could get mounted.

Putting systemd in /bin breaks that idea rather thoroughly. Why have the distinction between the two places at all if the init system doesn't live in /sbin?

Systemd and Fedora 14

renox — Thu, 02 Sep 2010 08:29:06 +0000

>> Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time.
> That argument is already barely sustainable for upstream kernels, and it's nonsense for a distribution.

Depends on the distribution!
Fedora's mission is this: "The Fedora Project is out front for you, leading the advancement of free, open software and content."

"Leading the advancement of [cut] software" are nice "marketing" word for "bleeding edge", what is right for a distribution aimed at "non-technical users" or enterprise isn't necessarily right for a "bleeding edge" distribution..

Note that I'm not saying this as a criticism against Fedora, we need "bleeding edge" distributions to make rapid progress, and I applaud them to take (calculated) risks.
Now Ubuntu's early use of PulseAudio, the KDE4.0 mess, etc, on the other hand *sigh*..

Please...(again)...

filteredperception — Thu, 02 Sep 2010 03:22:17 +0000

> I would really like to get back to a place where we can discuss the technical issues without applying terms like "Mr. A**hat" to somebody who has contributed large amounts of code to our community (or to anybody else, for that matter). Can we agree that would make LWN a more pleasant and focused place for all of us?

As someone who succumbed to PA bug rage on bugzilla, I feel a 100+ comment article is a pretty good place to add an extra apology. But you have to understand, that the bug in question, literally involved *painful*, possibly health-damaging audio making its way to my earbuds for the portion of a second it took my brain to rip the things out of my ears. Until that experience, it had never entered my mind that a distro bug was literally a health hazard. In fact, since my bug-rage-rant, I've come to the believe that the intel sound hardware, or perhaps even the sony earbud hardware, are at fault for allowing a software bug to be potentially seriously health damaging. But as many have mentioned, I ran into LP's rather dismissive attitude, which really, in that reactionary timeperiod, rubbed me the wrong way.

I don't even recall how PA was pushed onto fedora, but if there was any way it could have been done, that it could have reduced the number of people whose audio hit __400%__ due to a rhythmbox/pa-flat-volumes bug _instantaneously_, then it really, really, IMHO would have been worth it.

And I have to admit just a little bit of flaring anger at the (ad hominem attack redacted) idea that systemd should be default on in the first release of fedora that it lands in. _Especially_ when it is as easy to leave default off, but turn on as described in this article. I mean, we are talking about such a core piece of the distro infrastructure. Something that decades upon decades of sysadmins have painstakingly all familiarized themselves with. I mean, <seth and amy voice>Really?!?</>, you can't phase it in as default off for one release? <>Really?!?</>.

Honestly I am precisely one of those people being driven away from fedora. I like my bleeding edge stuff, but after suffering the last several releases, I can not tell you how much I look forward to CentOS6, and just saying- go ahead fedora folks, have all the crazy fun you want, just without me, I'll catch up with you in a decade when CentOS7 comes out.

Anyway, I wish systemd the best of luck, and just hope RH facilites COS6 in a timely enough manner that I don't have to touch it for many many years, because it's not solving any problem I knew I had.

Some questions that do 3d6 fire damage

aquasync — Tue, 31 Aug 2010 14:59:38 +0000

It would be very cool to have a system-wide dsp! Hope something similar makes it in to pulse audio one day.

Systemd and Fedora 14

salimma — Mon, 30 Aug 2010 15:11:32 +0000

I believe Kamilion was describing setting up the remote CUPS instance itself.

Please...(again)...

cmccabe — Sun, 29 Aug 2010 07:31:30 +0000

> I would disagree that the current scripts are inferior. People in our
> field are far to quick to dismiss the value of simplicity. systemd has
> several more features, I'll certainly admit that. The older / current
> method was great though. You'd think there was other lower hanging fruit
> that required attention.

I don't think systemV init scripts are really simpler. They just push the complexity into other parts of the system.

Since they can't represent dependency information, you either have to have a slow boot time or parallelize things by hand. I have had to manually parallelize sysV scripts before, and it's not fun. The system should know what depends on what.

Since sysV init scripts only happen at boot time, or when someone changes the runlevel, you have to have a separate mechanism to handle the addition of hardware at runtime. Sometimes adding that hardware requires starting a daemon-- for example, when it's bluetooth hardware.

SystemD also subsumes portreserve and xinetd. In theory systemD could also handle restarting daemons, although I don't know if that has been implemented yet.

Systemd and Fedora 14

Blaisorblade — Sat, 28 Aug 2010 00:12:43 +0000

> To test it, it has to go out to users (sure, at first just die-hard masochists, but soon after you need to reach out to the others).

Hey, it's cool, but until the bug stream doesn't slow down, there's no chance that you can include it in a distribution. Not even in one as crappy as Fedora. We've suffered this style ever since RH 9's (IIRC) backport of NPTL.

> Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time.
That argument is already barely sustainable for upstream kernels, and it's nonsense for a distribution.

Yes, at some point there won't be new bugs reported. Then it means you can end the beta-test phase, set up more stress-testing, get more packages to work with it, ship it, and fix the tons of bugs reports.
Of course, I mean that first systemd should have a alpha-beta-stable set of releases, and then a distribution should test integration (over more than 6 months). Which means that Lennart's thinking in this mail [1] is broken.
I mean, yes, it's optional in the current Fedora, but it's not yet ready. Finish it, declare it bug-free, ship it as optional, and then watch testers report tons of bugs - because those testers are simply more masochistic machos with crazy configurations that you have to support.

> And that is bad for developer morale (and focus), and probably damages the whole effort.

Hey, that's crap. If developers can't wait six months to replace the core component of a system, they should be fired. Now. Because they wouldn't be able to deal with much harder problems. I guess it does not matter, because it's just your idea.
I'm more concerned about concerns expressed in the article, like "Poettering has something of a reputation for waving away bugs as features" or the handling of noauto - I see the technical point in changing its handling, but I very much see that 99% of the users using noauto use it for good reasons which can go beyond boot-up time, and do so consciously, so changing the interpretation of noauto really questions the sanity of the developer. (Readers of The Art of Unix Programming from Raymond will also notice that choosing for users is very much against the Unix spirit in general, for the reasons I just discussed).

Finally, reading one of the original Nottingham's comments linked from the article [2] is enlightening. He's teaching release management to Poettering. Which means that I don't trust him to care for a distribution. Sure, he's a great and brilliant developer, able to think different, but those guys are not good for ensuring stability.

[1] http://lwn.net/Articles/401901/
[2] http://lwn.net/Articles/401921/

Some questions that do 3d6 fire damage

alankila — Fri, 27 Aug 2010 20:37:45 +0000

Lennart, I would like to add some audio DSP capabilities to PulseAudio. I might want a bit of input about that -- I tried sending you an email with some rubbish I had made a month or two ago, but you never responded.

I have since implemented this stuff into Android, and it's about to go live in CyanogenMod 6 that is going to be released, like, tonight. I'd like to see this code also on the Linux desktop. For reference, here's the application I built for Android:

http://bel.fi/~alankila/android-dsp/

I'd specifically need a few pointers about the good way to design this. I'm thinking about making a module that can be loaded into PulseAudio and which listens to dbus for configuration, and something like gnome-volume-control or such application could provide the GUI for settings and send these events over the dbus when it starts up. This would be a close equivalent to how I implemented it on Android.

Systemd and Fedora 14

cdmiller — Fri, 27 Aug 2010 20:11:10 +0000

One question that comes to mind, how easy is it to fix when something is broken? Just went through this with upstart/plymouth startup on upgraded Ubuntu Lucid servers. It was not well documented how to restore boot time messages and logs to chase down boot problems, or set up a text console rather than frame buffer mode.

With systemd starting everything "at once", "as touched", how tough is it to trouble shoot or gracefully error out when something doesn't work or untested configurations crops up?

Systemd and Fedora 14

cdmiller — Fri, 27 Aug 2010 19:51:14 +0000

Perhaps it should be renamed Userd.

Sorry couldn't help myself with all the flaming and angst :)

Systemd and Fedora 14

sorpigal — Fri, 27 Aug 2010 17:48:56 +0000

Not all distros change quicky. This is where Debian's turtle-like pace shines. It's already too late to put systemd in the next stable and by the time that the one after that comes along systemd will be mature and accepted or well-debunked by faster moving distros.

with pulse, it's silent; without sound works

Trelane — Fri, 27 Aug 2010 17:12:41 +0000

It should perhaps also be mentioned that "codec" is a specific bit of jargon specific to the HDA spec (available on the intarwebs; this is how I know about these things, although it's been a while and I'd greatly appreciate supplements/corrections where appropriate).

The HDA spec has a tree structure, and one of the nodes is a "codec," referring to a virtualized interface to a block that Does Stuff. This is used to interesting effect with the sound card discussed at http://blogs.amd.com/home/2009/06/16/turning-it-up-to-11/, where the HDA protocol itself is used as a transport/formalization of a higher-level protocol used to drive a particularly novel consumer-level sound card.

IIRC. It's been a bit since I read the specs on this card and therefore also the HDA specs to understand Intel HDA as it was being used here. (Sadly, I never got enough hand-holding to get a driver up and running on ALSA and perhaps also lacked the motivation, not actually having hardware to play/test with.)

Systemd and Fedora 14

gidoca — Fri, 27 Aug 2010 15:02:27 +0000

I don't know about other DEs, but on KDE, you don't need to have CUPS running on your local machine to support printing on a remote machine or network printer, given that it supports IPP and Zeroconf. It will automatically detect the remote CUPS instance and show it in the print dialog, without accessing the local print server.

Please...(again)...

rahulsundaram — Fri, 27 Aug 2010 14:10:56 +0000

And what is the proposed solution here? As long as you are not paying people to work on what you want, it is always going to be a distributed set of components with no central design or authority. It is sort of like evolution, messy and inefficient but noone else has proposed a better way to tackle it without throwing away a lot of money on something that might not pay dividends even years later.

Please...(again)...

mmcgrath — Fri, 27 Aug 2010 14:00:29 +0000

> Much of what you use on a regular basis was designed in the same way driven by self interest and tackling problems they are interested in.

I agree, and relative quality difference compared to what is available around it has grown wider and wider. The Linux desktop is a wasteland of disjointed features and applications that only sort of work together written by groups that have far more reach then manpower and no central design other then freedom. We've made almost no headway on the desktop in the last _10_ years. We're still sitting at 1%. I'm tired of playing this tune, I need to just accept that.

But now I'm seeing these crazy disjointed desktop bits make their way into core system parts (note: NetworkManager didn't replace network scripts for a reason in RHEL6). So now I worry that where we have made great headway (on the server) is now being put at risk by these silly disjointed 'features'.

Please...(again)...

rahulsundaram — Fri, 27 Aug 2010 13:51:29 +0000

I don't see what you are talking about. Much of what you use on a regular basis was designed in the same way driven by self interest and tackling problems they are interested in. It might not be some low hanging fruit that you want to tackle but obviously different people have different interests. If you want to tackle a different problem, go ahead and do that.

Please...(again)...

mmcgrath — Fri, 27 Aug 2010 13:48:21 +0000

I can't think of a worse way to design a system whole then what you just described. That's why I complain.

Please...(again)...

rahulsundaram — Fri, 27 Aug 2010 13:30:34 +0000

Obviously, people work on what catches their attention. For a hobbyist project, we can't expect anything more. Why complain about that?

Please...(again)...

mmcgrath — Fri, 27 Aug 2010 13:20:58 +0000

> ... especially when you replace something inferior, but core and WORKING.

I would disagree that the current scripts are inferior. People in our field are far to quick to dismiss the value of simplicity. systemd has several more features, I'll certainly admit that. The older / current method was great though. You'd think there was other lower hanging fruit that required attention.

Please...(again)...

mpr22 — Fri, 27 Aug 2010 12:59:09 +0000

I would say that "work, just" is more accurate than "just work".

Please...(again)...

marcH — Fri, 27 Aug 2010 10:46:14 +0000

> As you can probably guess, handling transition issues is *not* the fun part. It's the boring but difficult part. [..] But you absolutely must not do this, or else you will make a lot of enemies.

... especially when you replace something inferior, but core and WORKING. You can take whatever risks you want with brand new features, but regressions? Never, ever. Even if you put an extraordinary amount of effort in implementing the best piece of software ever, people will hate you for the tiniest regressions. And you deserve it. Divas seem to forget too easily that normal people have a day job: make the system JUST WORK whatever it takes and no matter how ugly it is in the end.

PS: yeah I know, I should use RedHat. You can save your post.