1

I have an issue updating SVN from within PHP. It was working fine then suddenly stopped working a few days ago.

I am running PHP-FPM 5.5 through Nginx. SVN version is 1.8.8.

The code:

exec("svn cleanup $path");
exec("svn revert $path -R");
exec("svn update $path --accept theirs-full --non-interactive", $output, $return);
echo "Return: $return\nOutput: ".print_r($output, true)

Output:

Return: 1
Output: Array
(
)

When I run this in terminal (under the same user as PHP-FPM and Nginx), I get the expected output:

Updating '/path/to/app':
At revision 100

PHP CLI also works with the correct output (under same user as PHP-FPM and Nginx):

php5 /path/to/app/svnupdate.php

Based on this it seems to be specifically an issue with PHP5-FPM exec on svn. But how can I debug this and figure out what is wrong?

Thanks.

Updates from comments to keep everything together: Tried the proc_open approach, running only "svn cleanup $path" via that failed and caused all files to lock. running same command under same user in terminal worked fine and unlocked all files again.

Tried full path to svn bin, no difference

Running "svn info $path" seems to work fine, no files were locked. The following commands all fail in php exec/proc_open (without any error message or output) and lock the app files:

  • svn cleanup $path
  • svn revert $path -R

"svn update $path" returns "Updating '$path'" but stops there, previously the current build number would be returned on a second line.

I have a 2nd setup with a different app and svn server but running the same version OS and all software, this one is working fine. I think that rules out software.

i tried rolling the issue server back to a version from 2 months ago when it was working, the server automatically updates software and app on launch but should not have touched config files or cache. After it was available it was still showing the same issue. Fairly sure that rules out software config files/cache.

Which leaves only app codebase and svn server as a possible cause. I'll try resetting the svn server next and redoing the svn project.

Update 2: Recreated the project on the SVN server, remove application from app server and all svn config directories, checked out the new project from SVN server (build 1). Still the same error. !_!

Update 3: After doing all of the above i concluded that left only the file base that could be causing the issue. And it was, there was a "Can't convert string from native encoding to 'UTF-8':" error being thrown by SVN because of a few files with special characters in the filename. Interestingly the error only stopped the process when running from php-fpm and not in terminal. NO IDEA WHY. I added export LC_CTYPE=en_US.UTF-8; to the exec command and now it is working fine.

exec("export LC_CTYPE=en_US.UTF-8; svn update $path",$output);
Improve this question
7
  • My guess is that svn isn't in the path, try using the full path to the executable. Commented Dec 6, 2016 at 2:25
  • if it wasnt in the path then it would not work in terminal either under the same user. But to rule it out i tried with the full path, /usr/bin/svn and still the same result. Commented Dec 7, 2016 at 1:13
  • And you're sure that $path is correct? Commented Dec 7, 2016 at 1:43
  • yes, works in terminal Commented Dec 7, 2016 at 1:51
  • No, I meant that the $path variable itself is populated correctly. Maybe it's not being passed through? Can you log it - echo $path;? Commented Dec 7, 2016 at 1:53

3 Answers 3

Reset to default
1

The exit status (1) indicates that the command fails for some reason. To find out the reason, you need to capture the standard error with the help of proc_open function as shown in this answer. The exec function captures only the standard output.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

$out is empty, $exit_status is 1 for all 3 svn commands. No error is displayed. to compare, i also ran "ls $path" in proc_open which gave me the expected $out and $exit_status 0. additionally, when I tried svn update in terminal it seemed that SVN was locked and cleanup had to be run first.
further info upon researching a bit more: if i ONLY run svn cleanup in php it fails and it looks like every file in the app directory has been locked - ran svn status --show-updates and as far as I can tell every file is listed with an L flag. I don't know much about the inner workings of SVN but it would seem like php is launching SVN, it locks the app files, and then it crashes before the requested action can be taken... the "cleanup" command is obviously not running via php else why would everything be locked. Running cleanup in terminal with the same user works just fine, no issues.
tried deleting the entire app directory, subversion folder and starting with a fresh checkout. But still the same issue.
1

There was a "Can't convert string from native encoding to 'UTF-8':" error being thrown by SVN because of a few files with special characters in the filename. Interestingly the error only stopped the process when running from php-fpm and not in terminal. NO IDEA WHY. I added export LC_CTYPE=en_US.UTF-8; to the exec command and now it is working fine.

exec("export LC_CTYPE=en_US.UTF-8; svn update $path",$output);

I used this code to actually discover the error in php:

$proc = proc_open('svn update', $desc, $pipes);
echo 'PIPE 1: '.stream_get_contents($pipes[1]); fclose($pipes[1]);
echo 'PIPE 2: '.stream_get_contents($pipes[2]); fclose($pipes[1]);
echo 'STATUS: '.proc_close($proc);
Improve this answer

Comments

0

In my situation, I fixed the problem by following steps:

  1. check which user php-fpm runs, in my case, it is nginx

  2. cat /etc/passwd to check 'nginx' user, its home directory is '/var/cache/nginx'

  3. cp /root/.subversion to /var/cache/nginx

  4. reconfig /var/cache/nginx/.subversion/servers if you need

  5. then is works well

Maybe the debug process is helpful:

  1. I guess it is because of the permission problem

  2. I change nginx from /sbin/nologin to /bin/bash

  3. I run runuser -l nginx -c 'php myphpscript_which_exec_svn_command.php'

  4. It will output some information you need

  5. So I get the solution, for security reason, change nginx user property back(/bin/bash to /sbin/nologin)

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.