Last modified: 2013-08-01 09:55:00 UTC
We have a job that sanity-checks our API server, which is a primary part of our ability to communicate with the VisualEditor. It fails because the process forks off several workers to handle requests, which sets off big red blinking alarms in Jenkins. Do we need to add in an option to not fork? Do we need to add in some other method of doing this (like a "start a background process" Jenkins builder)? Or can we work around the file descriptor issue?
The job dashboard is https://integration.mediawiki.org/ci/view/All/job/parsoid-server-sanity-check/ An example console is https://integration.mediawiki.org/ci/view/All/job/parsoid-server-sanity-check/65/console After the worker have been forked, Jenkins detects some file descriptor leakage and cancel the build: Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information They point to http://software.clapper.org/daemonize/ . But maybe we can use /usr/bin/daemon for the same effect.
daemon seems to have broken it further, though I'm not sure why. I tried letting the server get set up, and I tried making sure my options were correct, but the parsoid server doesn't seem to like being run with daemon.
The tests seem to be working now. Has this been fixed or have certain testing paths been disabled? Is there something we can do on our end?
Yeah, we disabled it because there was no point in keeping it around. There's some hacky workaround, but it seemed really complicated and not worth the work at that time.
Job got deleted, I guess we can forget this bug for now.
