Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have php code that is as follows (kill.php):

<?php echo exec("/home/duke/aa/scripts/");  ?> looks like this:

screen -S server -X quit

If I run the php code in the terminal php screen -S server -X quit the script kills the screen session.

However, if I point my web-browser to http://mywebsite/test.php, it displays "No screen session founds" and it doesn't kill the screen session. What can I do to make it work through the web-browser?

share|improve this question
up vote 1 down vote accepted

The default configuration is to run all PHP pages (and their spawned commands) as www-data user, which means they only have access to sessions owned by www-data.

You need to run the script under your own user account, which can be done by:

  • using sudo; for example, the following sudoers entry:

    www-data: ALL=(duke) NOPASSWD: /home/duke/aa/scripts/

    will let you run exec("sudo -u duke /home/duke/aa/scripts/");

  • or installing suPHP: the PHP script will then be run under its owner's account.

Your current example runs the script twice, which may have various side effects. Get rid of the second exec() call – or even better, use system() or passthru() instead – if you want to display the script's output.

share|improve this answer
The sessions are owned by root. Should I modify the sudoers entry aswell? So in my case do I do exec("sudo -u root /path/to/.sh")? – Kevin Duke Jun 4 '11 at 22:29
@Kevin: Correct. Although root is the default for sudo, so you can use just sudo /path/to/.sh in this case. – grawity Jun 4 '11 at 22:38
Would you please explain how I may modify my sudoers entry? – Kevin Duke Jun 4 '11 at 22:43
@Kevin: Replace (duke) with (root), and fix the .sh path if needed. – grawity Jun 4 '11 at 22:43
I can place this www-data: ALL=(root) NOPASSWD: /home/duke/aa/scripts/ anywhere within the sudoers entry? – Kevin Duke Jun 4 '11 at 22:50

I guess the cause is that you start the screen session as another user than your web server user (possibly www-data), but since the script will run as your web server user when started via the browser, it doesn't have the right to send commands to another user's screen session.

How to fix this is dependent on how your originally start the screen session. If it is possible to start it as the web server user, this will be the simplest solution, but other options might include sudo or more complicated measures (*). Tell us more about what you are doing, so we can make useful suggestions.

(*) I've seen a "solution" for this kind of problem where the PHP script would write a special file, which was detected by a cronjob that started it's work only when the file was present...

share|improve this answer
SvenW, the screen sessions were started with the root account, so I have modified the php code to look like this exec("sudo /home/duke/aa/scripts/"); However, no luck still. Any other suggestions before I try starting the sessions with www-data? – Kevin Duke Jun 4 '11 at 22:46
Did you put www-data in the sudoer's file? – Sven Jun 4 '11 at 23:09
yes this is what my sudoer's file looks like: – Kevin Duke Jun 4 '11 at 23:16
@Kevin: sudo by itself doesn't change the user environment completely, e.g. try sudo who am i and you'll still get info on the original user and pty. However, you can tell screen which user to use, e.g. screen -r sessionowner. – Tom Shaw Jun 5 '11 at 0:34
@Tom: who checks the utmp file, but screen just uses the current UID, so the latter should work fine with sudo. – grawity Jun 5 '11 at 12:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.