Last modified: 2013-11-15 16:46:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T59105, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 57105 - jsub fails when starting php scripts
jsub fails when starting php scripts
Status: RESOLVED INVALID
Product: Wikimedia Labs
Classification: Unclassified
tools (Other open bugs)
unspecified
All All
: Unprioritized major
: ---
Assigned To: Marc A. Pelletier
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-15 13:40 UTC by Christian Thiele
Modified: 2013-11-15 16:46 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Christian Thiele 2013-11-15 13:40:19 UTC
I'm not able to commit jobs to the grid engine. That's what I'm doing:

Simple php script (test.php):

<?
  print "Test";
?>

Running "php test.php" on tools-login works as expected. Then I try it using the grid engine:

> jsub -N test php test.php

(and I tried it with full path to test.php, too)

The job is successfully queued; the .err and .out files are created. The job is then executed.

The result is: test.out is empty and test.err gives the following error message:

libgcc_s.so.1 must be installed for pthread_cancel to work
Comment 1 Liangent 2013-11-15 13:42:48 UTC
Set a bigger -mem (memory limit) and it works.
Comment 3 Marc A. Pelletier 2013-11-15 15:35:05 UTC
Sadly, while the completely opaque error message is a known issue, it is also quite outside our ability to fix (as it is generated by the dynamic loader itself).

Short of warning people in advance as we did with the FAQ, there is nothing that can be done.
Comment 4 Christian Thiele 2013-11-15 15:37:54 UTC
Thanks to all. I didn't thought about searching such an error in the FAQ, sorry.
Comment 5 Liangent 2013-11-15 16:19:17 UTC
(In reply to comment #3)
> Sadly, while the completely opaque error message is a known issue, it is also
> quite outside our ability to fix (as it is generated by the dynamic loader
> itself).
> 
> Short of warning people in advance as we did with the FAQ, there is nothing
> that can be done.

Does it help if we increase the default memory limit value?
Comment 6 Marc A. Pelletier 2013-11-15 16:46:52 UTC
The problem is that there is no default value big enough to cover all the common cases yet reasonably frugal enough that we won't have a severe under commitment of resources.

Right now, things have been tweaked so that the default value (250m) matches processor availability - any smaller wouldn't get more jobs running anyways.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links