问题
Below is a pared-down (error/null checks omitted) snippet of C/Obj-C code that uses sysctl to get the argv of a particular process with PID 50.
...
int getProcessArgs[3] = { CTL_KERN, KERN_PROCARGS, 50 };
sysctl(getProcessArgs, 3, NULL, &length, NULL, 0);
char* processArgs = malloc(length * sizeof(char));
sysctl(getProcessArgs, 3, processArgs, &length, NULL, 0);
...
The first call to sysctl (to determine the size of the argv string array) succeeds. The returned length is ~1600, larger than I would expect, but I suppose not unreasonable. Malloc succeeds. The second call to sysctl returns -1, setting errno to 22, E_INVAL.
I've looked at other code, including that from this question, but can't see the problem with mine. What am I missing?
回答1:
I tried wrapping your code up into a program, and it works fine and prints out the other process's argv etc when inquiring about one of my own processes, i.e., one with the same uid as the process invoking sysctl().
The "larger than I would expect" aspect is because the process's environment variables are returned as well as the command line arguments. (It's not obvious what the format of all this information is.)
When inquiring about a different user's process, I get the same EINVAL from the second sysctl that you've been seeing. I guess this is considered unreasonable curiosity about other people's processes, but you'd think the first sysctl would fail too.
(When inquiring about a non-existent pid, the first sysctl fails with EINVAL.)
This all seems to be massively underdocumented: on Leopard, KERN_PROCARGS doesn't even appear in the sysctl man page.
来源：https://stackoverflow.com/questions/2567510/why-is-sysctl-producing-e-inval-on-mac-os-x