A full Linux filesystem can disrupt services that write logs, temporary files or stream data, but it does not by itself prove why your YouTube 24/7 stream stopped. To investigate, compare YouTube’s timestamped stream-health information with the Linux host’s disk and inode use, service state and logs around the same time.
Recover in stages: preserve useful evidence, identify what filled the relevant filesystem, make room without removing active or needed data, then check the encoder and YouTube event. A network interruption, process failure or another issue may have coincided with the disk warning, so treat the full filesystem as a plausible contributing condition until the evidence points more clearly to a cause.
What a full Linux filesystem can affect
“Disk full” can mean that a filesystem has no space for additional data, or that it has used all its inodes: the records the filesystem needs to represent files. These are separate limits. A host may have apparent room in gigabytes but be unable to create another file because inode use is exhausted. That can matter for services which create logs, caches, temporary files or other small files.
A streaming process may need to write to more than one place. Its media file could be on one mount, while logs, temporary data, application state and system journals use others. If one of those locations cannot accept writes, the effect depends on the software and its configuration. A process might report a write error, stop, remain running but fail to perform a task, or continue while an unrelated part of the system struggles. None of those possibilities establishes what happened in your incident.
Separate the local encoder from YouTube’s ingest and the event shown to viewers. A stopped process, a lost connection and an ended event are not interchangeable observations. YouTube Live Control Room exposes stream health and error information; note what it says and when it says it rather than inferring the cause from a disk alert alone. YouTube’s live streaming error guidance describes the error information available in Live Control Room.
Keep the timeline in view. A disk alert that appeared after the stream stopped may be a consequence of a long-running log or a separate issue, while an alert before the stop makes a relationship worth investigating, not a proven explanation. Record the stop time and timezone, the first disk-full observation, any service restart, and the YouTube health messages. This gives you something concrete to compare instead of relying on a remembered sequence.
Check which filesystem reached capacity
Start with read-only checks before deleting or restarting anything. On the Linux host, run df -h to inspect filesystem capacity in human-readable units and df -i to inspect inode use. The GNU/Linux df manual documents reporting available space and inode information. Look at the mount that contains the relevant data, not only the root filesystem /.
Identify the paths used by your setup: media source, encoder logs, service logs, caches, temporary files and system journal. A stream can read a large video from one mount and write logs to another. If the service runs under a separate account or in a container, check the filesystem view and paths available to that service as well as the host’s general view. Do not assume that a healthy-looking / means every relevant mount has room.
For a directory-level locator, you can use du -xhd1 /path where supported, changing /path to the mount or directory you are examining. The -x option keeps a scan on one filesystem, while the depth limit makes the output easier to inspect. Flags vary between implementations, so check the installed du manual or use equivalent options. The GNU du manual explains that it estimates usage through directory trees.
Treat du as a way to find likely large directories, not a perfect reconciliation with df. The two tools answer different questions: filesystem-wide space used versus usage reachable by walking directory entries. Open-but-deleted files, mount boundaries, permissions, reserved space and filesystem-specific behaviour can contribute to a mismatch. Those are avenues to check if the numbers disagree, not confirmed explanations for your case.
A short inspection sequence can keep you oriented:
| Check | What it tells you | What to do with the result |
|---|---|---|
df -h |
Available filesystem blocks | Identify the mount at or near capacity |
df -i |
Available inodes | Check whether file count, rather than bytes, is the constraint |
du on a relevant path |
Directories with substantial reachable usage | Inspect the owner and purpose of large data before cleanup |
| Service path and mount configuration | Where the encoder and its logs write | Compare those paths with the full mount |
A nearly full mount is a clue, not an automatic instruction to expand it. Confirm whether it is a media volume, a log location, a temporary area or a system filesystem. If you operate a VPS, the 24/7 FFmpeg VPS guide can help put the software and host setup in context, but the disk diagnosis still depends on your own mount paths and evidence.
Inspect logs and processes around the stop
Before clearing files, collect the evidence that may explain the sequence. Review the streaming application’s own log, the service manager’s view of the process, and the system journal for a window around the recorded stop time. If you use OBS, its connection troubleshooting guidance is relevant to OBS encoder and network symptoms; it is not a description of every Linux streaming stack. OBS says dropped frames and intermittent disconnects can indicate an unstable connection to the remote ingest server, so network evidence deserves separate consideration. See OBS stream connection troubleshooting.
Search for messages that distinguish possible failure paths: failed writes, a process exit, a service restart, a connection loss, or a resource warning. Match their timestamps with YouTube’s health timeline. A local message about a failed write may support a disk-related theory; a connection error may point elsewhere; and a lack of a useful message does not establish that no failure occurred. Keep copies of relevant log excerpts before rotating or removing them, particularly if you may need an administrator to review the incident.
For systemd-based systems, journalctl --disk-usage reports the space occupied by journal files. Journald can use persistent storage under /var/log/journal or volatile storage under /run/log/journal, depending on configuration. The journalctl manual documents journal inspection and maintenance, while the systemd-journald manual describes its storage behaviour.
Check the service state without assuming that a restart is the right first move. If the process is still running, capture its current status and recent logs before changing it. If it has exited, note its exit information and any configured restart behaviour. A repeated restart can obscure the original event or fill a log further; it also may not address a connection problem or a separate YouTube event state.
YouTube’s stream metrics guidance can help you examine available event information. Write down whether the event appears ended, disconnected, or still receiving an encoder feed, and whether the reported health changes align with local events. If the evidence remains incomplete, label the cause unknown rather than turning the nearest warning into a certainty.
Restore space without deleting needed data blindly
First identify what occupies the mount and whether it is safe to alter. A large file could be the source video currently being read, a recording you need, a growing log, a cache that can be recreated, or application state. File size alone does not tell you which. Check ownership, timestamps, the process using a file and the service’s retention needs before removing or moving it.
If logs account for substantial usage, preserve the portion needed to investigate and then use the system’s supported log rotation or retention controls. For systemd journals, inspect usage and configuration before deliberately rotating or vacuuming archived entries. Vacuum operations target archived journal files; they are not a substitute for understanding why records continue to accumulate. Avoid copying a very large log to the same full filesystem, since that can make the pressure worse.
For ordinary application logs, investigate which service is producing them and whether rotation is configured. The logrotate manual documents time- or size-based rotation, compression and removal according to configuration. Adjust retention with care: a short retention period can remove useful evidence, while an unbounded log can consume the space required by other services. Make a configuration change only when you understand which files it will affect and how the application handles rotated logs.
If the culprit is media or other required data, do not delete it just to make the warning disappear. Consider moving confirmed inactive files to another suitable location, or expanding the relevant volume if your environment supports it and the capacity need is genuine. For a virtual server, first confirm the provider’s storage model, the mount and filesystem, and whether a resized volume also needs an operating-system change. Adding capacity will not stop a runaway log or resolve inode exhaustion by itself.
Where df and du disagree, pause before cleanup. A deleted file can still take space while a process holds it open; permissions can prevent a directory scan from seeing all entries; and a mount may hide data beneath its mount point. These are possible explanations to investigate with appropriate administrative access. If the machine is managed by someone else, share the mount, command output and incident timestamps rather than attempting unfamiliar filesystem repairs.
After making room, repeat df -h and df -i for the affected mount. Confirm that the relevant service account can write where it needs to, and check whether usage is growing again. The goal is not simply to produce a lower usage figure; it is to restore the required operation while preserving data and understanding what consumed the space.
Verify the streaming process and YouTube event status
Once the host has usable capacity and the relevant paths are writable, check the actual encoder or streaming service. The right procedure depends on whether you use OBS, FFmpeg, a systemd unit, a container or another arrangement. There is no universal restart command that is safe for every setup. Follow the procedure for your service, and capture status and logs if it fails again.
Then verify both sides of the broadcast. On the host, confirm that the process is running and producing the expected output without new write errors or repeated restarts. In YouTube Live Control Room, check whether an encoder feed is arriving, whether the event is live or ended, and whether the health messages have changed. A running local process alone does not confirm that YouTube is receiving a usable stream; a visible YouTube event alone does not show that the underlying disk condition is resolved.
If the service reconnects but health remains poor, investigate the connection path rather than repeating disk cleanup. Compare the timestamps and local encoder messages, and use the relevant software’s troubleshooting steps. The distinction matters when deciding the next action: capacity changes address confirmed storage pressure, while a network or ingest issue needs its own diagnosis. The OBS dropped-frames troubleshooting article is useful when OBS reports frame or encoder symptoms, but it should not be used to label a non-OBS failure.
Likewise, if the process remains healthy but YouTube marks the event ended, check the event state and the available YouTube guidance before assuming a local restart will restore the same event. Record the result and any new errors. Do not promise yourself that a particular recovery outcome will follow from freeing space; verify what the software and Live Control Room actually show.
Reduce the chance of another disk-full incident
Prevention starts with the directory that grew, not with a generic hardware purchase. If a service log grew without limit, configure appropriate rotation and retention for that service. If temporary files accumulated, find out which process owns them and whether it has cleanup behaviour. If the mount is simply too small for confirmed media and logs, plan capacity around those uses. A larger disk does not correct inode exhaustion, uncontrolled file creation or an unrelated unstable connection.
Set up routine checks for both block and inode use on the filesystems that matter. The useful warning point depends on the service’s write rate, the time required for someone to respond and the amount of space needed for safe operation; there is no single threshold suitable for every host. Review trends rather than waiting for a failed write. In a managed environment, ask the administrator which alerts cover each mount and whether they report inode use as well as bytes.
Keep stream media, application state and logs distinguishable where practical, so a growing log does not silently compete with the source file or system journal. Document the paths and service names. A brief runbook can state how to check the encoder, where to find logs, how to inspect YouTube health, and which data must not be deleted. If another person is on call, that record reduces guesswork at the point when the stream is already disrupted.
Also review restart behaviour. An automatic restart can help recover from some process exits, but it cannot make a full filesystem writable and may repeatedly fail if the underlying condition remains. Check what the service logs on restart and whether repeated attempts create more records. The automatic stream scheduling guide discusses planned starts; scheduled start behaviour is separate from diagnosing a service that has stopped unexpectedly.
If maintaining a Linux host, its storage, logs and restart behaviour is taking time away from preparing the channel, an uploaded-file workflow can remove the need to keep your own computer running for the broadcast. StreamNeo turns an uploaded video into a YouTube live stream, so you do not have to investigate disk use on your own streaming computer for that broadcast; you still need to prepare the file and verify the channel and event.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does a full filesystem prove that it stopped my YouTube stream?
No. It can interfere with software that needs to write, but the disk condition alone does not establish the mechanism or prove that it ended YouTube ingest. Compare local logs and process state with YouTube’s timestamped health information before drawing a conclusion.
Why does df -h show space but the service cannot create files?
The filesystem may have exhausted inodes, which are distinct from storage blocks. Check df -i for the relevant mount as well as df -h, and confirm the path where the service is trying to write.
Is it safe to delete the largest log or media file?
Not until you know what it is, whether a process is using it, and whether it is needed for diagnosis or the stream. Preserve useful evidence and use the service’s supported rotation or retention controls for logs rather than deleting files solely because they are large.
Should I restart the encoder as soon as I free space?
First confirm the affected filesystem has room and the required paths are writable, then follow the restart procedure for your actual encoder or service. Afterwards, verify both the local process and YouTube’s event status; a restart does not establish that the original cause is fixed.