Day 5 - Week 6 Comprehensive Review: Tying Processes, Initialization, and Scheduling Together on One Page

📌 Key Takeaways

• This week in one sentence: Linux's dynamic world starts from a single process (PID 1), grows into a tree, talks through signals, and works according to a timetable (cron).
• Viewing: ps aux (usage, bare) / ps -ef (PPID, hyphen); controlling: signal order 15 → 9. Only 9 and 19 cannot be blocked, and negative nice is root-only.
• The life cycle is fork (new PID) → exec (PID kept). Zombie = dead child + parent that doesn't collect it (dangerous), orphan = living child + dead parent (adopted by PID 1, harmless).
• Initialization is all about the runlevel ↔ target mapping — 2, 3, 4 → multi-user, 5 → graphical, 0 and 6 are forbidden as defaults. start (now) and enable (every boot) are separate.
• Scheduling uses the "min-hour-day-month-weekday" 5 fields (weekday 0 and 7 = Sunday), and a system crontab adds a user field for 6 fields. cron = recurring, at/batch = once.

Review of Process Identification and Control (Day 1)

• Signals are the only means of talking to a process. Memorize the numbers.

• Priority is set with the nice value (-20 to 19, default 0). Lower means higher priority, negative is root-only, nice is for launch time and renice for running processes.

⚠️ Trap review: Don't mix ps aux (bare) and ps -ef (hyphen). Terminate in the order 15 (graceful) → 9 (forced). Only 9 (SIGKILL) and 19 (SIGSTOP) cannot be blocked. Negative nice is root only. kill works by PID, killall/pkill by name.

Review of the Process Life Cycle (Day 2)

• A new process is born by fork (copy) → exec (replace). fork creates a child with a new PID, and exec keeps the PID and changes only the program.
• Job control: & (background), Ctrl+Z (stop), bg, fg, jobs, nohup.
• Zombies and orphans are exact opposites.

⚠️ Trap review: "Zombie = dead child + parent that doesn't collect it, orphan = living child + dead parent (adopted by PID 1)". A zombie can't be killed with kill -9; you have to deal with the parent. Ctrl+Z is a stop (T), not termination. exec doesn't create a new process (PID kept).

Review of System Initialization (Day 3)

• The runlevel ↔ target mapping is the key.

• The start/enable distinction in systemctl is important.

0 and 6 are forbidden as the default runlevel. 2, 3, and 4 are all multi-user.target. start (once, now) and enable (auto at boot) are separate. daemon-reload is required after editing a unit file. [Install] WantedBy= is the target that enable links to. Logs: journalctl -u service -f.

Review of Job Scheduling (Day 4)

• crontab 5 fields: minute (0-59) hour (0-23) day (1-31) month (1-12) weekday (0-7, 0·7=Sun).
• Build patterns with the symbols * , - /, and specifying both day and weekday is OR.

The order is "min-hour-day-month-weekday". Weekday 0 and 7 = Sunday. A user crontab has 5 fields, /etc/crontab has 6. cron = recurring, at/batch = once. allow > deny in priority. crontab -r deletes everything, so be careful. The at list is atq, deletion is atrm.

Scenarios That Often Intertwine — Integrated Thinking

Scenario A — Safely terminating a runaway process

ps aux --sort=-%cpu | head      # identify the process hogging the CPU
pgrep -l runaway                # get the exact PID
kill -15 1234                   # try graceful termination first
kill -9 1234                    # force termination if that doesn't work

• Integrates Day 1 (ps, pgrep, signals 15 → 9).

Scenario B — Registering a new service + auto-start + checking logs

vi /etc/systemd/system/myapp.service   # write the unit file
systemctl daemon-reload                # make systemd notice the change (required)
systemctl enable --now myapp           # register + start immediately
systemctl status myapp                 # check active/enabled
journalctl -u myapp -f                 # follow logs in real time

• Integrates Day 3 (unit, daemon-reload, enable, journalctl).

Scenario C — Automating a daily backup at dawn

crontab -e
# 0 3 * * * /usr/local/bin/backup.sh   # every day at 3 a.m.
crontab -l                             # confirm registration

• If the backup script is heavy, yield with nice or run it with batch when the system is idle — integrates Days 1, 2, and 4.

The standard flow of real-world incident response is exactly this order — find the culprit with ps/top (Day 1), stop it safely with signals 15 → 9 (Day 1), restart the service cleanly with systemctl (Day 3), check the cause in the logs with journalctl (Day 3), and set up an inspection job in cron to prevent recurrence (Day 4). This week's content is the backbone of real-world operations, not just of the exam.

📖 Glossary

• PID 1 : The first process the kernel starts (init/systemd). The ancestor of all processes, the star of initialization, and the adopter of orphans.
• Signal : A numbered notification sent to a process. 1 HUP (reload) · 2 INT (Ctrl+C) · 9 KILL (forced) · 15 TERM (default) · 19 STOP (stop).
• Unblockable signals : 9 (SIGKILL) and 19 (SIGSTOP). A process cannot catch or ignore them.
• Nice value : A value from -20 to 19 indicating how much CPU a process yields. Lower means higher priority, and only root can give negative values.
• fork / exec : Copying itself to create a child with a new PID / keeping the PID and swapping out only the executing code.
• Zombie / orphan : A dead child the parent hasn't collected (Z, dangerous) / a living child adopted by PID 1 after its parent died first (harmless).
• Runlevel ↔ target : SysV's 0-6 states and systemd's bundled-state units. 2, 3, and 4 merge into multi-user, and 5 into graphical.
• start vs enable : Turning on once now / registering to turn on automatically at every boot. enable --now does both.
• daemon-reload : A command that makes systemd re-read the disk contents after you edit a unit file. If you forget it, the service runs with the old settings.
• crontab 5 fields : minute-hour-day-month-weekday. Memorize it as "min-hour-day-month-weekday", and for the weekday both 0 and 7 are Sunday.
• at / batch : Run once at a specified time / run once when the system load drops. Both are handled by the atd daemon.