Closed (works as designed)
Project:
Drupal.org infrastructure
Component:
Other
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
6 Nov 2009 at 17:31 UTC
Updated:
12 Nov 2009 at 08:48 UTC
Trying to deploy new code to localize.drupal.org via merging from the vendor branch of l10n_server. Running d.o-cvs-to-svn.php l10n_server DRUPAL-6--1 with my up to date password attempts to run
svn_load_dirs.pl https://svn.drupal.org/drupal -no_user_input -t vendor/l10n_server/DRUPAL-6--1-200911061654 vendor/l10n_server/current l10n_server
which then says
/home/gabor/bin/svn_load_dirs.pl: caught signal PIPE. Quitting now.
on shell.d.o and says
Checking that the base URL is a Subversion repository.
Running /usr/bin/svn log -r HEAD --username ********* --password ****** https://svn.drupal.org/drupal
Finding the root URL of the Subversion repository.
Running /usr/bin/svn log -r HEAD --username ********* --password ****** https://svn.drupal.org
on my local machine (and never returns from after this last item, at least not in the past 30 min).
Is the mistake on my end? Both on my setup on shell.d.o and my local setup? How can we make this work? Since I cannot even pull in vendor code, I'm not at all near to merging that, comitting and then deploying on localize.drupal.org.
Comments
Comment #1
gábor hojtsyTo reproduce on shell.d.o:
This might still use an svn_load_dirs.pl from a different path, I have /home/gabor/bin on my path so the script would be picked for me from there obviously. You can alter your path or edit that d.o-cvs-to-svn.php script to look at the svn_load_dirs.pl script on my bin directory and not in your path. You should get the PIPE signal error after a while (and some other messages inbetween).
Comment #2
nnewton commentedHi Gabor,
I don't have much experience with the d.o-cvs-svn script, but the error we are hitting is that its using a huge amount of ram. As a test I raised the memory_limit to 900M and it still failed with a php fatal error caused by memory exhaustion. Any thoughts on why it would be using so much for this?
(Note: There is also an entry in the apache error log saying that your user doesn't have access to one part of the repo for some reason, I don't know what causes that but according to strace its not stopping whatever the script is doing)
Comment #3
gábor hojtsy@Narayan: I don't know the intricacies of the script, but David needed to increase the memory limit earlier as well. Looks like this script is using an insane amount of memory.
Comment #4
gábor hojtsySo this is the log of the running script I'm experiencing:
Looking at the d.o-cvs-to-svn.php script, the place it fails is in the passthru(), inside svn_load_dirs.pl:
Given that PHP waits on the feedback of the process from passthru(), and we get the PIPE error from inside the passthru(), I'd think that PHP is not to blame here. Not sure why do you expected PHP is at failure here.
Comment #5
nnewton commentedTry tailing /var/log/php.log while running the script.
Comment #6
gábor hojtsyOk, as I've said this is not an issue with PHP itself. Running the same deploy script works for potx.module. What I did for l10n_server is that I run the d.o script, and then when it PIPEs, I've run the svn-load-dirs.pl command manually from the given tmp directory (since the checkout is available there still). It had very rich output (unlike potx), and got me two questions:
Looks like we could do well with passing
-no_user_inputon to svn_load_dirs, so that it will not ask such questions. Seems like PHP was having errors with the load dirs script prompting without getting an answer.I don't have a module to try this on now, given that I've successfully committed potx and l10n_server changes to the SVN repo, so will try next time and close this out if it works.
Comment #7
moshe weitzman commentedWe are already calling svn_load_dirs.pl with the -no_user_input flag. Thats not the cause of the alleged memory hog.
Comment #8
gábor hojtsyOh, turns out my d.o script copy in /home/gabor on shell.d.o was not up to date. Eh :) I don't have stuff to deploy now, but will reopen this if the next one will not succeed.