Sysctl: I didn't know about this approach. But you are correct that this will list only the user's own processes. Of course, parsing output from launchctl is something else that Apple strongly cautions against. You can combine that with output from launchctl and get pretty detailed information. I have an app that does a whole lot of "system monitoring" and I'm trying to put that thing to bed so I can work on a real app.īut if you insist, I can tell you the following: It would be better to develop a regular 'ole app that can run on either iOS or macOS and then you never have to deal with these kinds of problems. I'm working on an app that contains a mini system monitoring utilityI think that is your error right there. Even if I came up with some formula that produces plausible looking results, I have no real guarantee it's correct or equivalent to what Activity Monitor shows. However, I don't know how to convert the cpu_*_time fields of the resulting struct rusage_info_v4 to compute a "simple" percentage. Looks like they're using proc_pid_rusage. Needless to say, I have no confidence in being able to make a safer privileged helper than Apple's engineers lol On the other, making my own similar privileged helper would be duplicating effort, and expose a bigger attack surface. On one hand, I don't want to depend on a private API, because that takes a lot of time to reverse engineer, keep up with changes, etc. There are some partial reverse engineered header files floating around, but they're incomplete, and have the usual fragility/upkeep issues associated with using private APIs. But unfortunately, the only documentation/usage I can find of sysmond is from bug databases demonstrating a privilege escalation vulnerability lol. Getting the data "striaght from the horses mouth" like this sounds ideal. That's a user library which wraps an XPC connection to sysmond ( /usr/libexec/sysmond), allowing you to create requests ( sysmon_request_create), add specific attributes you want to retrieve ( sysmon_request_add_attribute), and then functions to query that data out ( sysmon_row_get_value). From what I can tell, it's using private functions from /usr/lib/libsysmon.dylib. Disassembling the kernel on my mac, I could confirm that the assignment of that field never happens (thus _PROC_HAS_SCHEDINFO_ wasn't set during compilation, and the value will always stay zero)Īctivity Monitor.app makes proc_info and sysctl system calls, but from looking at the disassembly, it doesn't look like that's where its CPU figures come from. The assignment of p_pctcpu is in a conditional region, relying on the _PROC_HAS_SCHEDINFO_ flag. p_pctcpu looked really promising, but that value is always zero.ĭigging deeper, I found the kernel code that fills this struct in ( fill_user64_externproc). Using the keys, I'm able to get a kinfo_proc instance. I'm a little scared of that, because I don't want to put my users at risk. Perhaps running as root could alleviate that, but that would involve making a priviliedged helper akin to the existing sysmond that Activity Monitor.app uses. It doesn't work for processes owned by other users. Listing a table of processes now takes O(proces_count) rather than just O(process_count), and causes way more syscalls to be made Summing these, I could get the total for an app. Using proc_pidinfo with PROC_PIDTHREADINFO, I'm able to get each thread of an app, with its associated CPU usage percentage. I detail my research below.Īny pointers in the right direction would be much appreciated!įirst I looked at libproc. I've gone to great lengths to try to find this information myself, and at this point I'm just struggling. Ideally, I want to go through public headers/frameworks. I would like to list the top CPU-using processes.Īs Quinn “The Eskimo!” has repeatedly cautioned, relying on private frameworks is just begging for maintenance effort in the future. I'm working on an app that contains a mini system monitoring utility.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |