https://bugzilla.wikimedia.org/show_bug.cgi?id=47534
--- Comment #19 from Bawolff (Brian Wolff) <[email protected]> --- >btw, I believe ghostscript error code 9 is for invalid file access. Actually nevermind, in guile, if you kill a subprocess executed with the (system) command, the return status is the signal that killed it, so in this case SIGKILL (signal 9), which is what would happen if ghostscript exceeded resource limits when using cgroups. (Internally ghostscript also uses 9 to mean invalid file access I believe, but I don't think it actually uses that as a return code) Which brings up the question of why is it only gs that is exceeding resource limits. I would expect it to be other parts of the rendering process as well. And specifically which limit is being exceeded. Is ghostscript really that expensive? [I don't have cgroups set up locally, but using ulimits, the process completes with much less memory then the limit is set to on wmf wikis] To further add mystery, on test.wikipedia.org, this issue does not happen. I occasionally got a return status from lilypond of 137 (128 + signal number 9 for bash signalling that it was killed, again presumably due to cgroups). In general though rendering succeeds. Which is odd, since even though test.wikipedia.org is not the same as a normal cluster wiki, afaik it has resource limits configured in the same way [Unless it is perhaps configured as an image scalar?] [As an aside this provides a very poor workaround, since once you get something rendered on test, it gets cached, and can be used on the other wikis] ----- In case its later useful, it can be determined what the precise gs command being executed by lilypond by addding -dverbose to the lilypond command line. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
