Comment # 10 on bug 1183711 from Fabian Vogt

(In reply to Fabian Vogt from comment #9)
> (In reply to Benjamin Zeller from comment #8)
> > A coredump file might help here though. 
> 
> https://w3.suse.de/~fvogt/boo1183711core.xz
> This time it didn't crash in libsolv, but the memory corruption caused a
> "stack level too deep" error in ruby and then it aborted in malloc_printerr.
> 
> > But depending on the state of libzypp, libsolv when the files are moved this
> > might indeed be a problem. If we have open fd's to the cache it would be
> > problematic, first the copied files might be garbage and second we'd still
> > continue to use the old files ( since the kernel will keep deletes files
> > around as long as a process has them opened ) or a mix of both.
> > 
> > Do you know in what stage that happens? 
> >
> > Not sure if libsolv keeps the cache files open, adding Michael Schr���der as
> > well.
> 
> Before copy and link:
> 
> lr-x------ 1 root root 64 M���r 31 10:05 27 ->
> /mnt/var/cache/zypp/solv/@System/solv
> lr-x------ 1 root root 64 M���r 31 10:00 28 ->
> /var/cache/zypp/solv/openSUSE-Leap-15.3-1_0/solv
> 
> After copy and link:
> 
> lr-x------ 1 root root 64 M���r 31 10:05 27 ->
> /mnt/var/cache/zypp/solv/@System/solv
> lr-x------ 1 root root 64 M���r 31 10:00 28 ->
> /var/cache/zypp/solv/openSUSE-Leap-15.3-1_0/solv (deleted)
> 
> So the 15.3 solv file got unlinked and @System/solv got overwritten!
> 
> Excluding @System from the copy prevents the crash. It might work to remove
> /mnt/var/cache/zypp/ before the copy, so that the open cache isn't modified.

Yep, that seems to work. I opened a PR:
https://github.com/yast/yast-packager/pull/561
Reassigning back to YaST.

> Or cp could be used with --remove-destination.

I chose the explicit removal as this avoids mixing local and destination
caches completely. If it's an issue that caches of other repos are also
cleared, then the cp switch could be used instead.