I'm using php 5 apache on windows server 2008, I have disabled IIS.
I m using exec command in my PHP script and it was working fine
but today I got an error:
Warning: exec(): Unable to fork
I gave permissions to cmd.exe in C:\Windows\System32 folder
but this did not fix the problem.
Specifically which permissions did you give to who?
Probably not to the right user..
Run this php script:
echo 'Script is executed by: ' . get_current_user() . getmygid();
It will tell you which user is running the PHP scripts and therefore which user to grant permissions to cmd.exe.
In 64-bit windows (e.g server 2008), theres a folder named c:\windows\syswow64, that contains all executables/dll, that are required by a 32 bit app. installed on your 64-bit machine.
Make sure your required 32-bit .exe/dll etc is placed in that folder.
if you cant find it there you will have to put a 32-bit version of the required .exe/dll
there.So this can used by yopur app/process.
Now when your 32-bit application/process executes, windows will automatically redirect your process to execute required app in syswow64 folder.
Hopefully that should resolve your compatibility issue.
I had this problem myself, but was eventually able to resolve it. The problem was due to how I had accidentally set cmd.exe to "Run as Administrator" by default. I say "accidentally" as I thought I was only setting the compatibility settings of a shortcut on my task bar, but it turned-out it was setting the compatibility of the .exe itself. Anyhow, I disabled this by deleting the registry key here:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
After doing this, everything started working again.
Related
I have written a PHP script "toalpha" (purpose not relevant to this question). The script is in $HOME/bin. If my CWD is $HOME/bin, I can execute it by typing "./toalpha". But if I simply type "toalpha", I get a message:
Could not open input file: /c/barry/bin/toalpha
Some information that may be relevant:
. I recently upgraded my desktop from WinXP to Win7.
. This is the first time that I have made my own userid be an ordinary user instead of an admin. (I tried to do that on XP, but ran into problems and went back to having my normal userid be the admin. Don't need a solution for that because I'm no longer running XP and besides it was my own fault.)
. My $HOME is /c/barry
I did that by adding the following to the .bashrc created when I installed cygwin:
mount C: /c
HOME=/c/barry
cd
. .bashrc
. The first two lines of the PHP script are:
#!/c/xampp/php/php
<?php
. Yes, the copy of PHP I want to use is in C:\xampp\php\php.exe
. I have another, similar script that I wrote on WinXP. It starts with the same two lines. It worked fine under XP, but doesn't work on Win7.
My best guesses at the source of the problem:
A difference between XP and Win7
I fumbled the home directory change in some way. IIRC, when I installed cygwin on XP I did some trickery so it would start directly in C:\barry but I couldn't remember how I did that when I installed it on Win7, so I took the "easy way out".
bash is passing to "C:\xampp\php\php.exe"
the file name "/c/barry/bin/toalpha"
but that is a cygwin path and your PHP does not regognize it.
You should convert it in an understandable one using
cygpath
Try
/c/xampp/php/php $(cygpath -w /c/barry/bin/toalpha )
I'm debugging my PHP app on CentOS7 using Apache.
My application is a Web GUI to manage the Torque batch system and I used the qmgr, which is a command line tool provided by Torque to do the management work.
Because only the root user can execute the qmgr and the Apache server cannot be running as root user, I have written a C program as a wrapper for anyone to execute commands as root user.
But the PHP application always give the following output:
socket_connect_unix failed: 15137
qmgr: cannot connect to server (errno=15137) could not connect to trqauthd
This means the PHP app cannot raise a socket connection to connect the Torque server.
Here is some additional information:
The command called by the PHP application can be executed correctly in the shell
The same PHP app can be executed correctly on a CentOS6 server with Apache
SELinux and the firewall are disabled
I have tried the two versions (5.1 and 4.10) of Torque, the result is the same
Apache and PHP are used with the default RPM's of CentOS7.
I thought there are some new security limits that maybe influence Apache on the CentOS7 server.
Please give me some suggestions, thank you!
I had the exact same problem.
The cause is that newer Apache.httpd versions default to having the systemd property PrivateTmp set to true. This causes the httpd service to see a private /tmp directory that is actually mapped to some other location in the file system, instead of the real /tmp directory. PHP, running in the Apache process, has the same /tmp directory as the Apache service, and so do any processes forked from PHP (e.g. using exec or system etc). So when PHP calls qsub (etc), that too will see the private /tmp directory.
This causes the error you mentioned because qsub internally uses the unix socket /tmp/trqauthd-unix to communicate with trqauthd. But qsub sees the "fake"/private /tmp directory instead of the real one, so it doesn't find the socket.
This explains why the command works when you run it manually in a console--in that case, qsub sees the real /tmp directory, as opposed to the private one it sees when forked from PHP (running the Apache service).
One solution is to simply change the PrivateTmp property in the file httpd.service from true to false. You can find this file under the /etc/systemd directory. The subfolder it is in probably depends on the linux distribution, so use the find command to locate it:
find /etc/systemd -name httpd.service
This really helped me!
I have been struggling a lot having a php script using exec()-command. For some reason I got permission denied. Having tried vary many things, including running my scripts in shell as the www-data user, but with no success, this was finally the solution to my problem.
BTW, for Ubuntu the apache service config file is located at cat /etc/systemd/system/multi-user.target.wants/apache2.service
I have a php script that works perfectly on the browser BUT it has this error on windows command line.
I have ssl enabled in php config and from what I gather it works for browser but not command line but I don't understand the difference between these two (neither is windows service I belive). Basicly I don't know what to do about it and I need to run the script from commandline, then create .bat file (in order to start windows scheduler - like cron under linux).
I have windows Xp and Xampp. Please help.
As mentioned in comment above. Php in command line uses different php.ini config.
I've installed the LibreOffice RPMS (have tried both 3.5.3 and 3.4.6) on my CentOS machine, and I'm trying to make PHP run a shell script that calls LibreOffice. In the shell script, it runs executes this line:
/opt/libreoffice3.4/program/soffice --headless -convert-to $extension.pdf "$1" -outdir $folder
However, this command will cause the following message to appear:
./createpdf.sh: line 8: /opt/libreoffice3.4/program/soffice: Permission denied
The line itself is fine. If I echo it and run it manually in SSH, it works fine. This is most likely because I'm running it as a different user (note: not as the user that installed it, and not as root), with different permissions.
Desperate as I was, I've already tried chmodding the entire libreoffice folder to 777, and tried to make the 'apache' user the owner. No luck there. Would anyone have a clue as to why it's not letting apache run it, and how I can solve this?
As an alternative to running from the command line, have you considered running UNO (the Open/Libre Office alternative to COM) with the PUNO PHP wrapper. That way, you don't need to worry about permissions
See also Universal Network Objects (UNO): there are Python, Java, etc. bridges for use it. There are applications for simplify the use for convertions, see Docvert and JODConverter (jODconverter and pyODconverter).
All of then can be called as web-service or exec by PHP.
When I call /usr/local/bin/pdftk from PHP in Apache (via shell_exec(), exec(), system(), etc.), it returns the SYNOPSIS message as expected.
When I call /usr/local/bin/pdftk input.pdf fill_form input.fdf output output.pdf flatten via shell_exec(), nothing returns.
When I copy and paste the exact same string to the same path in the shell (as the apache user), the output.pdf file is generated as expected.
Moving the pdftk command into a PHP shell script (shebang is #!/usr/bin/php) and executing it with php script.php works perfectly.
Calling that shell script (with its stderr redirected to stdout) from PHP in Apache (via shell_exec(script.php);) results in this line:
sh: line 1: 32547 Segmentation fault /usr/local/bin/pdftk input.pdf fill_form input.fdf output output.pdf flatten 2>&1
Whenever I run the script from the command line (via PHP or directly), it works fine. Whenever I run the script through PHP via Apache, it either fails without any notification or gives the SegFault listed above.
It's PHP 4.3.9 on RHEL4. Please don't shoot me. I've set memory to 512M with ini_set() and made sure that the apache user had read/write to all paths (with fopen()) and by logging in as apache ...
Just went and checked /var/log/messages to find this:
Oct 4 21:17:58 discovery kernel: audit(1286241478.692:1764638):
avc: denied { read } for pid=32627 comm="pdftk" name="zero"
dev=tmpfs ino=2161 scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:zero_device_t tclass=chr_file
NOTE: Disabling SELinux "fixed" the problem. Has this moved into a ServerFault question? Can anybody give me the 30 second SELinux access controls primer here?
php-cli & php-cgi (or the module, depends on what your server uses) are different binaries. They don't even have to share the same version to live happily side by side on your server. They also may not share the same configuration. Increasing memory usually does nothing to help Segfaults. Points to check:
Are they the same version?
Do they have the same settings (consult the *.ini locations loaded in the phpinfo(); output, and possibly the whole output itself), if not: try what happens if you alter the one for your webserver to the one for the cli as far as possible.
Segfaults occur more in extensions then in the core afaik, and sometimes seemingly unrelated. Try to disable unneeded extensions one by one to see if the problem goes away.
Still no success? You may want to run apache with gdb, but I have no experience with that, it might tell you something though.
No luck? Recompile either the module of cgi your webserver uses.
It's PHP 4.3.9 on RHEL4. Please don't shoot me.
I feel more sad for you then anger, we're beyond the 5.3 mark, come over, it's a lot more happy here.