https://bugzilla.suse.com/show_bug.cgi?id=1183711
https://bugzilla.suse.com/show_bug.cgi?id=1183711#c10
Fabian Vogt
(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. -- You are receiving this mail because: You are on the CC list for the bug.