2

Update: by redirecting stderr from php exec, I can now see that running maxima produces a segmentation fault, increasing the likelihood that this is in fact a bug.

Important note: this used to work perfectly on older versions of PHP/Ubuntu.

I'm trying to get PHP exec() (or shell_exec() ) to redirect the output (stdout) of a maxima call to a text file. All I get is an empty file.

I have tried the simplest of commands:

exec( "maxima -b /var/www/tmpIn.txt > /var/www/tmp/tmpOut.txt");

(tmpIn.txt just contains the text "1+1;", all permissions are set properly).

If I paste this command in the terminal it will work fine, php's exec() will only produce an empty file. However, this is the case only for the maxima binary; cat/echo/ls etc. redirect just fine.

To me this seems exceedingly strange especially as this code used to work well as mentioned. Is there any workaround for this "bug"?

System info: ubuntu 20.04 PHP version 7.4 on Apache2 Maxima 5.43.2 bash

WantsToLearn
  • 41
  • 3
  • Looks like you have already tried some good ideas. The only thing I can think of is that PHP is executing Maxima in a different environment than at the command line. Is it possible that there is more than one maxima executable on the system? Is PHP executing maxima with some environment variables set? Is PHP executing maxima with user set to something compatible with the permissions on the various files and directories? By the way, can you get a more extensive error message? Maybe it says something about some other problem before the segfault. – Robert Dodier Nov 29 '20 at 17:38
  • Also, perhaps you can append the output of `build_info();` to your problem description (assuming that you can execute the same maxima as what PHP is executing). Sorry I can't be more helpful! – Robert Dodier Nov 29 '20 at 17:38
  • I have finally resolved the issue by changing the Apache 2 user from www-data to another user on the machine, so that user was restricted in some way. I believe this should still be considered a bug as the Segmentation Fault message should have been replaced by an actual error message in case those restrictions were intentional. – WantsToLearn Nov 29 '20 at 21:31

2 Answers2

2

I have finally resolved the issue by changing the Apache 2 user from www-data to another user on the machine, so that user was restricted in some way. I believe this should still be considered a bug as the Segmentation Fault message should have been replaced by an actual error message in case those restrictions were intentional.

Update: the new apache2 user (set from envvars file) must have a home directory (e.g. added through adduser and not useradd) otherwise the problem will persist. If you set this to an active user the server might shutdown if that user is logged in/out externally. Those findings might point to a bug in maxima assuming a user directory or similar. I'm not sure if going the other way around (adding a home directory for www-data) would resolve this bug or not.

WantsToLearn
  • 41
  • 3
  • Thanks a lot for the update. I will try running Maxima with a user which does not have a home directory to see what happens. There is some code which is executed when the program is launched which reads initialization files. It seems possible that code assumes that there is a home directory and fails without it; anyway I will try to verify the bug. Thanks again, the information you provided is very helpful. – Robert Dodier Nov 30 '20 at 17:53
  • For the record, I've tried running Maxima on an Ubuntu system with users which do not have a home directory. I was able to execute Maxima successfully with users which do not have a home directory, however, the crucial bit was that a working login shell is required. I.e. this works: home = /something/nonexistent, shell = /bin/bash, and this doesn't: home = /something/nonexistent, shell = /bin/false. I looked at /etc/passwd to see what's the home and shell. What does /etc/passwd say about www-data? In my experiments, I tried: `sudo su someuser -c 'maxima --version'` or other commands. – Robert Dodier Dec 10 '20 at 05:47
  • What does `build_info();` report for your Maxima installation? Different Lisp implementations might have different behavior. – Robert Dodier Dec 10 '20 at 05:49
0

assuming that the path of installation is /usr/local/maxima5.43.2

please try using the following:

exec( "/usr/local/maxima5.43.2/maxima -b /var/www/tmpIn.txt > /var/www/tmp/tmpOut.txt");

Please adjust the path according to your own installation path . In addition, please add read and execute permission of maxima to apache , and also try using sudo to run

Ken Lee
  • 6,985
  • 3
  • 10
  • 29
  • Unforunately this was among the things I tried (maxima is installed at /usr/bin/maxima on my machine) to no avail. – WantsToLearn Nov 29 '20 at 02:46
  • please make sure that you have added both read and execute permission of maxima to the apache – Ken Lee Nov 29 '20 at 02:50
  • I've ensured that all permissions are set properly. I don't understand why would php have an issue running maxima even with the full path and permissions set. – WantsToLearn Nov 29 '20 at 02:56
  • please try using sudo. (you may refer to this link: https://stackoverflow.com/questions/3173201/sudo-in-php-exec) – Ken Lee Nov 29 '20 at 02:59