programmingnoob

never mind, now i feel i am not even sure if it's even running ...

the reason i thought it was still running, but I coded my program so that while the host is running, then if you start the program again, then guest part will run

it ran the host once, and after that it's only running guest now!
i want it to run host again!

grumpy

If the kill command fails because the operation is not permitted, it normally means you don't own the process (only root can kill processes owned by other users). If you actually own the process you're trying to kill, ensure you get the PID correct.

Eoin

Well if you can see it's PID then it is running but I don't quite follow what you ment in your last response so I could be a bit confused.

__________________
Visit my website BinaryNotions.

programmingnoob

i have a question... that can solve this problem in a subtle way lol

if i am trying to code a message passing interface in linux/unix
is there any way i could check whether a queue associated with a key exists or not? the point to note is that I dont want to create a queue if it does not exist, i just want to see whether it exists or not ...
would IPC_EXEL help at all?

grumpy

Unix operating systems enforce security constraints on various actions (i.e. if you don't have permission to do something, you are not allowed to do it).

Obtaining information about a process (eg it's process ID) is fairly benign so most users are allowed to do it. However, killing a process is not benign: if you were to kill a process owned by another user, you could seriously inconvenience that other user. Therefore users are prevented from killing processes owned by other users.

Eoin

Hi grumpy, yeah I'm a bit too used to playing around on my own *nix setup where if you can't do something you sudo it .

That said though my confusion was regarding what exactly programmingnoob ment by the host and guest parts .

__________________
Visit my website BinaryNotions.

Ooble

You can use some versions of top to kill processes. Run top and identify the process. Hit the k key, type the process ID (PID) and hit Enter twice.

__________________
Me :: You :: Them

Kennedy

Hmmm, sounds like the OP exited and the OS allowed (probably an oops) the process to stay active. . . which means that ROOT now owns it.

If this is NOT the case, you could try killall and the NAME of the process.

[EDIT] Probably need to man killall [/edit]

grumpy

You're referring to zombie processes.

When a parent process spawns a child it is possible for the child to exit before before the parent knows about it. When that happens, the system keeps information about the child process in case the parent needs it (eg to check the exit status, etc). The parent needs to call wait() to get information it might need. If the parent hasn't done that, then the child becomes a zombie (with ps, the child will typically have a Z in it's status to indicate this). It consumes no resources (as it is no longer running) except for an entry in the system process table. That becomes a problem for the system if there are too many zombies, as the system process table is finite;. It can also be a problem for the user who created the child (i.e. who ran the parent, which ran the child) as most systems limit the number of processes any user can have going and that limit is less generous than what is available to the system. Zombies cannot be killed using the kill command (as they are not running, and cannot respond to signals).

The real way to stop zombies is for the parent to call wait() [or a related function], such as checking the child's exit status. One way to stop them under some flavours of unix if the parent is still active is to send a SIGCHILD (value 18) signal to the parent, which tells parents to kill all their children. Unfortunately, not all versions of unix support this by default, so we come back to the problem of having to design the parent to do it (by writing a signal handler that does the work of killing the children).

If the parent dies before it killing it's children the zombies are inherited by the init process (which has PID of 1: it is the first process launched by the system when starting unix). On some forms of unix, init periodically cleans up the zombies it has adopted. On some systems, init will periodically clean up it's zombie children, but system configuration settings or a bug can prevent that (init does other work, and has to wait for other things to happen; if those things don't happen ....). On some systems, init can be told (by sending a SIGCHILD signal to it) to terminate it's children --- but init is a system process, so normal users can't do that. The net effect is that init does not necessarily kill it's adopted children. The only way then is to shutdown the system (during which init terminates all processes on the system with prejudice) and restart.

There are many human parents who would like to have similar abilities to unix parent processes.

climbnorth

At the terminal type:


if that doesn't work try:


(I think thats the syntax) That will show you list of all processes and some otehr information that is useful: such as the command line that was used to execute the command. Now use grep to find out which command it was. Grep matches regular expressions but all you need is something you can identify that would be in the executables path- such as the name of your home directory. To tie the ps and grep commands together, use a pipe:


the result will possibly give you a few lines. It should be easy to identify your process- because the command string will probably look familiar (a.out??).

Now use the "kill" command on the process ID (first column). To make sure kill works, you can throw the "-9" switch in (which is more forceful).


BTW none of this will "mess up the server." Even if you tried to kill other processes, you wouldn't have permission.

By default, when you run apps remotely they should hang up when you exit your console. This is a design feature. To "daemonize" a process, you would use the command nohup. This makes it so it "doesn't hang up" after you exit. Because of this, your process probably died when you logged out. That is of course, dependant on the OS. Sometimes "logout" doesn't wokr, sometimes you have to use "exit" to make sure all processes die. Also, some applications may be built in with nohup ability (apps that you start with a script will likely have a call to nohup to daemonize or something similar).