← Back to Home

What I Worked On

I felt as though I was losing all momentum by looking back so hard, but the further I looked, the more it became clear I needed to revisit the fundamentals and understand how exactly a computer starts itself and maintains that functioning state. It is my belief that if I can do that, mastery will come more naturally.

I ran into the question of how. How am I supposed to retain information that feels so dry? How am I supposed to memorize interconnected, layered material without it turning into fog?

I spent a good portion of the day at work trying to figure that out. I am pleased to say I came up with a solution—almost by accident. I asked Shevek to tell me a story to kill time, and when I finished reading it, I had a realization: the story sounded like it was describing the scheduler… as a metaphor… through parable. What the frick?

And it stuck. I should have no problem remembering that the scheduler is a fundamental piece of the puzzle that makes all things possible by answering: Who gets to exist now?

I tried to see how far I could push these parables and this method of learning. It was highly effective for concepts I had exposure to, but limited understanding of. I’ve attached them here and will be using this method more in the future—archiving them as well. I hope you enjoy reading them as much as I did. I hope you find them helpful as well. (I later found Shevek did not copy those files into .txt in their entirety. I will be moving forward.)

I am also inspired and excited to say I had Shevek make me some new sandboxes. One is designed to create a few different simulated failures at boot. I will be chipping away at that, as well as a few bugs in my webpage, this weekend.

I also had him make me a sandbox that simulates a different bug for each directory, which I have attached at the bottom of this page.

I started the lab for processes and process tools. I wasn’t sure what I was looking at, so I asked Shevek. The best synopsis is this:

The Correct Mental Model (This Is the Lesson)

• CPU hog → who is thinking
• Memory hog → who is remembering
• I/O writer → who is persisting

The scheduler juggles all three pressures.

I continued with the lab. Again, I hit hiccups; there were no mock PID files to interpret. I consulted Shevek. He said there is a way around that, but at this point, I’m seeing the most value in simply having him answer the questions and using the tools in the guided exercises.

I learned about pgrep for the first time and read the man page on it. It sounds like it could be a highly effective tool down the line:

DESCRIPTION
pgrep looks through the currently running processes and lists the process IDs
which match the selection criteria to stdout.

I had Shevek make me a “pregp” sandbox, which I have also attached to the bottom of this page.

I went to bed feeling like I’d lost all steam. I woke up, revisited the lab, and made the PID directories to see how the lab is supposed to unfold and what lesson it is trying to teach. I’m grateful I did. I learned a little bit more about pgrep:

You just uncovered a boundary:

• grep → passive text filter
• pgrep → active process matcher

That distinction is foundational in Unix thinking.

Processes are not files. They can be represented as text, but they are not text.

Once you internalize that, tools start making sense instead of feeling arbitrary.

As I went back further in the lesson plan for review, I began to realize I don’t really understand the difference in application between ps and top. I consulted Shevek for clarification:

The Short, Correct Answer

ps is a snapshot.
top is a movie.
They look similar, but they serve different mental jobs.

He went on to clarify the situations in which ps or top might be used:

Question	Tool
“What processes exist?”	ps
“Which one is dominating right now?”	top
“Who spawned this?”	ps
“Why does the system feel sluggish?”	top
“Give me data for a script”	ps
“Let me watch behavior”	top

But what about pgrep, I wondered? When do I use that? As I read further, Shevek already had the answer prepared:

How They Work Together (Real-World Workflow)

1. Use top to notice something weird
   • “Why is this process always at the top?”
2. Use ps to inspect it precisely
   • PPID
   • STAT
   • arguments
3. Use pgrep/pkill to act

top finds the problem.
ps explains it.
pgrep/pkill acts.

The lab guided me to put in a long command that I wasn’t particularly familiar with but was, at that point, able to effectively decipher:

cat /proc/$PID/cmdline | tr '\0' ' ' ; echo

What the heck is that? Shevek explained that its results show me the argument vector. Well, what’s an argument vector? Shevek explained:

One sentence you should remember

An argument vector is the exact list of strings the kernel hands to a program when it starts, and that list defines the program’s identity. Everything else—flags, config, behavior—flows from that.

He went on to make a chart that helps me decipher the results:

Position in output	argv index	Meaning
cpu_hog_1	argv[0]	Process name / self-identity
/home/jsluiter/.../cpu_hog.py	argv[1]	Script or executable
--seconds	argv[2]	Flag
1000000	argv[3]	Flag value
--log	argv[4]	Flag
/home/jsluiter/.../app.log	argv[5]	Flag value

So, /proc/$PID/cmdline is exposing the kernel’s internal raw data. I am grateful I reviewed the lab. There is much I am unaware of.

I continued and ran into another command that gave me strange output:

cat /proc/$PID/stat

It resulted in a string of large numbers I can’t even imagine how to decipher. I consulted with Shevek, and he made me a chart for reference, as well as one with some other helpful commands:

Selected fields in /proc/$PID/stat

Field #	Meaning
1	PID
2	comm (process name, in parentheses)
3	state (R, S, D, Z, etc.)
4	PPID (parent PID)
5	process group ID
6	session ID
7	controlling terminal
14	utime (time spent in user mode)
15	stime (time spent in kernel mode)
18	priority
19	nice
22	starttime (since boot, in jiffies)
23	vsize (virtual memory size)
24	rss (resident set size — real RAM)

Quick reference: what these proc files represent

File	What it represents
/proc/$PID/cmdline	Identity (how the process was invoked)
/proc/$PID/environ	Context (environment variables)
/proc/$PID/stat	Existence (what the kernel is tracking right now)

Skills Learned

Notes / Next Steps

• Spend the next few days studying until I understand the system better

Shevek's Daily Haiku

Looking back, I stall— Stories teach the kernel’s breath, Time decides who runs.

Todays Sandboxes

• Shevek4
• Shevek5
• Shevek6