CLOCK_MONOTONIC change reverted [LWN.net]

CLOCK_MONOTONIC change reverted

Posted Apr 26, 2018 12:22 UTC (Thu) by judas_iscariote (guest, #47386)
Parent article: CLOCK_MONOTONIC change reverted

Was a bug report filled at the systemd issue tracker.. ? if not please do so explaining exactly what relies on the incorrect old behaviour ! . I'm certain that everybody wants this new CLOCK_MONOTONIC sane behaviour.

to post comments

CLOCK_MONOTONIC change reverted

Posted Apr 26, 2018 13:02 UTC (Thu) by tglx (subscriber, #31301) [Link] (1 responses)

Well, even if we file a bug and stuff eventually gets fixed, the change will break existing user space and probably more than just systemd and network mangler. It was expected and it might have been possible to fix this ahead of time, but the only option 4 weeks before the final 4.17 release is to revert it.

CLOCK_MONOTONIC change reverted

Posted Apr 27, 2018 14:48 UTC (Fri) by eternaleye (guest, #67051) [Link]

To be honest, what confused me most here was the approach taken to making the change. If a behavior is as useful and widely-documented as CLOCK_BOOTTIME vs. CLOCK_MONOTONIC is (and believe me, the _behavior_ distinction is very useful regardless of name), why was doing a straight renaming in one shot _ever_ considered?

When a behavior's name is suboptimal, there's a pretty well established way of fixing that - introduce a new name, deprecate the old name, and have a deprecation cycle.

1. Add CLOCK_MONOTONIC_ACTIVE as an alias for CLOCK_MONOTONIC, deprecating CLOCK_MONOTONIC (maybe add #warning)
2. Add an #ifdef that people can set to switch (deprecated) CLOCK_MONOTONIC = CLOCK_MONOTONIC_ACTIVE to (new) CLOCK_MONOTONIC = CLOCK_BOOTTIME
3. Flip the default ifdef, after waiting long enough
4. Deprecate CLOCK_BOOTTIME (maybe add #warning)
5. Remove CLOCK_BOOTTIME, after waiting long enough
6. Remove the #ifdef, after waiting long enough (this is last because previous stages _introduce_ errors or at least warnings, while this would cause build-silent misbehavior, as was seen with the current patch)

I cannot think of a reason that "just change it" was considered viable for public, documented API and ABI?

CLOCK_MONOTONIC change reverted

Posted Apr 26, 2018 13:32 UTC (Thu) by zuki (subscriber, #41808) [Link]

The effect was reported as "If you suspend >3min, then after a resume systemd watchdog timers all fire.".

CLOCK_MONOTONIC change reverted

Posted May 3, 2018 5:15 UTC (Thu) by smckay (guest, #103253) [Link] (1 responses)

In what sense is the old behavior incorrect? It matches the documentation and is monotonic. The new behavior is monotonic but doesn't match the documentation. That sounds less correct than before, to me.

CLOCK_MONOTONIC change reverted

Posted May 14, 2018 12:29 UTC (Mon) by sourcejedi (guest, #45153) [Link]

See e.g. Why is there a Linux kernel policy to never break user space?

Specifically also, we really want people to be testing new upstream kernels and reporting regressions. (That's probably not a very compelling activity on its own, but there are more positive reasons people play with running upstream kernels as well. For example, hoping it fixes a regression introduced in the previous version :). They will be much less willing to test and report, if we're deliberately breaking their system.

Making a change which kills logind on any suspend over 3 minutes, which then kills X / gnome-shell, definitely counts as breakage :-).

AFAIK this change also breaks rtkit, for example.

Here's another error you get if you suspend the host that's running a VM (as I mentioned on the previous LWN.net article, this causes the same problem, due to a bug somewhere in qemu/KVM):

rtkit-daemon[1218]: The canary thread is apparently starving. Taking action.
rtkit-daemon[1218]: Demoting known real-time threads.
rtkit-daemon[1218]: Demoted 0 threads.