lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

522
hpr_transcripts/hpr1142.txt Normal file
View File

@@ -0,0 +1,522 @@
Episode: 1142
Title: HPR1142: LiTS 020: pgrep and pkill
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1142/hpr1142.mp3
Transcribed: 2025-10-17 19:43:11
---
Hi everyone, this is Klaatu.
You may or may not know me from Hacker Public Radio.
And it turns out we're throwing a party on New Year's Eve.
And everyone's invited, whether you've listened
to Hacker Public Radio or not, whether you've contributed
or not, you should stop in on the Mumble Server,
mumble.openspeak.cc, port 64747.
You can use any username you want.
Drop in, say hi, eavesdrop, whatever you want to do.
It'll be a lot of fun.
And it's going for 24 hours.
That's right, UTC minus 12.
The whole UTC day will be broadcasting all day, all night,
and we want you to join us.
Welcome to Linux and the Shell Episode 20, PGrep and Pkill.
My name is Dan Washco.
I will be your host today.
And I'd like to start by thanking Hacker Public Radio
for supporting the show by hosting the website along
with the audio files.
So I strongly suggest you head over to HackerPublicRadio.org
to check out the other wonderful shows and consider
contributing your time to producing your own show
on a topic that you love.
So let's get into the commands for today.
Today we're talking about PGrep and Pkill.
And they kind of go hand in hand, although you probably
would use one or the other, not both combined in most cases.
What we're going to start with is PGrep.
And what that stands for is ProcessGrep.
It's a great utility to be able to find the process ID
for processes running.
And you could just name the process that you're interested in
and it returns the process IDs.
So it's like a Grep command for processes.
Instead of having to go to PS or top,
you could just use PGrep and type the process name
that you want to, for instance, X term.
And it will return a PID.
So by default, you just type PGrep space X term.
And it returns a process ID.
Maybe it's 5,036 or something like that.
That will give you back the process ID.
Add by its default.
Simple, purely simple.
Now, you can control the way that the display is for PGrep
by passing a couple of different switches.
Now, the process ID might be all that you're looking for.
But if you want to be sure, if you do a PGrep command,
you want to be sure what the process name is
is being returned.
So you're getting the correct process ID.
You just do the dash L or dash, dash, list, dash name.
That's list, dash, name.
And what that does is it lists the process ID
along with the process name.
So if you did PGrep dash L, X term,
it would list the process ID 5,036.
And then it would also list X term right after that.
Now, they just list the process name.
If you want the full process command line, you use dash A
or dash, dash, list, dash, full.
And that would list something like whatever the full command
line is, and execute that command.
Now, if you just execute it X term by itself,
it would probably just list X term as the full process name.
But if you execute X term as slash user, slash bin, slash X term,
then it would list the full path.
Whereas just dash L would only list X term.
Now, when you X term most commands
to probably look at this for, mainly return one process ID.
But if you would do, say you had Chromium Browser running,
and you did PGrep Chromium, it would return a bunch
of process IDs.
And if you did dash L, it would return the full command
line list, like right now I have Chromium running.
And if I did pre-PGrep X term with the dash L,
or PGrep sorry Chromium, with the dash L,
it returns a goodly amount of processes.
Well, that's a good point to jump in and talk about another switch.
And that's dash C or dash dash count.
So if I do dash C, instead of returning the process IDs,
it returns account of the total number of process IDs
that would be returned.
In this case, for PGrep dash C Chromium,
it returns 19 processes.
Now, if I did dash L, all I get back from all those processes
are the first, I think it is 15 letter characters.
So I see a number of Chromium processes,
but one of those is Chromium-Sanbo, which
is actually Chromium-Sanbox.
Now, if I do the dash A, I get a significantly different response
for Chromium.
I get, in a lot of cases, slash user slash lib, slash Chromium,
slash Chromium, and then I see Chromium-Sanbox.
I see in addition to that, the switches
that were used to call the different Chromium processes
and stuff like that.
So there's a lot more that you get with dash L, dash A.
So to speak, then just the command line,
you get the switches and everything else too.
Now, let's continue down some of the other ways
we could look at the processes return.
Now, as I said, there's 19 processes that were returned.
I could just look at the first process or the oldest,
so to speak, by using the dash O switch.
And when I do that, all I get is one process ID return
or one process return.
That's the oldest one in that list,
the one with the lowest process ID typically.
I can get the newest one with the dash N or dash dash newest.
And that returns the process ID for that new,
the most recent process of Chromium that was executed.
Chances are it's going to be the last process ID
in the list more than likely.
So there's a couple of different ways
that you can look at the processes and have them displayed
if you're trying to find a process ID to kill
or to get more information on.
Couple of other switches that may be of interest to you
in processing the output, you can look at
all the processes owned by a specific parent
with the dash capital P or dash dash parent
and then you have the parent process ID.
And you can list all the different processes
that are owned by that parent.
If you want to look for parent IDs
an easy way to find that out is using the top command,
you would have to add that extra field of parent process ID.
And when you do that, you can get a list of parent processes.
You can sort them by parent process ID
and then you can use P grip grip
if you want to see other parent process IDs.
You can use dash S or dash dash session
to show only process IDs of a given session,
process P pids of a given session ID, dash T
or dash dash terminal will show all the processes
that were executed in that specific terminal.
Now when you specify the terminal, all right,
you just specify like TTY zero or TTY one,
you don't specify the slash dev and then the terminal.
So you don't specify the full path to the terminal,
slash TTY zero, one, one, two, whatever is just enough.
If you try and pass the full path,
you'll get nothing in return.
If you're looking for processes that have been run
by a specific user that you wanna maybe look at killing
or whatever or find out what processes are running
by a specific user, there's two options for that.
There's the dash U or dash dash EUID,
which matches on the effective user ID.
Now you might be saying to yourself,
what does that mean, Dan?
What is the difference between effective
and the other option real user ID?
Well, I'm going to tell you that right here.
What you're going to get from the lower case you,
the effective user ID is what ID the process
is currently running under.
Now, which may or may not be the user ID
the process was started as.
So be aware of that.
If something happened like a patchy, when it starts up,
runs the initial startup as a root user
and then launches other instances of the Apache
as the non-root user, whatever user County Patchy
is supposed to run under.
So in situations like that, or if a process
has elevated or changed privileges with the SUID
or something like that, it's been real changed.
That will show you the effective user ID
or what the ID the process is currently
using running under as opposed to the dash capital U
or otherwise known as the dash UU, dash dash UID,
which is the real user ID.
Now, that is the ID of the user,
the process was started as.
And again, remember, those two user ID and real,
effective user ID and user ID could be different,
but it's going to give you all the processes
that the user was started as that user.
So you might get different responses
with those two, just be aware of that.
So that's the dash U for effective user ID,
dash capital U for real user ID.
Continuing on, you can look at processes
by group ID and that is a capital G or dash dash group.
And that'll match on processes
whose real group ID is the group ID list.
Now, an example of using these is,
I have a user account on the system
and my username is Dan and my user group is 1000
and I'm sorry, my user ID is 1000,
the numerical ID and the user group is 100, I believe.
So if I were to pass dash U, Dan or dash U 1000,
it would return all the processes
owned by that user account right there
or running as that user account.
Whereas, dash G, capital G, 100,
or the group name is going to return the values,
processes that are running as that group.
Now, there could be a bunch of users
on the system all under the same user group
and it will return all those processes by those users, okay?
So you could pass the group ID or the group name.
Now, I say capital G and that's important
because there is a small G, dash G or dash dash P group
will return all the group IDs by a process group, okay?
We talked about process groups in top.
So just remember,
processes could be under the same process group
and you could return those with a lower case G,
all those processes and then passing the process group.
You could find process groups
or see different process groups with the top command
and turn that field on for process group
and you can see different process groups
that different processes belong to.
You can do an exact, now when searching with P greps
or even with P kill because a lot of these commands
and switches are shared between the two.
Grep works just like a regular Grep expression
where whatever you pass to it,
it looks through the process list for that match.
So in a sense where I said X term, okay?
If I would just pass term to it,
I mean just term, I would get X term, A term, R term,
anything that has term in it would come back, okay?
But if you wanted to do an exact match
to say only things that's, only thing that says term,
then it would be a dash X or dash dash exact.
So the process name is what, it has to be an exact match
that would only return a process whose name is term
and that's it, all right?
So just be aware of that, how Grep works.
There is the inverse option just like in regular Grep
with the dash V or dash dash inverse.
So if I were to say P grep dash V, X term is going to return
all the processes that aren't X term, okay, are not X term.
So it's an inverse right there.
Now I want to make sure you kind of understand
another thing about how the process matching works
with regards to just standard matching and exact matching, okay?
In both instances, exact match and regular is with the dash L.
If I executed X term and I did a full listing,
all right, looking for X term and I did a full listing,
it would come back, that would be a dash A, full path command.
I would get both X term and user bin X term in the executables
and either one of those exact matches
because it's just looking at the process name,
not the full path, okay?
So even though the full path with a dash A listing
would show X term and user bin X term is being returned,
both regular, rep and exact match match on just the process name.
Now there's a switch to match on the full command line
and that's dash F and that produces different results.
So if I did P grep dash F X term,
I'm going to get that same output that I had before.
I'm going to get both X term and user bin X term, okay?
And that's in that instance right there.
So if I did a P grep dash F A X term,
I'm getting both of those.
But if I do a P grep dash F A X X term,
I'm only getting one because I'm telling P grep
to match on the full command line and to match exactly.
And I passed X term and that's the only thing
I get returned to me is that process X term
that matches on that full command line.
It's not going to return to me the process
where the full command line is user bin X term, okay?
Be just be aware of that.
That's the way that the matching kind of works,
different things that you can do with matching there.
So to re-peat or re-evaluate what we just said there
for matching purposes, grep, P grep by itself
with no switches matches on the process name,
any match that comes up.
So term gives you X term, A term, X term gives you
all processes with X term.
Regardless of whether they were executed X term
or user bin X term, whatever the full command
listing shows it will return X shows an exact match
on the process name.
So you're going to get a full return of X term
or user bin X term, okay?
But dash F is going to do a full search
on the process name itself, the full command line.
So anything that has term, X term,
in the full command line, it will return.
Whereas dash F, A, an exact match on the full command line
is going to only return the exact match
on the entire command line right there.
You will not get, if you just said X term,
you will not get user bin X term.
If you said user bin X term,
you're not going to get just X term.
Now let's review one more thing with regards to that.
Remember when I said that we did this on Chromium
and we saw if you have Chromium running,
you can see this for yourself.
You have a lot of Chromium processes running.
And chances are there isn't one single one
called Chromium.
So if you were to do an exact match, F A X,
for instance, on Chromium, you're not going to get a response
back, you're not going to get anything back, okay?
If you do a dash F, A, on Chromium,
you're going to get a lot of response back.
But the dash F A X, you're not going to get anything back, okay?
Because, or F A X, actually, you would get something back.
You'll get a whole list of just whatever thing is running,
just called Chromium.
But if you do a full path, user lib Chromium,
Chromium, which is what you'll see,
you're going to get a different result back
because it's going to give you only those processes
where the full path and the full path alone
is going to be user lib Chromium Chromium,
but it's not going to show you the user lib Chromium Chromium
with any switches because there's going to be
a whole bunch of them.
If you just do P grab dash A Chromium,
you're going to see a whole list of things,
the exact same match.
So remember, it's an exact match on the full command line
with switches.
So just be aware of that.
I hope I hammered that home well enough
and you fully understand what you're getting into there.
All right.
We've pretty much exhausted P grab right there.
There's only one other thing that would possibly
be useful in P grab and that is delimiter, dash D
or dash, dash, delimiter.
The output, default output is the show,
each PID, after which a new line is issued.
So you'll see each process ID on its own line.
You can specify a delimiter, dash D or dash, dash,
delimiter, and then put like a colon.
So then each process ID would be separated by a single colon.
If you wanted to do something a little more elaborate,
like have a comma in a space, if you just put a comma in there,
they're only going to be separated by commas.
Whereas if you want to do something like a common space,
put them in quotes or double quotes.
So it'd be like double quote, comma space, double quote,
and then you'll get more than one character in between there.
If you wanted to do, if you actually
wanted quotes or double quotes in there,
you would put like a double quotes inside a quotes,
or you could put a single quote inside a double quotes,
or you can escape them with a backslash character.
So we'd escape it so that it goes to say,
OK, we're going to include this double quote into the delimiter.
There's a couple of things that you can do there.
Now let's move on to Pkill.
Pkill takes all the same switches,
or pretty much all the same switches,
that P-Grep accepts.
But instead of displaying the output,
it sends a signal to those processes.
And now the default signal is the SIG term,
or termination, or dash 15, the number.
Just like we talked about in the kill command,
that's the default signal that'll send.
You can specify a different signal with the dash, dash,
signal option, or with just the dash, signal, dash.
But what I mean by a dash is like a dash nine,
a dash, SIG term, a dash term.
Any one of those are acceptable,
or you can spell out signal in its entirety,
and then provide the signal afterwards.
So again, Pkill X term sends the default SIG term,
signal 15, to the process, to terminate it.
Other ways that you can do that, Pkill dash 15,
Pkill dash, terminal capital letters,
Pkill dash, SIG terminal capital letters,
Pkill dash dash, signal space terminal capital letters,
Pkill dash dash, signal space 15,
terminal capital letters, Pkill dash dash,
SIG terminal space, SIG terminal capital letters,
all do the same thing, okay.
Now remember, you could pass any of the signals
acceptable, some of the more common ones you'll pass
are like hang up, SIG hub, SIG kill, and SIG term.
We discuss those all in the kill episodes,
head on over and watch that.
You can kill processes by group IDs, user IDs,
process group IDs, just like the PGREP command accepts,
you can use those to kill those processes.
You're probably not gonna wanna use the dash C
with Pkill or a count,
because, well, you probably would.
You can do the exact match, pattern matching,
you can do the inverse thing.
I would really be careful about doing something
like inverse and killing all things by a process group ID,
unless you absolutely know for sure
that's what you wanna do.
If you're looking to kill a process like Chromium,
it's gone haywire, Pkill space Chromium
should do the job just fine, in 99% of the cases.
You're not going to get a response back from Pkill
unless you have, provide the dash E or the echo.
Switch, Pkill will echo out, what it has done.
That could be handy, but chances are you'll see
the results right away.
Then there's a couple of switches to switches
that do not really do anything for PGREP,
but are more for Pkill.
And that's the dash capital F or dash, dash,
hit file and supplying a file with the pit in it.
Now, if you read the man page, you might think,
well, all I could have to do is just get a list of process IDs
and do a file that I wanna kill
and pass it to Pkill with the dash capital F.
Well, that's not gonna work.
What's gonna happen is in that list of process IDs,
all it's going to do is kill the first process ID
and ignore the rest.
Generally speaking, the dash capital F is used
in scripts for primarily like starting
and stopping damons and stuff.
When something like a damon starts up,
it writes out to a pit, it specifies a pit file,
a process ID file, usually in far run,
you'll find those process ID files that does,
like SSHD.pid.
So when the process goes to kill, the script goes to kill,
it calls Pkill and then dash capital F
and then dollar sign Pid file.
So it'll go to far run SSHD.pid
and pull the process ID out of there and kill it.
There's a control switch in there
that you can use, which is dash capital L
or it's dash dash log ID file.
It's essentially a lock file
and that will prevent Pkill
from killing the process.
It'll fail if the pit file is not locked.
Now, what locking is, is some processes
put in a lock file in place that if you try
to initiate another instance of the process,
it would look to see if there's a lock file to,
and if there's a lock file there,
refuse to run the process or that part of the process.
And it's largely done so that if a process is running
and you don't want a similar process
consuming the same types of resources,
you use a lock file and do a check for a lock file
to prevent other processes from running
to doing the same thing.
A great example is package managers.
Typically speaking, if you're running a package manager
like Yum, App or PacMan
and you're doing something like an update or an install,
while that package manager is performing that activity,
if you try to run a second instance of that package manager
to install or upgrade or something,
it will tell you it's already running.
So it's checked for a lock file
and it doesn't want two instances
of the same process running
because you could screw up your system
or you could screw up the package manager's database
and controls and everything.
So you don't want those two things going on
at the same time.
So it sees, looks to check if there's a lock ID
and if there is, it prevents that other process from running.
Sometimes you could do stuff like searches
with your package manager and stuff like that
while it's performing an upgrade,
maybe sometimes you can't.
But that's kind of what a lock file does.
So if you do the dash L option
and there's no lock file, it will fail p-kill
and that's the way that that operates.
So that's pretty much p-kill and p-grep in a nutshell.
Very handy commands for being able to kill processes.
Just be careful with using these
because unlike kill, which makes it a little more difficult
to kill processes by name
or a whole group of processes,
you can, but you gotta go through a little more work.
P-kill makes it very easy to kill a whole bunch
of processes if you have permissions to do so.
My name is Dan Washco.
This is Linux and the Shell.
P-grep and p-kill, thank you for listening.
Head on over to your website to get the full skinny
on these commands and look at the notes
and get more information on these concepts.
And I thank you, support Hacker Public Radio
and we'll be back soon.
You have been listening to Hacker Public Radio
where Hacker Public Radio does our.
We are a community podcast network
that releases shows every weekday
Monday through Friday.
Today's show, like all our shows,
was contributed by a HBR listener like yourself.
If you ever considered recording a podcast,
then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the Digital.Pound
and the Emponomic and Computer Club.
HBR is funded by the binary revolution
at binref.com.
All binref projects are crowd- Exponsored by linear pages.
From shared hosting to custom private clouds,
go to lunarpages.com for all your hosting needs.
Unless otherwise stasis,
today's show is released under a creative commons,
attribution, share a like.
Three does our license.