ProblemI 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 completesleep 16#Killing child processsudo kill -9 $!#Killing parent processsudo kill -9 $$If I search for this process, it is still there:pi@raspberrypi ~ $ ps -ef | grep raspividroot      7238     7234  0 21:53 ?        00:00:00 [raspivid]pi       17096 14925  0 22:05 pts/0    00:00:00 grep --color=auto raspividIf I try to kill it, it doesn't die. Instead it changes the parent PID to 1:pi@raspberrypi ~ $ sudo killall raspividpi@raspberrypi ~ $ ps -ef | grep raspividroot      7238     1  0 21:53 ?        00:00:00 [raspivid]pi       17196 14925  0 22:05 pts/0    00:00:00 grep --color=auto raspividpi@raspberrypi ~ $ sudo killall raspividObservations:The call works fine for a while (2 hours or something) then it startshanging.Only a physical power off solves the issue. I cannot reboot viaterminal (it hangs too)My questions:Why does Linux assign the parent PID to 1?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
Why can't I kill this process?
linux;bash;process
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.