5. Processes, Services and Job ControlIntroduction and ContextA Linux system is not merely a collection of files and commands. It is a continuously operating environment in which programs execute, communicate, consume resources, respond to events, and often restart or terminate according to administrative policy. The running instances of programs are processes; long-running background processes are commonly organized as services or daemons; commands launched interactively are managed through job control; and repetitive tasks are scheduled through mechanisms such as cron and systemd timers. For DevOps professionals, process and service administration is central to reliability. A web server that is installed but not running provides no business value. A database process that consumes all available memory can make an entire host unstable. A scheduled backup that silently fails is more dangerous than a visibly failed backup because it creates false confidence. Effective administration therefore requires more than memorizing commands. It requires understanding process life cycles, signals, priorities, resource boundaries, service dependencies, scheduling semantics, and operational evidence. This chapter examines these subjects as an integrated management problem. It begins with the Linux process model, then considers signals, priorities, limits, interactive jobs, service supervision, scheduling, dependencies, and operational practices. The discussion assumes familiarity with the command line, permissions, filesystems, and basic shell scripting. Learning ObjectivesBy the end of this chapter, the learner should be able to: - explain how Linux creates, tracks, schedules, and terminates processes;
- interpret process states, parent-child relationships, process identifiers, and exit statuses;
- select appropriate signals and terminate processes safely;
- analyze CPU and memory priorities using niceness and related controls;
- apply background execution, job control, and terminal-independent execution methods;
- distinguish cron jobs from systemd timers and select an appropriate scheduler;
- design systemd services with suitable dependencies, restart policies, limits, and security controls;
- diagnose service failures using logs, status information, and dependency analysis;
- identify common operational, security, and reliability risks in process and service management.
The Linux Process ModelA process is a running instance of a program together with its execution context. The program is a static file containing instructions and data; the process is the active entity created when those instructions are loaded and executed. A process has a process identifier (PID), an address space, open file descriptors, environment variables, credentials, scheduling attributes, signal dispositions, and relationships with other processes. Most user-space processes originate through a combination of `fork()` and `execve()`. A calling process first creates a child process, commonly by using `fork()`. The child initially resembles the parent, including inherited file descriptors and environment information. It may then call an `exec` function to replace its memory image with another program. Shells use this model when launching commands. Modern Linux also provides `clone()` and related mechanisms, which support threads and containers by allowing selected resources to be shared. Each process has a parent process identifier (PPID). The process tree can be viewed with commands such as: ```bash ps -ef pstree -p ps -o pid,ppid,user,stat,ni,%cpu,%mem,cmd -p 2481 ``` The process with PID 1 is the initial user-space process. On most contemporary distributions it is `systemd`, although other implementations are possible in specialized environments. PID 1 has a special responsibility: it adopts orphaned processes and must reap terminated children. In a service-managed system, PID 1 also coordinates service activation, supervision, logging integration, and shutdown. Process states and life cycleA process moves through several conceptual states. A running process is currently executing on a processor or is eligible to do so. A runnable process is waiting for CPU time. A sleeping process is waiting for an event, such as input from a device or completion of disk I/O. A process may be stopped by a job-control action or signal. A terminated process remains briefly as a zombie until its parent collects its exit status. The `STAT` field in `ps` provides abbreviated state information. `R` indicates running or runnable, `S` generally indicates interruptible sleep, `D` indicates uninterruptible sleep, often while waiting for kernel I/O, `T` indicates stopped, and `Z` indicates zombie. A zombie does not continue consuming CPU or ordinary memory, but it occupies a process-table entry. Killing a zombie directly is ineffective because the process has already terminated; the parent must reap it, or the orphaned zombie must be adopted by a suitable reaper. A process returns an exit status when it terminates. By convention, zero indicates success and a nonzero value indicates some form of failure or exceptional condition. Shell scripts can inspect the most recent status through `$?`, while conditional operators such as `&&` and `||` use this status to determine control flow. A process terminated by a signal may be represented by a shell status related to the signal number, but scripts should avoid assuming a universal numeric interpretation without considering the execution environment. Threads and processesA process may contain one or more threads. Threads share an address space and many process resources, but each thread has its own execution state and stack. A multithreaded service can therefore appear as one process with several schedulable entities. The distinction matters during diagnosis: a process-level CPU percentage may conceal a single overloaded thread, while a thread-level view can identify the precise execution path. Tools such as `top -H`, `ps -L`, and service-specific diagnostics assist with this analysis. Inspecting resource consumptionProcess inspection should combine identity, state, resource use, and command information. Useful commands include: ```bash pgrep -a nginx pidof sshd ps aux --sort=-%cpu | head ps aux --sort=-%mem | head top free -h lsof -p 2481 ``` `lsof` is particularly useful when a process is suspected of holding a file, socket, or deleted log file open. A process can continue consuming disk space through an unlinked file until it closes the associated file descriptor. This is a frequent explanation for apparent discrepancies between filesystem usage and directory listings. Signals: Communicating with ProcessesA signal is an asynchronous notification delivered by the kernel to a process or process group. Signals provide a compact control mechanism, but they do not all have the same meaning or degree of cooperation. `kill` sends a signal; it does not necessarily terminate a process. For example: ```bash kill -TERM 2481 kill -HUP 2481 kill -l ``` `SIGTERM` requests orderly termination. A well-designed program catches it, stops accepting new work, closes resources, and exits. `SIGINT`, commonly produced by pressing `Ctrl-C`, requests interruption of a foreground command. `SIGHUP` historically represented terminal disconnection and is also commonly used by daemons to request configuration reload. `SIGSTOP` forcibly stops a process and cannot be caught or ignored, while `SIGCONT` resumes a stopped process. `SIGKILL` immediately terminates a process and cannot be caught, blocked, or handled by the target. The normal administrative sequence is to identify the correct process, send `SIGTERM`, wait, inspect the result, and use `SIGKILL` only when justified. Premature use of `kill -9` can interrupt transactions, prevent cleanup, leave locks, corrupt application-level state, or conceal the actual defect. A service manager may also restart a process immediately, making repeated killing ineffective unless the service is first stopped or its restart policy is considered. Signals can be sent to process groups. This is important when a shell command launches child processes. Killing only the visible parent may leave descendants running. Conversely, indiscriminately signaling a process group can terminate unrelated work if group membership is misunderstood. Administrative scripts should use stable identifiers and clear ownership rather than parsing fragile output from commands such as `ps`. Permissions govern signal delivery. A user can generally signal processes that it owns, while signaling another user’s process requires suitable privileges. Even root should apply the principle of least privilege and verify the target, particularly on production systems where an incorrect PID can cause an outage. Scheduling, Priorities, and Resource BoundariesLinux schedules runnable tasks according to scheduling policies and priorities. Ordinary user processes use a dynamic priority influenced by niceness. Niceness is an advisory value usually ranging from -20, which favors CPU access, to 19, which makes a process more willing to yield. The command `nice` starts a process with an adjusted niceness, while `renice` changes the value of an existing process: ```bash nice -n 10 ./batch-report.sh sudo renice 15 -p 2481 ``` A higher nice value generally lowers CPU priority. Decreasing niceness, thereby increasing priority, normally requires elevated privilege because it can disadvantage other workloads. Niceness is not a guarantee of CPU allocation, and it does not solve memory pressure, I/O bottlenecks, or poor application design. Linux also supports real-time scheduling policies such as `SCHED_FIFO` and `SCHED_RR`. These policies are powerful and potentially hazardous. A runaway real-time process can starve ordinary tasks, including administrative shells. They should be used only with clear requirements, bounded execution, and operational testing. Resource limits constrain what a process or user can consume. The shell exposes soft and hard limits through `ulimit`, while system services may use systemd directives or cgroup controls. Common limits include maximum open files (`nofile`), maximum processes (`nproc`), core-dump size, virtual memory, and locked memory. A soft limit is the current effective boundary; a hard limit is the maximum to which the soft limit may be raised without greater privilege. ```bash ulimit -a ulimit -n 4096 ``` Limits should be designed from workload requirements rather than copied blindly. Raising the open-file limit may be necessary for a high-connection service, but it does not repair file-descriptor leaks. Limiting the number of processes can protect a host from fork bombs, yet an excessively low value may prevent a legitimate worker pool from starting. Control groups, or cgroups, provide stronger resource accounting and isolation by grouping processes. They can limit or measure CPU, memory, I/O, and process counts. Systemd uses cgroups to organize services, making it possible to inspect service-level resource use and apply directives such as `MemoryMax=`, `CPUQuota=`, `TasksMax=`, and `IOWeight=`. Cgroups are especially important in containerized and multi-tenant environments. Interactive Job Control and Reliable Background ExecutionA shell associates commands with jobs. A foreground job owns the terminal and can receive terminal-generated signals. A background job is not normally allowed to read from the terminal and does not block the shell prompt. The basic controls are: ```bash long-command & jobs -l fg %1 bg %1 ``` Pressing `Ctrl-Z` sends `SIGTSTP` to suspend the foreground job. `bg` resumes it in the background, and `fg` returns it to the foreground. The shell’s job number, such as `%1`, is not the same as the process PID. Confusing the two can result in an invalid or dangerous command. Appending `&` is suitable for short-lived interactive work, but it is not a complete service-management strategy. When the terminal closes, a shell may send `SIGHUP` to jobs associated with that session. `nohup` can protect a simple command from hangup, while `disown` removes a job from the shell’s job table: ```bash nohup ./migration.sh >migration.log 2>&1 & disown ``` Terminal multiplexers such as `tmux` and `screen` preserve an interactive session so an administrator can disconnect and later reconnect. They are useful for manual operations, but repeatable production workloads should normally be represented as systemd services, scheduled jobs, or workflow-managed tasks. A process kept alive in a personal terminal session has weak ownership, limited auditability, and uncertain restart behavior. Output and error handling are part of job reliability. A background command should have deliberate destinations for standard output and standard error, appropriate file permissions, and a rotation or retention policy. Otherwise, output may disappear, fill a filesystem, or expose sensitive information. Services and Daemons Under systemdA daemon is a background process that provides a function without requiring an interactive terminal. A service is the operational unit used to start, stop, supervise, and describe such work. The terms overlap, but a service may also represent a group of processes or a one-shot administrative action. Systemd manages units, including service units, socket units, target units, mount units, path units, and timer units. Common commands include: ```bash systemctl status nginx.service sudo systemctl start nginx.service sudo systemctl stop nginx.service sudo systemctl restart nginx.service sudo systemctl enable nginx.service sudo systemctl disable nginx.service systemctl is-active nginx.service systemctl is-enabled nginx.service systemctl list-dependencies nginx.service journalctl -u nginx.service ``` `start` changes the current runtime state; `enable` configures a unit to be activated during a relevant boot target. They are distinct operations. A service can be enabled but currently inactive, or active without being enabled for boot. `restart` stops and starts a service, while `reload` asks it to reread configuration without fully stopping, if the service supports that operation. A custom service unit commonly contains `[Unit]`, `[Service]`, and `[Install]` sections: ```ini [Unit] Description=Inventory API Wants=network-online.target After=network-online.target [Service] Type=simple User=inventory Group=inventory WorkingDirectory=/opt/inventory ExecStart=/opt/inventory/bin/server --config /etc/inventory/server.yml Restart=on-failure RestartSec=5 EnvironmentFile=-/etc/inventory/environment NoNewPrivileges=true PrivateTmp=true [Install] WantedBy=multi-user.target ``` `ExecStart` should identify the intended executable precisely. `User=` and `Group=` reduce the consequences of compromise. `Restart=on-failure` supports recovery from unexpected termination, while `RestartSec=` prevents an immediate restart loop. `EnvironmentFile=` can separate deployment configuration from the unit definition, but secrets should be protected and should not be casually placed in world-readable files. The service `Type=` must match the program’s behavior. `simple` treats the process launched by `ExecStart` as the main process. `oneshot` is appropriate for a command that performs an operation and exits. `notify` allows a service to signal readiness through systemd’s notification protocol. Incorrect type selection can cause systemd to report a service as ready before it is actually usable, or to wait indefinitely for a readiness event that never arrives. After changing a unit file, administrators generally run: ```bash sudo systemctl daemon-reload sudo systemctl restart inventory.service ``` Systemd records service output in the journal by default. Diagnosis should examine both the unit state and historical logs: ```bash systemctl status inventory.service --no-pager journalctl -u inventory.service -b journalctl -u inventory.service --since "30 minutes ago" ``` The `-b` option restricts results to the current boot. Logs should be interpreted alongside exit codes, timestamps, dependency failures, resource limits, and application-level health indicators. Dependencies and Service OrderingA dependable service design distinguishes dependency from ordering. `Requires=` expresses a stronger relationship: if the required unit is stopped or fails, the requiring unit may also be stopped. `Wants=` expresses a weaker preference: systemd attempts to activate the wanted unit but does not necessarily fail the requesting unit if it cannot be started. `After=` controls ordering only; it does not cause the referenced unit to start. `Before=` expresses the reverse ordering relationship. For example, a service may specify `After=network-online.target` because it needs network connectivity before startup. This does not, by itself, guarantee that a particular database is running or that the application endpoint is healthy. If a database is an explicit requirement, the unit relationship and application health strategy should reflect that requirement. Overstated dependencies slow boot and create larger failure domains; understated dependencies produce races and intermittent startup failures. Targets group units into operational states. `multi-user.target` commonly represents a non-graphical multi-user environment, while `graphical.target` adds a graphical session. The dependency graph can be inspected with `systemctl list-dependencies`, `systemctl show`, and boot-analysis tools such as `systemd-analyze critical-chain`. A robust service should also tolerate dependencies becoming temporarily unavailable after startup. Application-level retries, timeouts, circuit breakers, and health checks are often more reliable than assuming that a one-time startup order guarantees perpetual availability. Scheduling Work: cron and systemd TimersCron is a long-established scheduler for recurring commands. A crontab entry normally contains minute, hour, day of month, month, and day of week fields, followed by a command. For example: ```cron 15 2 * /usr/local/sbin/archive-logs ``` This requests execution at 02:15 according to the cron daemon’s time interpretation. Cron jobs run with a limited environment, so scripts should use absolute paths, explicitly define required variables, and redirect output. They should also prevent overlapping runs when necessary, using a lock mechanism such as `flock`: ```cron 15 2 * flock -n /run/archive-logs.lock /usr/local/sbin/archive-logs ``` Cron has limitations. It offers relatively little built-in information about missed executions, dependencies, resource controls, and structured logging. Time-zone and daylight-saving transitions also require careful consideration. A job scheduled during a skipped or repeated local time may not behave as an operator expects. Systemd timers provide calendar-based or monotonic scheduling integrated with systemd services. A timer activates a corresponding service, normally with the same base name. An illustrative pair is: ```ini /etc/systemd/system/archive-logs.service[Unit] Description=Archive application logs [Service] Type=oneshot ExecStart=/usr/local/sbin/archive-logs /etc/systemd/system/archive-logs.timer[Unit] Description=Archive logs daily [Timer] OnCalendar=--* 02:15:00 Persistent=true Unit=archive-logs.service [Install] WantedBy=timers.target ``` `Persistent=true` allows a calendar timer to run after the system becomes active if an execution was missed while the host was down. This behavior must be evaluated carefully: a delayed backup may be useful, while a missed job that performs destructive maintenance may be inappropriate. Timers also benefit from service-level logging, dependencies, user identity, resource controls, and restart or timeout policies. The choice between cron and systemd timers should be based on operational requirements. Cron remains appropriate for simple, portable, user-owned schedules. Systemd timers are often preferable for host-level operations requiring journal integration, dependency relationships, missed-run handling, or resource governance. In larger DevOps environments, neither should automatically replace a workflow orchestrator when tasks require distributed coordination, approvals, retries across systems, or complex dependency graphs. An Illustrative Case: Stabilizing a Failing Reporting PlatformBackgroundA fictional organization, Northbridge Retail, operates a Linux virtual machine hosting a reporting API and a nightly data-export task. The API is managed by systemd, while the export is launched from root’s crontab. The machine has eight virtual CPUs and 16 GB of memory. Situation and problemUsers report that the API becomes unresponsive between 02:00 and 03:00. The export script sometimes runs for two hours instead of twenty minutes. On several mornings, two export processes are found running simultaneously. The operations team has been terminating the processes with `kill -9` and restarting the API manually. AnalysisThe team first examines service state and resource use: ```bash systemctl status reporting-api ps -eo pid,ppid,stat,ni,%cpu,%mem,cmd --sort=-%cpu | head journalctl -u reporting-api --since "today 01:30" pgrep -af data-export ``` The evidence shows that the export consumes substantial memory and competes with the API for CPU and I/O. Cron starts a new export even when the previous one is still running. The API unit has no memory boundary and uses a privileged account. Its restart policy is absent, so an unexpected failure leaves it inactive. The export logs are written to a single file without rotation. Strategy and solutionThe export is converted into a systemd oneshot service and timer. The service runs under a dedicated account, uses `flock`-like mutual exclusion through an application lock, receives a memory limit, and writes output to the journal. A timeout is added so a hung export is visible and does not run indefinitely. The timer is marked persistent only after the team confirms that a delayed export is safe. The API unit is changed to use a nonprivileged service account, `Restart=on-failure`, and a controlled restart delay. The team verifies that the API’s readiness behavior matches its systemd service type. Rather than raising CPU priority for the API, they reduce the export’s CPU and I/O impact and schedule it outside the busiest reporting window. Monitoring is added for service restarts, timer executions, duration, exit status, memory pressure, and missed schedules. OutcomeOverlapping exports cease because each execution has a defined ownership and locking policy. The API remains responsive during the export window, and failures become visible in the journal and monitoring system. The team also gains a repeatable deployment definition instead of relying on undocumented manual actions. Learning pointsThe principal lesson is that process termination was treating symptoms rather than causes. Reliability improved through workload isolation, explicit scheduling semantics, service supervision, least privilege, observability, and prevention of concurrent execution. A priority adjustment alone would not have solved the overlap or the missing failure evidence. Operational Risks, Governance, and Professional PracticeProcess and service administration carries significant risks. An incorrect PID, an overly broad shell pattern, or an untested `ExecStart` change can cause production downtime. A service running as root increases the impact of vulnerabilities. Unbounded logs can exhaust storage, while unbounded restarts can create a restart storm and conceal an application defect. Configuration changes should be managed as code, reviewed, tested, and traceable. Unit files, timer definitions, scripts, and schedules belong in version control where practical. Secrets should be supplied through an approved secret-management mechanism or tightly protected files, not embedded in command lines that may appear in process listings or shell history. Administrative access should be logged and governed through role-based permissions. Scheduled tasks deserve the same engineering discipline as application code. They should be idempotent where possible, validate inputs, use explicit paths, handle partial failure, emit useful status information, and return meaningful exit codes. Time-sensitive operations should specify time zones and account for clock changes. Destructive tasks should include safeguards such as dry-run modes, retention checks, and bounded target selection. A service is not reliable merely because systemd reports it as active. A process can be alive while unable to serve requests, reach a dependency, or process work. Health checks, synthetic transactions, metrics, and alert thresholds should complement process supervision. At the same time, excessive automatic restarting can generate noise and increase damage. Restart policies must be paired with rate limits, escalation procedures, and root-cause analysis. Emerging DirectionsModern Linux operations increasingly combine systemd with cgroups, containers, infrastructure-as-code, and centralized observability. Containers still depend on kernel process and signal semantics; a container’s PID 1 must handle child reaping and signal forwarding correctly. Kubernetes and other orchestrators add higher-level reconciliation, but node-level services, timers, resource controls, and logs remain relevant. Event-driven activation is another important direction. Systemd socket, path, and timer units allow work to begin in response to connections, filesystem changes, or time events rather than keeping every component active continuously. This can reduce idle consumption, although activation latency and dependency behavior must be tested. Operational analytics can use process metrics, restart counts, execution duration, exit status, and resource pressure to detect degradation before complete failure. Automation and AI-assisted tools may help correlate logs or suggest likely causes, but automated remediation should be bounded, auditable, and reversible. A recommendation system should not be granted unrestricted authority to terminate processes or alter service definitions without controls. Best Practices for Reliable Administration1. Identify processes using stable attributes and verify targets before signaling them. 2. Prefer graceful termination with `SIGTERM`; reserve `SIGKILL` for justified exceptional cases. 3. Treat PID, PPID, process group, shell job number, and service unit as different identifiers. 4. Use dedicated service accounts and least privilege. 5. Define explicit restart, timeout, logging, and resource policies for important services. 6. Distinguish `enable` from `start`, and `After=` from `Requires=` or `Wants=`. 7. Prevent overlapping scheduled work when concurrency is unsafe. 8. Use absolute paths and controlled environments in cron and timer jobs. 9. Make scheduled tasks observable, idempotent, and safe to retry. 10. Store service and scheduling configuration in reviewed, version-controlled artifacts. 11. Test boot behavior, dependency failure, disk-full conditions, resource exhaustion, and graceful shutdown. 12. Monitor business health, not merely process existence. Chapter SummaryLinux process administration concerns the life cycle, identity, state, resources, and relationships of running programs. Processes are created through kernel-supported process and program-replacement mechanisms, organized in parent-child trees, and observed through tools such as `ps`, `top`, `pstree`, `lsof`, and `journalctl`. Signals provide asynchronous control, with graceful termination preferred over forceful killing. Scheduling priorities, niceness, resource limits, and cgroups help protect workloads and allocate scarce CPU, memory, I/O, and process-table capacity. Interactive job control is useful for command-line work, but production workloads require explicit ownership, logging, restart behavior, and scheduling. Systemd supplies a unified model for service supervision, dependencies, activation, resource control, and journal integration. Cron offers simple recurring schedules, whereas systemd timers provide stronger integration with service state and missed-run handling. Reliable practice depends on more than keeping processes alive. It requires least privilege, clear dependencies, meaningful exit statuses, prevention of overlapping jobs, observable failure, controlled automation, and configuration managed as code. These principles connect Linux administration with broader DevOps goals of repeatability, resilience, and rapid diagnosis. Key TermsProcess: A running instance of a program with execution state and allocated resources. PID: The numeric process identifier assigned by the kernel. PPID: The identifier of a process’s parent. Daemon: A background process that provides a service without interactive terminal control. Signal: An asynchronous notification sent to a process or process group. SIGTERM: A catchable signal requesting orderly process termination. SIGKILL: An unconditional termination signal that cannot be caught or ignored. Zombie: A terminated process awaiting collection of its exit status by its parent. Niceness: A scheduling attribute that influences the CPU priority of ordinary processes. Resource limit: A boundary restricting resources available to a process or user. Cgroup: A Linux control-group mechanism for organizing, accounting for, and limiting processes. Job control: Shell mechanisms for suspending, resuming, foregrounding, and backgrounding commands. systemd: A system and service manager commonly used as PID 1 on Linux systems. Unit: A systemd-managed resource such as a service, timer, socket, or target. Target: A systemd unit that groups other units to represent an operational state. Dependency: A relationship describing whether one unit requires, wants, or is ordered relative to another. Cron: A scheduler for recurring commands based on calendar fields. Timer unit: A systemd unit that activates another unit according to calendar or monotonic time. Exit status: A numeric result returned by a process when it terminates. Idempotence: The property that repeating an operation produces the same intended result without accumulating unintended effects. Review QuestionsShort Answer Questions1. What is the difference between a program and a process? 2. Why is `SIGTERM` generally preferred to `SIGKILL`? 3. What information can the `STAT` field of `ps` provide? 4. Distinguish `systemctl start` from `systemctl enable`. 5. What problem does `Persistent=true` address in a systemd timer? Long Answer Questions1. Explain the Linux process life cycle, including parent-child relationships, orphan processes, zombies, and exit statuses. 2. Discuss Linux signals and develop a safe procedure for investigating and terminating a malfunctioning process. 3. Explain niceness, resource limits, and cgroups, and show how they contribute to workload isolation. 4. Compare cron jobs and systemd timers in terms of environment, observability, dependencies, missed executions, and resource governance. 5. Describe the design of a production-quality systemd service unit, including identity, startup type, restart behavior, dependencies, logging, and security. Analytical / Application Questions1. A nightly backup sometimes overlaps with the next scheduled run and consumes enough memory to make an API unavailable. Design a diagnostic and remediation plan using the concepts in this chapter. 2. A service is reported as active, but users receive errors because its database is unavailable. Analyze why process supervision alone is insufficient and propose a layered health and dependency strategy. 3. An administrator proposes solving a CPU contention problem by assigning the API a negative nice value and killing the batch process whenever contention occurs. Critically evaluate this proposal and recommend a more reliable design. 22. Multiple Choice Questions with AnswersQuestion 1A process is shown with state Z in the STAT column of ps. What is the most accurate interpretation? A. It is consuming all available CPU in real-time mode. B. It is stopped and waiting for SIGCONT. C. It has terminated but its parent has not collected its exit status. D. It is sleeping while waiting for disk I/O. Correct Answer: C. It has terminated but its parent has not collected its exit status. Question 2Which sequence is generally the safest approach when stopping an unresponsive service process? A. Send SIGKILL immediately and then inspect the logs. B. Send SIGTERM, wait and inspect, then use SIGKILL only if necessary. C. Change its nice value to 19 and assume it will terminate. D. Send SIGSTOP and delete the executable. Correct Answer: B. Send SIGTERM, wait and inspect, then use SIGKILL only if necessary. Question 3Which statement correctly distinguishes systemctl enable from systemctl start? A. Enable changes current runtime state, while start changes boot configuration. B. Enable configures activation at boot or a target, while start activates the unit now. C. They are identical commands with different syntax. D. Start is used only for timers, while enable is used only for services. Correct Answer: B. Enable configures activation at boot or a target, while start activates the unit now. Question 4A systemd unit contains After=database.service but does not contain Requires=database.service or Wants=database.service. What does this primarily establish? A. The database service will always be started first. B. The application will be stopped whenever the database stops. C. If both units are activated, the application is ordered after the database. D. The application receives the database service’s resource limits. Correct Answer: C. If both units are activated, the application is ordered after the database. Question 5Which design best prevents two scheduled instances of the same non-concurrent script from running simultaneously? A. Redirecting standard output to /dev/null. B. Using a lock such as flock around the command. C. Increasing the process priority with renice. D. Adding more cron entries at different times. Correct Answer: B. Using a lock such as flock around the command. Question 6What is a principal operational advantage of representing a recurring task as a systemd oneshot service plus timer? A. It eliminates the need for exit statuses. B. It provides integration with service logging, dependencies, and resource controls. C. It guarantees that the task will never fail. D. It allows the task to run without any user or permission context. Correct Answer: B. It provides integration with service logging, dependencies, and resource controls. Question 7An administrator wants to reduce the CPU impact of a large batch report without stopping it. Which action is most directly relevant for an ordinary process? A. Increase its nice value. B. Send SIGKILL. C. Change its PPID manually. D. Convert its service to a target unit. Correct Answer: A. Increase its nice value. Question 8Why can repeatedly killing a process fail to resolve a service problem when Restart=always is configured? A. Signals cannot be delivered to systemd services. B. The service manager may immediately start a replacement process. C. The process automatically becomes a zombie and cannot be observed. D. The nice value prevents all termination signals. Correct Answer: B. The service manager may immediately start a replacement process. Question 9Which systemd service setting most directly reduces the privileges available to an application? A. After=network-online.target B. RestartSec=5 C. User=inventory D. WantedBy=multi-user.target Correct Answer: C. User=inventory Question 10A timer has Persistent=true. What operational behavior should the administrator anticipate? A. The timer will run continuously rather than at scheduled times. B. A missed calendar activation may be triggered when the system becomes active again. C. The associated service cannot be stopped manually. D. The timer ignores all dependency relationships. Correct Answer: B. A missed calendar activation may be triggered when the system becomes active again.
|
