get-core can't successfully locate jupiter hell process

[esotericist]

so i'm making an issue rather than a pull request because while i found a problem and i found a solution that appears to work, i don't know why this is the case.

when i try to run get-core with jupiter hell running, i get:

Error: could not find Jupiter Hell process to dump.

i check that jupiter hell is in fact running:

$ ps aux | grep "./jh"
eso      1718531 50.2  1.3 3256848 903132 pts/3  Rl+  05:52   2:46 ./jh

so i look at the script and see the pgrep invocation, but somehow pgrep -x ./jh returns an empty list, as if there is nothing for it to match.

i did a little googling, found this stack exchange bit:
https://unix.stackexchange.com/questions/267007/pgrep-full-match-not-work-only-part-why

and sure enough:

$ pgrep -f ./jh
1718531

presumably the fact you've got -x in your pgrep invocation indicates it works for you, so i don't know what the right answer is here.

this is on a ubuntu 20.04.4 LTS system, in case that info matters and there was somehow some kind of breaking change in pgrep between platforms or versions or something. but that feels unlikely?

[esotericist]

of course having adjusted that i'm now running into the issue that it does not actually produce a core file. running gcore 1718531 by hand gives me errors that get-core does not detect or report:

$gcore 1718531
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
You can't do that without a process to debug.
The program is not being run.
gcore: failed to create core.1718531

it looks like /proc/sys/kernel/yama/ptrace_scope has a value of 1 by default, which is restricted scope according to https://www.kernel.org/doc/Documentation/security/Yama.txt

so the advised methodology as written is very much not out of the box; at minimum it appears to require a sudo invocation without substantive changes.

[winny-]

Hey! I totally forgot some distros ship with that setting enabled OOTB. Good thing you tested and reported, thanks!

I am thinking this tool should have the following changed to accommodate this:

1. Show warnings and errors from gcore to the user
2. Give a more helpful error message when this issue arises (such as hint: rerun this program using sudo)
3. Optionally reattempt using sudo when gcore prints a specific error message.

I'll play with this and see what happens

[esotericist]

that sounds reasonable to me.