‘ps’ arguments to display PID, PPID, PGID, and SID collectively

When a process is forked, it inherits its PGID from its parent. The PGID changes when a process becomes a process group leader, then its PGID is copied from its PID. From then on, the new child processes it spawns, and their descendants, inherit that PGID (unless they start new process groups of their own).

In a shell with job control, such as most interactive shells, each job is put in its own process group. If you run a shell script, the shell process running the script will be the group leader, and the PGID will equal its PID.

In a shell without job control, such as most shells used to run scripts, commands are run in the shell's process group.

The syntax kill -- -N kills all the processes in the group with PGID = N. You can't use it with an arbitrary PID, only the PID of a process group leader, since that's the PGID. This is essentially how the shell's

kill %jobid

syntax works -- it internally translates %jobid to the PGID of the job and sends the signal to that PGID.

There's no simple way to run a script in its own process group from another shell script. See How to set process group of a shell script for some suggestions, though.

If you run ps -el instead of ps -ef, you'll get an S column with the process state. My guess is that the process is in state D, which means uninterruptible wait.

In other words, the process is stuck in the messier parts of a device driver, and the kernel doesn't think it's safe to kill it until the device driver lets go of it. You sometimes see this with processes that talk to sick NFS servers, or devices with errors. In this case, it looks like it's talking to a video-capture device.

Unfortunately, there's no silver-bullet way to unstick a process from D-wait, except for rebooting the system. You could try using the Solaris command truss to find out what the program did right before it got stuck, but there might not be anything you can do about it. You may just have a buggy device driver.

Finally, the reason the parent pid changes to 1 is that your killall is successfully killing the parent process. Whenever a process exits, its child processes are all inherited by pid 1. It's a minor mystery why the ps -f line for the parent process isn't matched by the grep.