"kill <PID>" not really killing the process, why?

Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:

kill -9 {PID}

Learn more by reading the manual page:

man kill

If kill is invoked without any parameter, it sends the signal number 15 (SIGTERM). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.

You can also "send" the signal number 9 (SIGKILL) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.

One says kill -9 <pid> always works. That's a misbelief. There are situations where even kill -9 does not kill the process. For example when a process has the state D (uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.

Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:

kill - send a signal to a process

The default signal sent by kill [pid] is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.

Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.

If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid].