[Bug 2035061] Re: uptime -p reports incorrect output after 52 weeks

[Robert Malz]

History is a little bit tricky, patch hhttps://gitlab.com/procps-ng/procps/-/commit/8827c6763f79f77a126968e200b0e402de7cb749 (applied in current debdiff) was merged to the master branch but probably was lost while repository was moving to a "newlib".
Last released version https://gitlab.com/procps-ng/procps/-/tags/v3.3.17 did not have this patch applied.
Next release version https://gitlab.com/procps-ng/procps/-/tags/v4.0.0 was based on refactored code.

With newlib as master this commit has been applied with some modifications in https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374
Looking at that function there is one more change applied to it https://gitlab.com/procps-ng/procps/-/commit/f08082093192b7d93f28517ffc5298172d182a1e which fixes and issue caused by previous modifications.
Differences in both patches are fairly small and affects upminutes/uphours calculation.
However after closer look (and writing some tests to check corner cases) there is one additional bug with updays and uphours calculation in proposed patch.
If there is exactly 60*60*24 (24h) input, updays will be equal to 0 and uphours will be 24%24 -> 0 which is a regression.

Having said that I would not recommend going forward with current proposed patch, another option is to backport https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374.
However because base code has been modified this patch will not apply on 3.3.16/17 and needs some tweaks.
I already started working on that and output looks promising. There is still 1 issue with exactly 60s of uptime but it comes from the upstream (I have already created an issue in upstream gitlab repo).

Attaching testing results "uptime_test_results".

I'll work on providing new debdiffs and keep improving Bug Description.

** Attachment added: "uptime_test_results"
   https://bugs.launchpad.net/ubuntu/+source/procps/+bug/2035061/+attachment/5700926/+files/uptime_test_results

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/2035061

Title:
  uptime -p reports incorrect output after 52 weeks

Status in procps package in Ubuntu:
  New
Status in procps source package in Focal:
  New
Status in procps source package in Jammy:
  New

Bug description:
  [IMPACT]

  uptime will provide incorrect data after 52 weeks. This is at least confusing for users utilizing this tool.
  Issue is already fixed in upstream https://gitlab.com/procps-ng/procps/-/commit/8827c6763f79f77a126968e200b0e402de7cb749.
  Latest procps releases already include this patch (procps 4.0.3 lunar/mantic)
  The fix is needed for following set of packages:
  procps | 2:3.3.17-6ubuntu2   | jammy
  procps | 2:3.3.16-1ubuntu2   | focal

  [TEST CASE]

  UPTIME="31528920 31528800"; mkfifo uptime_fifo; while true; do cat <<<$UPTIME > uptime_fifo; done & sudo mount -obind uptime_fifo /proc/uptime
  uptime -p
  Running above commands will result in incorrect uptime output.

  [REGRESSION POTENTIAL]

  The patch is already available in upstream, lunar/mantic releases already include is as well.
  Old behavior will inaccurately print uptime -p for 24h after 31449600 seconds (0 years, 0 weeks).
  With new patch during that time uptime -p will print "52 weeks".

  [OTHER]
  Bug upstream: https://gitlab.com/procps-ng/procps/-/issues/217
  Following patch is needed for older releases: https://gitlab.com/procps-ng/procps/-/commit/8827c6763f79f77a126968e200b0e402de7cb749

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/2035061/+subscriptions