Bug 215781

Summary: Calling pgrep "javafrom java process
Product: Base System Reporter: Brandon Barker <brandon.barker>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Not A Bug    
Severity: Affects Only Me CC: jilles, ler
Priority: ---    
Version: 11.0-RELEASE   
Hardware: Any   
OS: Any   

Description Brandon Barker 2017-01-04 21:46:42 UTC
Disclaimer: Since this problem has to do with 'pgrep' as well as 'java', and I no longer see a 'java' component as advised, I'm putting under base/bin.

Although I haven't created a minimal working example of the summary, it is easy enough to reproduce in its current form. I'm using ammonite shell to run pgrep.

Install ammonite with these two lines ( see docs for latest instructions: http://www.lihaoyi.com/Ammonite/#Ammonite-Shell):

mkdir -p ~/.ammonite && curl -L -o ~/.ammonite/predef.sc https://git.io/v6r5y
sudo curl -L -o /usr/local/bin/amm https://git.io/v1rPf && sudo chmod +x /usr/local/bin/amm && amm

Then, in amm, simply run:
%pgrep("java")

For the original ammonite bug report, see https://github.com/lihaoyi/Ammonite/issues/541
Comment 1 Brandon Barker 2017-01-04 21:56:32 UTC
A couple of notes I accidentally left out due to premature submission:

* openjdk8 is required to be installed.

After running this in amm:
%pgrep("java")

this results in the following less than helpful error, which after looking through the ammonite code, indicates that nothing to stdout was printed from pgrep:

ammonite.ops.InteractiveShelloutException
  ammonite.ops.Shellout$.executeInteractive(Shellout.scala:53)
  ammonite.ops.Shellout$.$anonfun$$percent$1(Shellout.scala:14)
  ammonite.ops.Shellout$.$anonfun$$percent$1$adapted(Shellout.scala:14)
  ammonite.ops.Command.applyDynamic(Shellout.scala:105)
  $sess.cmd22$.<init>(cmd22.sc:1)
  $sess.cmd22$.<clinit>(cmd22.sc:-1)
Comment 2 Jilles Tjoelker freebsd_committer freebsd_triage 2017-01-04 23:38:50 UTC
Unless the -a option is used, pgrep and pkill do not find any ancestor processes. This is documented if you read the man page fully, but might be slightly unexpected. On the other hand, why use pgrep to find the current shell process?

The commit message that added this (SVN r192242) states:

"When finding processes, ignore ourself and our ancestors.  It is almost
always surprising when you kill a 'sh -c ...' ancestor or when you kill
yourself when using -f."
Comment 3 Brandon Barker 2017-01-05 20:19:18 UTC
Aha, thanks, and sorry about that - I really should be more thorough in man page checking between systems. Adding "-a" does indeed fix the problem.
Comment 4 Brandon Barker 2017-01-06 01:23:18 UTC
I'll admit I'm curious as to why this isn't an issue when calling pgrep from other shells, like tcsh: "pgrep tcsh" from tcsh.
Comment 5 Jilles Tjoelker freebsd_committer freebsd_triage 2017-01-06 21:16:12 UTC
(In reply to Brandon Barker from comment #4)
I see the same behaviour with zsh:

% pgrep zsh
983
968
% pgrep -a zsh
1857
983
968
% 

This is with three shells open and running pgrep from one of them.
Comment 6 Larry Rosenman freebsd_committer freebsd_triage 2017-01-06 21:21:49 UTC
might it have to do with the proc title of the calling process.  where -a grabs all the 
processes before?

(just pure unadulterated conjecture)