os x process state UE - macos

I've got process running that can't be killed. It's my EyeTV App and here is what 'ps aux' says:
cb0 87583 1,0 3,4 812796 144236 ?? UE 21Nov09 2638:11.45 [.....]/EyeTV
The process state is really strange as I've never seen UE before. The manpage tells me
U means Marks a process in uninterruptible wait
E means The process is trying to exit
But I'm not able to kill the process. Any Idea how I could force it to exit??
Additional Info: None of the following statments worked:
kill -S KILL
kill -S QUIT
kill -2
kill -9

Have you tried using
top
in order to get all active processes, and then
kill(PID)
where PID will be referring to the EyeTV process ID handed to you by top?
Also (and I am not sure this works two, but it just might), you could try
kill(pid,SIGTERM)
which sends a termination signal to the process (however that is used in C programming to kill a process, so I am not 100% sure it would work outside of the programming language, but worth a try)

Related

Kill -9 -1 behaviour on MacOS

Our teachers told us to experiment with the terminal and kill -9 -1
To my understanding, on UNIX based OS, the first process charged is Init with PID -1 from which the other processes will spawn. I assumed that you couldn't kill it as it is charged in a secured part of memory.
On a VM running LinuxMint, the command would would cause the session to close itself. On MacOS, it would close/crahs(?) all applications.
On some other people laptops running different distribution of Linux the command would be denied which was the behaviour I would have expected in any OS.
So I am confused by the behaviour of the command.
What should be the normal result? Or is it bound to each OS implementation?
Thanks.
The general behaviour, from Kill MAN page:
If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init)
So, "kill -9 -1" will kill all processes it can.

kill doesn't actually terminate the ghost process

In order to terminate the ghost process (process which hasn't terminated properly and hence it still pending to be killed)
I used the
kill -9 <process-id>
At times it works perfectly, and when I check the process after killing it, it is gone
ps -aux | grep python
However, surprisingly, now I am able to see the ghost process even after the kill command. What's the problem?
In the image above, I tried to kill the process with id 23756 but it still appears in ps aux
Referring to my answer to previous question of Visual Studio ghost process
VSCode kill running processes
Looks like, I had to close the debug process that was still incomplete. Basically, killing the application or closing the debug or something on those lines, helps you to terminate the ghost process.

killing a background process with shell in Ubuntu

I tried killing a process with shell in Ubuntu which is created with like:
#!/bin/bash
<!--There should be codes which can kill my app(run in the background)
echo "app will be run."
java -jar path/to/my/jar/file.jar /arguman/of/myApp.txt & << 'ENDAPP'
disown ENDAPP
I know how to kill an app with manuel which is like:
ps -ax -u| grep appName
and find processid then,
kill [processId]
Is it possible to do?İf yes,how?
Thank you.
You can actually find examples of how to do this right here, on this site, by doing a simple search. (Or Google it: "bash shell wait.") When you execute any background process, you can get the PID ("process id") of the new child. You can wait on the child to finish. You can also kill it.
Shell commands that show you executing jobs also provide their PID.
However, bear in mind that "killing a child" ... while it won't land you in prison in this case ;-) ... "is generally not a good thing to do." You have no idea what the child was doing, what it had or had not finished doing, what data might now be in an inconsistent state, when you put that bullet through its brain. It is impossible to reliably debug any process that relies on murdering its children.
You can "send a different signal," such as SIGHUP or SIGUSR1, to a process, using the same kill command, and design the child process to be listening for that signal as an indication that it must "shut itself down, quickly." Always give a process a signal to "put its own affairs in order, and then to leave 'this mortal coil' ..."

How to Turn Off a Program Running from .bash_profile

I am working with a Raspberry Pi running linux, and have modified the .bash_profile file in order to a run a program I've made automatically upon login. This works great, but I was wondering how to turn the program off, since for ctrl+c I would need to be running the program in the terminal.
You can use Kill to terminate program by its process Id, Top command will list all the processes, You can also use Pkill, which will Terminate the process by its name.
-9 option forces process to shut down, so its very commonly used.
Example:
kill -9 "Process ID without Quotation marks"
pkill -9 "Name with Quotation marks (Case Sensitive)"
Check this.
I always use
pkill - f processname

Killing Subshell with SIGTERM

I'm sure this is really simple, but it's biting me in the face anyway, and I'm a little frustrated and stumped.
So, I have a script which I've managed to boil down to:
#!/bin/sh
sleep 50 | echo
If I run that at the command line, and hit Ctrl-C it stops, like I would expect.
If I send it sigint, using kill, it does nothing.
I thought that was strange, since I thought those should have been the same.
Then, if I send it sigterm, then it also dies, but if I look in ps, the sleep is still running.
What am I missing, here?
This is obviously not the real script, which runs python, and it's more of a problem when it keeps running after start-stop-daemon tries to kill the daemon.
Help me people. I'm dumb.
The reason this happens is that the Ctrl-C is delivered to the sleep process, whereas the sigint you are sending is delivered only to the script itself. See Child process receives parent's SIGINT for details on this.
You can verify this yourself by using strace -p when hitting ctrl-c or sending sigint; strace will tell you what signals are delivered.
EDIT: I don't think you are dumb. Processes and how they work are seemingly simple, but the details are often complicated, and even experts get confused by this sort of thing.
I did the same thing I written script named as test.sh with below containt.
#!/bin/sh
sleep 50 | echo
After executing , I did Ctrl-C -> its working fine means closing it.
Again executed and in another terminal i checked the PID by ps -ef|grep test.sh after finding the pid , i did kill <pid> and it killed the process , to verify again i executed ps -ef|grep test.sh and didnt get any pid.

Resources