1

I have a symfony task that I can run with the following command:

/home/jason/projects/mcif/./symfony import:start-queue

I can then see that the process is running by doing this:

$ ps aux | grep php
jason     5760 91.0  2.5 101628 78128 pts/0    R    13:10   0:04 php /home/jason/projects/mcif/./symfony import:process --id=593 --type=Import
jason     5775  0.0  0.0   4008   764 pts/0    S+   13:10   0:00 grep --color=auto php

That part of it works fine. Now:

  • I have this job sending e-mails so I know whether it actually got started or not.
  • It takes about an hour for this job to run.
  • If I start the job by hitting a PHP script via a browser, I can't find its process.

Here's my script:

<?php exec('/home/jason/projects/mcif/./symfony import:start-queue');

If I run this script on the command line, it works fine. If I run this script via browser, I get the e-mails sent by the script, so I know it's running, but I can't find its process when I run ps aux.

I need to be able to find the process because I need to be able to manually kill it.

Any ideas what's going on?

Jason Swett
  • 43,526
  • 67
  • 220
  • 351

4 Answers4

2

htop is a command that lets you sort by trees so you can see what might have spawned the process and kill it that way if you want to visually look for it.

Katerberg
  • 121
  • 2
0

getpid(2). Or if you are up for hacks, /proc/self.

user502515
  • 4,346
  • 24
  • 20
  • Believe you are suggesting to have the process reports its own PID, in the email or by creating a file in a known location or something. Could also be worth reporting the contents of /proc/self/cmdline to clear up the mystery. – Chris Stratton Dec 10 '10 at 20:43
0

I can think off a couple of solutions:

  1. Inside the file you start in background(/home/jason/projects/mcif/./symfony import:start-queue) which I assume is PHP script else this does not work do http://php.net/manual/en/function.getmypid.php and write the pid to a file on disc. That way you can kill it by reading pid from file.

  2. Start background process which reads(when read something from pipe make exec call) from named pipe(mkfifo) for request from apache(website) which writes to named pipe. The background process should be in ps

  3. Install redis and push it on list from apache(website). From background process blpop message. Again you should be able to find background process in ps

Alfred
  • 60,935
  • 33
  • 147
  • 186
  • Hmm, when I e-mail myself `getmypid()`, it says 3849. When I run `ps` and find my running script, the pid is `3861`. `ps aux | grep 3849` gives me nothing (except the process for `grep`). – Jason Swett Dec 13 '10 at 16:39
  • Now that I think about it, it's probably because one script runs that calls another script, etc. – Jason Swett Dec 13 '10 at 16:45
0

It it's being run via the browser it will depend on your exact setup.

  • The most likely situation (because this is the normal, easiest LAMP setup) is that you're using Apache with mod_php; in this case PHP is part of the apache process, and you'll need to kill the Apache process that is running it. Figuring out which is tricky and may have side effects. I would suggest that you instead run the job from cron so that it's always running from the command line, if this is an option.
  • Another possibility is you're using some sort of fastcgi setup (less common, more complex, but better performance) in which case your task is running in a separate php-cgi process somewhere. I'm still not sure how you could figure out which one is running your task, however, but it's probably slightly safer to kill off these (especially if you're using mod_fcgid rather than fastcgi - it handles php process deaths better).

So, in short, try not to run it from your web browser if you want to be able to kill it without causing other instability. The other answers to this question may let you find the process ID, but you will discover that it's almost certainly an apache process, and you may or may not want to kill that.

If you don't mind the instability, you can just restart your apache server and it will kill the job.

El Yobo
  • 14,823
  • 5
  • 60
  • 78
  • I am using the Apache setup you describe. I can't just straight up schedule a cron job because the job needs to run on-demand, not at certain times. I suppose I could, however, set up some sort of daemon and then just trigger it to start the job as necessary. – Jason Swett Dec 13 '10 at 16:51
  • In any case, I was never able to find the process. – Jason Swett Dec 13 '10 at 16:51
  • The process will be called `apache2`, `apache` or `httpd`. – El Yobo Dec 13 '10 at 22:24
  • Tip for anyone else trying to find a process: do `ps aux > before` before you trigger the process, do `ps aux > after` after, then run `vimdiff before after`. – Jason Swett Dec 20 '10 at 19:59
  • After some more investigation, I found out the process' user was `www-data` and all the process' properties when I ran `ps aux` looked the same whether I ran the script from the web or from the command line. The only difference with the web run is that the process disappeared after a few seconds instead of after many minutes. – Jason Swett Dec 20 '10 at 20:06