Closed strogdon closed 3 years ago
Hum... I think I know what lock we are talking about and I thought Jeroen had removed it after some other work I have done. May be it is not in 8.2.beta6, I'll have to dig.
No I am mistaken with the doctest forker. Has it appeared after the upgrade to MPL-2.1.0 or what it happening before?
It is definitely a parallel build issue that's likely needing to be dealt with upstream. How many threads/tasks?
This happened after the upgrade to 8.2.beta6
. So therefore MPL-2.1.0
was already there. However I noticed that I'm using a MPL-2.1.0
from my local overlay, but I don't see any potential parallel build changes between my local overlay matplotlib
and that in the main tree. I should upgrade. I have 12 threads here. The failure is fairly random and I haven't been able to get it to fail twice in a row.
I got this LOCKERROR
again, same Prefix, when building 8.3.beta7
. Restarting the build was then successful.
Actually, I get this LOCKERROR
on almost every rebuild of 8.3.beta7
in Prefix. This is new. When things fail I usually can continue building the html-docs by removing the matplotlib lock folder and then ebuild sage-9999 install
.
Hum, any zombie processes around?
Built with MAKEOPTS=-j10
instead of the usual MAKEOPTS=-j13
.
Is this still happening?
Occasionlly, yes. It is random, but rare.
Just for info, I haven't seen this LOCKERROR
in some time. I'm not sure when I stopped seeing it.
This has now appeared again building 8.9.beta8
. The procedure in the above comment was used to continue the build with the exception that the matplotlib lock folder was not removed. Apparently, removing it is not needed?
I am really clueless with regards to this issue. What kind of file systems do you have?
OS is debian and the file system doesn't appear to be odd
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 10M 0 10M 0% /dev
tmpfs tmpfs 3.2G 676K 3.2G 1% /run
/dev/mapper/blitzen-root ext4 427G 197G 208G 49% /
tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs tmpfs 6.3G 0 6.3G 0% /run/shm
/dev/sda2 ext2 229M 21M 197M 10% /boot
/dev/sda1 vfat 487M 128K 486M 1% /boot/efi
I'm wondering what is creating the lock folder since it doesn't appear to be used.
I'm wondering if https://github.com/matplotlib/matplotlib/pull/10596 may not be the solution. It appears to be in matplotlib 3.0. However, it was prompted by the lock folder associated with tex.cache. The lock folder here is not under the tex.cache folder
ls -al temp/matplotlib/
total 136
drwxr-xr-x 4 strogdon math 4096 Aug 26 14:58 .
drwxr-xr-x 5 strogdon math 4096 Aug 26 16:29 ..
drwxr-xr-x 2 strogdon math 4096 Aug 26 14:58 .matplotlib_lock-4729
-rw-r--r-- 1 strogdon math 121270 Aug 26 14:58 fontList.json
drwxr-xr-x 2 strogdon math 4096 Aug 26 14:58 tex.cache
so it may be different.
Interesting but it relies on python3 features. So no backporting. On the other hand we may very well just ditch python2 in sage-on-gentoo by the end of the year. I don't think it will stay for long in the main tree after support end at the end of the year.
I haven't see this issue in some time. However, the last time I noted this within days it appeared again. Perhaps, if this doesn't appear after the release of 9.1 it should be closed?
We'll probably have some problem by then. I currently cannot build the doc on the vbraun branch and I don't know why. The obvious culprit isn't.
Well, the obvious culprit was guilty in the end. Even if I don't know why.
Closing old.
This is just to document the issue since I've seen it several times. It occurs just as the docs are being built. Perhaps parallel build related.
The lock folder
And the referenced
sphinx-err-5Y7Dya.log