site_archiver@lists.apple.com Delivered-To: Darwin-kernel@lists.apple.com On Mar 16, 2006, at 12:54 PM, Spencer Nielsen wrote: I have an interesting problem that I am trying to understand. These are really bad interfaces to use for this. err = kill( pid, 0); switch(err) { case 0: /* exists, we have permission to kill */ case EPERM: /* exists, we don not have permission to kill */ ... break; case ESRCH: /* process does not exist */ default: /* unexpected error - treat as not exists */ ... break; } Basically, this means you shouldn't use them. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... I have a PreferencePane that uses code based off of Apple's GetPID example (which in turn uses sysctl with CTL_KERN, KERN_PROC and KERN_PROC_ALL) to query the state of currently running processes and searches by name to see if a companion program is currently running. My problem is that right now the results that the sysctl call are not the same results displayed by top and Activity Monitor; most notably that sysctl says that my companion program is currently running, has a PID for it and everything but neither top nor Activity Monitor say that it is. A more proper interface to use for this is to apriori know the pid. This is normally done on UNIX systems by storing the in a file in the directory /var/run. A program reads that file and gets the PID. It then uses code like the following: If you need this information to find the process bundle, this is not how you should do it, either. Instead, you should popen() the program "/bin/ps" with appropriate arguments (specifically, use the '-o' option to retrieve only the field you are interested in, and the '-p' option to select a specific process ID, if desired. Throw away the first line read fron the pipe, as that's the header. You may also want to use the option '-ww' to avoid the 80/132 column output restriction). I'm not going to write sample code for that because I believe that people should be discouraged from using this method, rather than writing bundle information into /var/run file(s) as well (e.g. as the second line, after the pid, or, if the pid is a known value, in a file named "program.pid" in /var/run as a means of supporting multiple instances of the program you are interested in (e.g. for support of a licensed program inFast User Switching, or some other environment). I have tried to sudo kill PID and nothing happens. sysctl always reports back that the companion process is running. Up until now sysctl would accurately report that my program is not running if it is in fact not running and my PreferencePane would work as intended. Because I have been working on developing the companion program I have been launching and stopping it all over the place, both through the debugger, the finder and otherwise. I had been working on one portion of it for the last few days and have been running the machine for a while and put it to sleep a few times. It was not until I returned to working on the PreferencePane that I noticed that it always said that my companion program was still running even though top said that it was not. I started to debug the PreferencePane to see if it was maybe some weird thing that I missed. I isolated it down to the fact that sysctl is still including a process structure for the companion program in the results when as far as I understand, it shouldn't be. I have also created a separate test program that simply calls sysctl and looks for the same process. It also reports back that it is running. I suspect that if I reboot my machine the problem will go away or it will easily reproduce (which will then point me towards the bug which is most likely mine). However, I am afraid that if I do reboot that it will in fact go away and I will not be able to reproduce the behavior (because I have no idea what behavior caused it in the first place). Thus my opportunity to hunt this bug might be gone for a while. I don't know much about how the kernel stores process structures but possibilities that I have run through my head are that something went wrong in the bsd process management of the kernal (but then why does "top" not reflect the same results? does top use sysctl or something else like mach calls?). Then again it could also be random cosmic rays or my own bug that I am still overlooking. So before I do actually reboot I wanted to throw it out there and see if anybody more knowledgeable in these things than me could provide any insight. In general, the sysctl() interfaces you are attempting to use are considered SPI - that means we may change them at any point, and that you should use programs that use utilities that rev when the system revs in order to obtain the information (for example, we guarantee that the /bin/ps program will continue to work, no matter what we do to the sysctl(0 interfaces it uses, or if we change it over to some other interface, etc.). That said, it's likely that your mistake is that you are not examining the process state information from the first sysctl before calling subsequent sysctl's, and therefore are not seeing some of the process state flags that might indicate that the process has been zombied, or that something else is going on (e.g. it's in the process of exiting, etc.). In general, this information is reported back in portable format from / bin/ps, if you give it the appropriate '-o' option to select the information you want back from it. This email sent to site_archiver@lists.apple.com