Don't Use Fedora's Fedup Right Now Due To A Bug With Systemd

[Mehak50]

A girl with the right face shape would look hot in a fedora. but i'd recommend the modern interpretation, instead of the actual 40s version.

[watchbeans]

Bugs are expected, Better be ready.

[AdamW]

Systemd 217 has a slightly different implementation of the feature with the same defaults and the same fundamental design flaw where long-running units have no way to override the startup timer.

Yeah, it is re-implemented in 217. The 'startup timer' is actually on basic.target, and it's arguably reasonable to suggest that 'long-running units' shouldn't happen before basic.target is run. One of the changes we eventually implemented to deal with this problem was a change to fedup that caused the old version of the timeout code to not consider startup to be 'blocked' by fedup's package installation stage, though I'd have to run a test to see if the change holds with systemd-217. See http://pkgs.fedoraproject.org/cgit/f...3a5a855ad269d9 .

[Luke]

The only way systemd can frack

We are fed up with this fracking systemd

Fortunately, the only way systemd can frack something is if gas frackers use modern Linux distros in the computers that control their equipment. I REALLY would not want my computer to dispense flammable drinking water from every faucet in my house, nor to blow me up in the shower with gas bubbling from the water until it reached the light switch...

[makomk]

No, they're not. What will happen is udev will switch to kdbus. Totally different thing. Sure on a systemd system it'll be systemd's job to set up kdbus policies. But there's nothing preventing someone to write a non-systemd method to set up kdbus, thus allowing the kdbus-enabled udev to run without systemd.

They could, but it would have to have almost exactly the same architecture as systemd. If I'm following the code and documentation correctly the system kdbus bus would have to be created and managed by PID 1. The kernel requires bus names to start with the PID of the process that created them, and the name of the system bus is hardcoded in applications. So basically you'd have to replace init with something that knew how to set up kdbus, and that something would probably have to be tightly integrated with service management in order to fulfil its manager role. The only non-systemd-based distro I'm aware of that's designed that way is Ubuntu, which is moving to systemd anyway - everything else decouples PID 1 from service management.

About KDE, Kwin will require logind on wayland. *logind*, not systemd. More info here. So, similar to above, using Kwin/wayland without systemd will require that someone writes an alternative logind implementation. Or use logind with Debian's systemd-shim.

It's not feasible to reimplement logind or use it independently of systemd - even the systemd developers don't think it can be done. It should be obvious why if you take a look at the API documentation for it.

The feature never went into a systemd release; F21's systemd package follows the upstream 216-stable branch quite rapidly, which is why it got this change.

Systemd 217 has a slightly different implementation of the feature with the same defaults and the same fundamental design flaw where long-running units have no way to override the startup timer.

[AdamW]

No, it will not. Linux kernel has thermal checks for this exact reason and when your CPU overheats, it throttles at first and at some point it will shut everything down (wheather fedora is updating or not).
If you take a look at your kernel log sometimes, you can see such warnings in kernel log:

[137547.968129] CPU2: Package temperature/speed normal
[137547.968130] CPU0: Package temperature/speed normal
[137548.124277] CPU2: Core temperature above threshold, cpu clock throttled (total events = 16455155)
[137548.124280] CPU3: Core temperature above threshold, cpu clock throttled (total events = 16455154)
[137548.125289] CPU2: Core temperature/speed normal
[137548.125291] CPU3: Core temperature/speed normal
[137847.287143] CPU2: Package temperature above threshold, cpu clock throttled (total events = 17888019)
[137847.287147] CPU3: Package temperature above threshold, cpu clock throttled (total events = 17888017)

This will slow down your CPU and also prevent it from frying.

That's not a pure kernel/software feature, it works together with the firmware (and ultimately the CPU and motherboard hardware). The firmware has to specify the cutoffs and provide the actual temperature monitoring.

The feature was actually first introduced by Intel. AMD dragged their feet for a bit, until Tom's Hardware posted a rather infamous (in its day) video. The original Tom's article seems to be gone, sadly, but there's a couple of copies of the video on Youtube - http://www.youtube.com/watch?v=NxNUK3U73SI is one. AMD introduced the feature to Athlon XPs rather soon after that article was posted...=)

[AdamW]

According to the systemd changelog, this option is configurable. You can enable/disable it or change the timeout duration PER UNIT FILE! .. So can we really say that this is a systemd bug and not carelessness by fedora/Fedup devs?

The person who maintains the Fedora package is a systemd upstream developer, so apart from anything else, the distinction is fairly academic...

[AdamW]

Not exactly 'Fedora 21's systemd'

I'd phrase this bit a little differently:

"Fedora 21's systemd has a feature of timing out the system startup if it's not complete after 15 minutes of booting."

It's not quite 'Fedora 21's systemd' but the exact systemd build that got baked into Beta. Unfortunately this particular feature got put into systemd-216-2.fc21, and Beta wound up with 216-5. The feature clearly needed a rethink and has already been dropped upstream, and won't be in Fedora 21 Final in its current form, but it's now baked into the frozen Beta package set and that can't be changed.

It's unlikely to cause problems with anything other than fedup, and we're pretty far along in making sure no-one else gets bitten by the fedup case.

systemd-216-8.fc21 - which is currently in the process of going into F21 stable - has the feature reverted.

The feature never went into a systemd release; F21's systemd package follows the upstream 216-stable branch quite rapidly, which is why it got this change.

[MoonMoon]

(and systemd-haters have every right to complain about their decision).

They are entitled to have their own opinion, but unless they actively contribute to change what they don't like their only option is to demand their money back and buy a different product.
Oh, wait...

[Gusar]

1) Some users don't want/can't (policy at workplace/school... etc) use systemd.

Then it's up to those policy makers to make sure the systems they manage work as they should. Either by devising workarounds, or by careful selection of software, or whatever other means.

2) Projects who make their stuff _rely_ on systemd feature, know what they signed up for and that they will lose some users

Sure. The point is, it's *their* decision, because they're the ones doing the development.

(and systemd-haters have every right to complain about their decision).

They do. The problems is that these complaints are far too often vague stuff without much substance, misunderstandings or exaggerations, and the most annoying one - inane conspiracy theories, coming from people who haven't invested much time to learn how systemd works and what it brings to the table and why upstreams are choosing it. Real, technical objections are far and few between. So the complaints aren't much more than noise, with no chance to change upstream's behavior regarding their use of systemd interfaces.

3) Developers can do whatever they want in open source world (unless they work for _some_company_ which ultimately controlls some OSS projects).

Tell that to some of the complainers, who are sometimes downright demanding how software (that they are not writing) should be written.

x) "anit-systemd proponents" -- really??? I mean.. I don't usually pick on grammar, but... srsly?

Ever heard of a typo? You should've stuck to your policy of not picking on grammar, because this is jsut beyond silly. (note, this time I've spotted the typo before hitting "Submit Reply", but I'm gonna leave it there anyway )