bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

[zimoun]

Hi,

From 8a87e29, I get:


--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=9d795fb -- help
Backtrace:
          14 (primitive-load "/home/sitour/.config/guix/current/bin/…")
In guix/ui.scm:
   2229:7 13 (run-guix . _)
  2192:10 12 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
  1747:15 10 (with-exception-handler #<procedure 7f1459d16b40 at ic…> …)
In guix/store.scm:
    671:3  9 (_)
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   658:37  7 (thunk)
In guix/status.scm:
    809:4  6 (call-with-status-report _ _)
In guix/store.scm:
   1320:8  5 (call-with-build-handler #<procedure 7f1459e534b0 at g…> …)
In guix/inferior.scm:
    885:2  4 (cached-channel-instance #<store-connection 256.99 7f1…> …)
In guix/cache.scm:
    39:10  3 (maybe-remove-expired-cache-entries "/home/sitour/.cac…" …)
In srfi/srfi-19.scm:
   287:16  2 (time-normalize! #<time type: time-monotonic nanosecond…>)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure <: Wrong type argument in position 2: #<eof>
--8<---------------cut here---------------end--------------->8---

Then ~/.cache/guix/inferiors/last-expiry-cleanup is empty

--8<---------------cut here---------------start------------->8---
$ cat ~/.cache/guix/inferiors/last-expiry-cleanup 

--8<---------------cut here---------------end--------------->8---

probably erased by the previous time-machine call.  Well, it still fails
until I remove the file ~/.cache/guix/inferiors/last-expiry-cleanup.

It is hard to debug.  Any idea?


Cheers,
simon

bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> In guix/cache.scm:
>     39:10  3 (maybe-remove-expired-cache-entries "/home/sitour/.cac…" …)
> In srfi/srfi-19.scm:
>    287:16  2 (time-normalize! #<time type: time-monotonic nanosecond…>)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure <: Wrong type argument in position 2: #<eof>
>
>
> Then ~/.cache/guix/inferiors/last-expiry-cleanup is empty
>
> $ cat ~/.cache/guix/inferiors/last-expiry-cleanup 

This file was empty when you ran the command instead of containing an
integer (could have been a file system corruption or something like
that).

Solution:

  rm ~/.cache/guix/inferiors/last-expiry-cleanup

HTH!

Ludo’.

bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Ludovic Courtès schreef op do 26-05-2022 om 17:05 [+0200]:
> This file was empty when you ran the command instead of containing an
> integer (could have been a file system corruption or something like
> that).
> 
> Solution:
> 
>   rm ~/.cache/guix/inferiors/last-expiry-cleanup

It's a work-around, but there's still an underlying problem: 
guix/cache.scm doesn't do 'fsync+rename', so the file is not created
atomically, so in case of an abrupt shutdown or C-c at the wrong time,
the file becomes corrupted without fault of the file system.

As such, WDYT of making last-expiry-date more robust, by treating
invalid contents as time=0 or something like that?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

[zimoun]

Hi,

On Thu, 26 May 2022 at 17:05, Ludovic Courtès <ludo@gnu.org> wrote:

> This file was empty when you ran the command instead of containing an
> integer (could have been a file system corruption or something like
> that).

No, I did nothing special and the file system is not corrupted. :-)

I am just using intensively "guix time-machine".


> Solution:
>
>   rm ~/.cache/guix/inferiors/last-expiry-cleanup

Yes, this is what I did because I know enough the internals.

As Maxime said, it should be robust.  Therefore, see the fix:

https://issues.guix.gnu.org/55673


Cheers,
simon

bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

[Ludovic Courtès]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> It's a work-around, but there's still an underlying problem: 
> guix/cache.scm doesn't do 'fsync+rename', so the file is not created
> atomically, so in case of an abrupt shutdown or C-c at the wrong time,
> the file becomes corrupted without fault of the file system.

Right, I guess this is what we should fix first, by using
‘with-atomic-file-output’ for instance.

> As such, WDYT of making last-expiry-date more robust, by treating
> invalid contents as time=0 or something like that?

That too.

Ludo’.

bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

[zimoun]

Hi,

On Sat, 28 May 2022 at 19:12, Ludovic Courtès <ludo@gnu.org> wrote:

> Right, I guess this is what we should fix first, by using
> ‘with-atomic-file-output’ for instance.

Please give a look at the patch

https://issues.guix.gnu.org/55673#18

which fixes the issue.


Cheers,
simon