李建 wrote:
Now ,the directory is:
-----------------------------------------
[r...@localhost mock]# du -hs *
651M gtes11.2-build-10-9
18M gtes11.2-build-13-10
5.6M gtes11.2-build-15-15
549M gtes11.2-build-1-6
5.5M gtes11.2-build-16-15
18M gtes11.2-build-18-18
18M gtes11.2-build-19-18
Due to a potentially dangerous bug in rpmlib [1], kojid removes the
mockdir directories in two stages.
First the buildroot (e.g. gtes11.2-build-16-15/root)is cleared of
content, but the directory itself (as well the mock results dir)
remains. This clearing occurs almost immediately after most builds, but
is delayed four hours for failed builds.
After 24 hours, the entire mock directory for the chroot is removed.
This allows any stray rpm transactions plenty of time to exit. This may
seem like an extreme wait, but the consequences of triggering the rpm
bug are very, very bad.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=192153
It appears that at least some of these directories (e.g. the 18M ones)
are still in that 24 hour wait. As for the others, I cannot be sure from
this small amount of data.
...
Why ? Because I use a special disk space,and I use Selinux, So I modified
the /var/lib/mock to /dist/mock on kojihub and kojiweb and kojibuilder3
host. but the kojibuilder2's mock directory is /var/lib/mock ,a link to
/dist/mock on it's host.
the kojihub and kojiweb and kojibuilder3's /mnt/koji directory is modified
to /data/koji also . but the other kojibuilder*'s directory is /mnt/koji by
nfs mount.
Why ? It isn't change or removed after 1 days.
As pointed out above, it is normal for koji's mock directories to
survive (in a stripped form) for up to 24 hours. If the problem
persists, I recommend cranking up the debugging on kojid and watching
the logs (look for lines containing rootdir or buildroot).
--
Fedora-buildsys-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
