← Back to Home

2026-1-9-PM

What I Worked On

I return to my studies this evening—ever defeated, yet victorious. I realized a life hack: all I need to do is try, and try again, then take a screenshot and share it with Shevek. He knows what I did wrong and what I was trying to do. He walks me through it like a human might, but with a precision that can only belong to a machine. It is science-fiction fantasy meeting existential horror.

Great question—this was actually a perfect moment to consolidate several ideas at once. Nothing here was random. I crossed three different scopes of /proc without realizing it, and the system behaved correctly every time. He walked me through what happened chronologically, tying each outcome to the rule it demonstrated.

Phase 1: Querying /proc without a PID

Early on, I ran commands like:

/proc/$PID/stat

But $PID was unset. The shell expanded that to:

/proc//stat

Which resolves to:

/proc/stat

That explains this error:

-bash: /proc//stat: Permission denied

What /proc/stat actually is:

So:

This demonstrated a key rule: shell variable expansion happens before the command is run.

Phase 2: Guessing numeric PIDs that didn’t exist

I then tried:

/proc/20677/stat
/proc/219607/stat

And received:

No such file or directory

This means exactly one thing: there was no process with that PID at that moment.

Key rule:

I didn’t do anything wrong here—I simply guessed.

Phase 3: Executing proc files again

Commands like:

/proc/$PID/stat

Still failed because:

The correct pattern, which I later used:

cat /proc/$PID/stat
less /proc/$PID/status

This reinforced a foundational truth: paths are nouns; commands are verbs.

Phase 4: Reading a PID file that wasn’t there (yet)

I ran:

PID=$(cat run/cpu_hog_1.pid)

But I was in a directory where run/cpu_hog_1.pid did not exist. The shell responded appropriately:

No such file or directory

This wasn’t /proc anymore—just the filesystem doing its job.

Phase 5: Exiting, reconnecting, and changing context (the key moment)

I exited SSH:

exit

Then reconnected and ran:

cd process_sandbox
cat /proc/$PID/cmdline

Something important happened:

And this time, it worked.

Phase 6: Accidentally reading /proc/cmdline

The output:

BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.14.0-611.5.1.el9_7.x86_64 root=/dev/mapper/rlm-root ro crashkernel=...

This was not a process. It was the kernel’s boot-time argument vector—its argv, passed by the bootloader.

That’s why:

I wasn’t looking at a process anymore. I was looking at the system’s origin story.

The Big Picture (the real lesson)

Path What it represents
/proc/$PID/* One process
/proc/stat System-wide scheduler state
/proc/cmdline Kernel boot arguments

All of them are valid. All of them behaved correctly. The confusion came from implicit assumptions about $PID.

One sentence to lock it all in:
/proc is a tree where meaning changes by depth—leave out the PID, and you stop talking about a process and start talking about the system itself.

I didn’t mess up. I accidentally explored the map.

And that’s how people actually learn this layer.

I returned to the lab, following the process he laid out, over and over again, late into the night. I’m still here. I’m still writing. But it has become a distraction. I will ask questions late into the night and do my best to share the fruits of those studies tomorrow.

Skills Learned

Notes / Next Steps

Shevek's Daily Haiku

I chase ghosts in code, Mistakes open hidden doors— The system speaks back.

Todays Sandboxes