what port(s) give me good control over processes (list, kill, etc) better than MacOS pgrep+pkill

[Kenneth Wolcott]

Thank you, you have provided lots of help which I need to fully digest..

Ken

On Sat, Apr 8, 2023 at 5:09 PM Richard L. Hamilton <rlhamil at smart.net> wrote:
>
> If you're trying to be exact and ONLY get the process you're probably interested in, here's a scenario:
>
> sh-3.2$ pgrep -lf CARROT # list process-id and full command line
> 911 /Applications/CARROTweather.app/Contents/MacOS/CARROTweather
>
> sh-3.2$ pgrep -l CARROT # list process-id and just command name
> 911 CARROTweather
>
> sh-3.2$ pgrep -u ${LOGNAME} -x CARROTweather # match only current user-id and exact command name
> 911
>
> With -f, it will match (and with -l, display) the entire command line. Without it, it will match (and with -l, display) the command "name", which is the first sixteen characters of the last level of the pathname passed to execve(), or maybe of argv[0], but I don't think so.
>
> With -x it has to be an exact match, otherwise it just has to match a substring (somewhere in what's being matched).
>
> With -u it has to match that user-id too (which can be either numeric or an account name).
>
> So the last of those requires specifically the process CARROTweather running with my own user-id, and will ignore an instance with any other user-id, such as if someone else is logged in graphically with screen sharing/VNC (maybe with NX and some other things too if they allow multiple graphical logins)  and also running it.
>
> A single user can still have multiple processes of the same name running (such as either a command line program or an app opened with the -n option of the open command); there would probably be no good and simple way to be sure which one was desired.
>
>
> > On Apr 8, 2023, at 17:20, Kenneth Wolcott <kennethwolcott at gmail.com> wrote:
> >
> > Hi Richard;
> >
> >  Thank you for your additional input.
> >
> >  Apparently I was over-thinking pgrep+pkill in my earlier attempts.
> >
> >  I have implemented your suggestions in my script and it appears to work fine.
> >
> > Thanks,
> > Ken Wolcott
> >
> > On Fri, Apr 7, 2023 at 9:27 PM Richard L. Hamilton <rlhamil at smart.net> wrote:
> >>
> >> 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 <kennethwolcott at 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$
> >>
> >
>