Not seeing that, if this fits your scenario: sh-3.2$ open -a TextEdit sh-3.2$ pgrep -lf TextEdit 68476 /System/Applications/TextEdit.app/Contents/MacOS/TextEdit sh-3.2$ pkill TextEdit # it went away...
SIGTERM is (usually) like Quit; SIGKILL is like Force Quit. A process may ignore SIGTERM; the signalling process will not be informed of that. SIGKILL cannot be ignored; although in some Unix implementations, a hang on what's supposed to be fast I/O (like a physical disk, or an NFS mount that's "hard" but not "intr") can make a process unkillable, at least until the hang resolves, if it does; if not, nothing but a reboot will kill such a process. Some implementations block SIGKILL on process 1, because process 1 is essential and there's no good reason to do that. Sometimes the executable in an app bundle does not have the same name as the app; but a pgrep -lf could match based on the full path includng the app name. pgrep or pkill not finding something is not an error, although they'll have a return code of one. sh-3.2$ pgrep -lf nosuch sh-3.2$ echo $? 1 sh-3.2$ pkill nosuch sh-3.2$ echo $? 1 You cannot kill something unless you're root or the same real or effective userid as it is; there MIGHT be other restrictions, Apple liking to be tricky about security. But if it exists and you're not allowed to kill it, that would get an error message: sh-3.2$ pkill syslogd pkill: signalling pid 161: Operation not permitted Other than those cases, I don't have further guesses what's happening. > On Apr 7, 2023, at 23:55, Kenneth Wolcott <kennethwolc...@gmail.com> wrote: > > Hi Richard; > > Thanks for the info. I'll look into those. > > I found that a process that I started by using the MacOS open > command could be listed by prep but I could not kill it with pkill > (silently fails, like a no-op). > sh-3.2$
