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

[Richard L. Hamilton]

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  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$ 

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

[Kenneth Wolcott]

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).

Thanks,
Ken

On Fri, Apr 7, 2023 at 7:54 PM Richard L. Hamilton  wrote:
>
> While AFAIK there is not a /proc port, there are FUSE based procfs 
> implementations for macOS. They are limited in the information they can 
> provide, they're using system calls rather than actually digging into the 
> kernel, so they can only provide what the system calls they use offer. So I 
> don't think you can for example see into a process address space with it.  I 
> had it set up some time ago; not sure what FUSE versions or macOS versions it 
> would work with, and didn't really think it worth the bother to keep it set 
> up.
>
> The procs port claims to be an advanced ps with more information.
>
> pfind (also in proctools along with pgrep and pkill) looks to offer much more 
> powerful selection of processes to list; RTFM.
>
> If permissions allow, lldb should be able to attach to a process, control it, 
> inspect it, etc. In addition to owner being the same, some signed or 
> sandboxed processes may be able to refuse being attached to or traced.
>
> Don't forget top, Activity Monitor, and (for certain information) lsof.
>
> > On Apr 7, 2023, at 22:39, Kenneth Wolcott  wrote:
> >
> > Hi;
> >
> > what port(s) give me good control over processes (list, kill, etc)
> > better than MacOS pgrep+pkill?
> >
> > It would be great if MacOS has /proc filesystem like Linux.
> >
> > Thanks,
> > Ken Wolcott
> >
>

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

[Richard L. Hamilton]

While AFAIK there is not a /proc port, there are FUSE based procfs 
implementations for macOS. They are limited in the information they can 
provide, they're using system calls rather than actually digging into the 
kernel, so they can only provide what the system calls they use offer. So I 
don't think you can for example see into a process address space with it.  I 
had it set up some time ago; not sure what FUSE versions or macOS versions it 
would work with, and didn't really think it worth the bother to keep it set up.

The procs port claims to be an advanced ps with more information.

pfind (also in proctools along with pgrep and pkill) looks to offer much more 
powerful selection of processes to list; RTFM.

If permissions allow, lldb should be able to attach to a process, control it, 
inspect it, etc. In addition to owner being the same, some signed or sandboxed 
processes may be able to refuse being attached to or traced.

Don't forget top, Activity Monitor, and (for certain information) lsof.

> On Apr 7, 2023, at 22:39, Kenneth Wolcott  wrote:
> 
> Hi;
> 
> what port(s) give me good control over processes (list, kill, etc)
> better than MacOS pgrep+pkill?
> 
> It would be great if MacOS has /proc filesystem like Linux.
> 
> Thanks,
> Ken Wolcott
> 

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

[Kenneth Wolcott]

Hi;

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

It would be great if MacOS has /proc filesystem like Linux.

Thanks,
Ken Wolcott

mongodb 6.0 - No mongo or mongosh binaries

[Steven Green]

After updating mongodb to version 6.0, there is no longer a mongo 
executable, which is how you normally connect to it from a command line.


The mongo web site says "/The legacy mongo shell was deprecated in 
MongoDB 5.0 and removed in MongoDB 6.0. The new MongoDB Shell, mongosh, 
offers numerous advantages over the legacy shell./".


However, I can not find mongosh in any ports either. Am I overlooking a 
port?


- Steven

Re: argp.h

[Ryan Schmidt]

On Apr 7, 2023, at 04:23, Christoph Kukulies wrote:

> Am 07.04.2023 um 11:02 schrieb Christoph Kukulies:
> 
>> Anyone having an idea where the  is buried?
> 
> OK, I found in the macOS prerequisite list for macOS that the brew package 
> „argp_standalone“ is required.
> I hate mixing brew and macports.

Right, please don't; it will cause problems.

You can use the search function on the ports web site to discover if we have a 
port that provides a particular file, for example:

https://ports.macports.org/search/?installed_file=/argp.h

This shows that we do have such a port and it is called argp-standalone.

Re: argp.h

[Christoph Kukulies]

OK, I found in the macOS prerequisite list for macOS that the brew package 
„argp_standalone“ is required.
I hate mixing brew and macports.

> Am 07.04.2023 um 11:02 schrieb Christoph Kukulies :
> 
> I’m about to compile a tool, named „drat“ - an APFS repair tool 
> (https://github.com/jivanpal/drat )  maybe 
> worth making a port of it - and I’m getting compilation errors since the 
> argp_parse library (seems to be a part of the gnu clib, but which one?) 
> cannot be found.
> 
> Anyone having an idea where the  is buried?
> 
> —
> Christoph
> 



smime.p7s
Description: S/MIME cryptographic signature

argp.h

[Christoph Kukulies]

I’m about to compile a tool, named „drat“ - an APFS repair tool 
(https://github.com/jivanpal/drat )  maybe 
worth making a port of it - and I’m getting compilation errors since the 
argp_parse library (seems to be a part of the gnu clib, but which one?) cannot 
be found.

Anyone having an idea where the  is buried?

—
Christoph



smime.p7s
Description: S/MIME cryptographic signature