Why can't I kill this process?

Question

Problem

I would like to kill a process called raspivid (program which records videos using a Raspberry Pi Camera) but I cannot...

This is how I call it:

#!/bin/bash

#Start recording...
raspivid -w 800 -h 600 -t 15000 -o $1 -v -n -rot 270 >> /home/pi/log/camera_output.txt 2>&1 &

#Waiting the video to be complete
sleep 16

#Killing child process
sudo kill -9 $!

#Killing parent process
sudo kill -9 $$

If I search for this process, it is still there:

pi@raspberrypi ~ $ ps -ef | grep raspivid
root      7238     7234  0 21:53 ?        00:00:00 [raspivid]
pi       17096 14925  0 22:05 pts/0    00:00:00 grep --color=auto raspivid

If I try to kill it, it doesn't die. Instead it changes the parent PID to 1:

pi@raspberrypi ~ $ sudo killall raspivid
pi@raspberrypi ~ $ ps -ef | grep raspivid
root      7238     1  0 21:53 ?        00:00:00 [raspivid]
pi       17196 14925  0 22:05 pts/0    00:00:00 grep --color=auto raspivid
pi@raspberrypi ~ $ sudo killall raspivid

Observations:

1. The call works fine for a while (2 hours or something) then it starts hanging.
2. Only a physical power off solves the issue. I cannot reboot via terminal (it hangs too)

My questions:

1. Why does Linux assign the parent PID to 1?
2. Why the process cannot get killed? (I also tried sudo kill -9 7238)

EDIT:

aecolley was right. The column S shows D:

0 D     0 11823 11819  0  80   0 -     0 down   ?        00:00:00 raspivid

Answer 1

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.