A Linux service cannot write. Do you restart it?
Reads work. New uploads fail.
The question
Bellmere is a fictional healthcare group with clinics, offices and a supply warehouse. You are handling a Linux document-service escalation. The records and procedure below are authored practice material; no command is run.
| GiB | |
|---|---|
| Capacity | 32 |
| Used | 32 |
| Available to the service | 0 |
A simplified authored capacity record: the volume is 100% used. Other filesystems are not reported full.
- Document serviceThree attempted writes fail with “No space left on device”. Users can sign in and read existing documents; new uploads fail.
- AI suggestionDelete the largest log directory and restart the shared service. This will fix the database defect.
Support may read the supplied diagnostics and preserve a redacted error excerpt. The Linux host owner controls storage cleanup and service changes. Log retention rules apply; support cannot delete logs or restart the shared service. The document-service owner must verify uploads after any authorized host action.
“Explain the strongest supported diagnosis, the permitted next action, and the check needed before closure.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Connect the two observations
What would you do here? Open the move you’d make.
Treat successful login as proof the service is healthy
Tempting, but it misses something. The affected task is a new upload, which still fails after login.
Relate the full volume to the write errors
The strong move. Use the failing operation and matching resource evidence.
See how a strong candidate says it
“The /var volume has no available space, and writes report no space left. Reads and login still work. That supports a capacity-related write failure; it does not establish the AI’s database-defect claim.”
Why it works: Use the failing operation and matching resource evidence.
Step 2: Preserve useful evidence
What would you do here? Open the move you’d make.
Keep the AI diagnosis as the root cause in the escalation
Tempting, but it misses something. Neither the capacity report nor the error identifies a database defect or the reason for growth.
Preserve the current records and ask about growth
The strong move. The record supports the immediate constraint, not its underlying cause.
See how a strong candidate says it
“I would retain the volume report, failed-upload times, redacted error excerpt and affected operation. I would ask when growth began and which directories changed, rather than guess why the volume filled.”
Why it works: The record supports the immediate constraint, not its underlying cause.
Step 3: Use the host owner
What would you do here? Open the move you’d make.
Escalate capacity and retention decisions to the host owner
The strong move. A likely capacity problem does not authorize destructive cleanup.
Delete the largest logs before they grow further
Tempting, but it misses something. That removes evidence and may violate retention rules; support lacks change authority.
See how a strong candidate says it
“I would ask the Linux host owner to investigate space use and choose a permitted cleanup or capacity action under retention rules. I would not delete the largest logs or restart the service from support.”
Why it works: A likely capacity problem does not authorize destructive cleanup.
Step 4: Define restoration before closure
What would you do here? Open the move you’d make.
Close when the owner reports that space was freed
Tempting, but it misses something. Free space alone does not verify that the affected application task now works.
Check space, the actual upload and renewed errors
The strong move. A resource change and user-task recovery are separate observations.
See how a strong candidate says it
“After an authorized host action, I would confirm available space, have the document-service owner test a new upload, and check for renewed write errors. I would keep the growth cause open unless the owner establishes it.”
Why it works: A resource change and user-task recovery are separate observations.
The answer, in short
- Decision
- Send the capacity-related write failure to the Linux host owner; preserve the evidence.
- Because
- The supplied /var report is 32 GiB used out of 32 GiB, with zero space available to the service and matching write errors.
- What would change it
- A new capacity report, a different write error, or an owner-verified cause could change the diagnosis. Closure still needs an upload check after an authorized action.
Common traps
- Turning a no-space error into an unverified database-defect claim.
- Deleting useful logs without retention approval.
- Closing after a resource change without testing the upload.
Check your answer
- Did you connect zero available space to the failing writes?
- Did you preserve evidence and leave the growth cause open?
- Did you keep deletion and restart authority with the host owner?
- Did you require both space and upload checks after an authorized action?
Last reviewed Nov 10, 2026