FFmpeg writes its messages to stderr by default. To keep a long-running YouTube stream’s logs from filling a VPS disk, choose a deliberate log level and destination, rotate the file in a way the running process can handle, and set a finite retention limit.
Renaming a log file does not necessarily make its space available: FFmpeg can keep writing to the already-open file even after its pathname changes. The right rotation method depends on whether your service can make FFmpeg close and reopen that output; either way, check disk use and YouTube stream health separately.
Find where FFmpeg writes its logs
Start with the process launch configuration, not a guessed filename. FFmpeg’s default is stderr, so a service manager, shell wrapper or container may decide where those messages go. They might be captured by the service manager’s journal, redirected to a file, or discarded. The command itself may also specify a report file.
The FFmpeg documentation describes the default logging destination and the -report option. Check the unit file or wrapper that launches FFmpeg, then inspect the service manager’s configuration and logs. If stderr is redirected with a shell expression such as 2>>/var/log/ffmpeg.log, that path is the obvious candidate for rotation, but it is not the only possible output.
For a systemd-managed service, for example, stderr may be collected in the journal rather than a separately redirected file. In that case, configure and verify journal retention rather than adding a logrotate rule for a file that does not exist. The settings and commands differ by distribution, so use the documentation for the system in front of you. A journal’s storage limit is also separate from a file-based FFmpeg log’s retention.
If you do use a file, keep it in a dedicated, predictable location with ownership and permissions that permit the service to write and the rotation job to manage it. Avoid placing it beside the video file simply because both belong to the stream. The log has a different lifecycle, and separating it makes disk checks and cleanup less error-prone.
A log can include the command line or other operational details. Keep stream keys and other credentials out of command lines, reports and published examples where possible. YouTube describes a stream key as functioning like the stream’s password and address in its live-stream settings guidance. Treat logs as private operational data and review who can read them.
If you are building a continuous stream from a VPS for the first time, the discussion of a nonstop stream from an Indian VPS can help put the process and hosting choices in context. For this article, the immediate task is simply to identify every place the service writes diagnostic output before deciding what to rotate.
Set useful verbosity and destination
A rotation rule limits retained files; it does not stop excessive output from being written in the first place. FFmpeg’s documented -loglevel levels include error, warning, info, verbose, debug and trace, with info as the default. Choose the least verbose setting that still gives you the information you need when the stream misbehaves.
For routine operation, the default may be useful because it preserves general operational messages. A quieter level such as warning can reduce routine lines, but you may lose information that would make a failure easier to diagnose. error is quieter still and reports errors, including recoverable ones. Do not change levels solely to make a log smaller unless you have considered which clues you may need after an overnight failure.
FFmpeg’s time and datetime log flags add timestamps to lines. They can help you compare a local event with a YouTube warning or a service restart. Use one if it makes your own log easier to read, and verify how the output looks in your deployed FFmpeg version. Timestamps improve correlation; they do not tell you whether YouTube received a healthy feed.
Be especially careful with -report. FFmpeg’s documentation says it writes the command line and log output to a timestamped report in the current directory, and that it implies debug-level logging. That can be valuable while investigating a specific fault, but leaving it enabled indefinitely can create both extra output and unexpected files in the service’s working directory. Use it for a bounded diagnostic run, then remove it from the normal launch configuration if you no longer need it.
Keep the output destination explicit. If a wrapper redirects stderr to a file, make that path and its directory easy to find and monitor. If the service manager collects stderr, learn how that manager retains and exposes it instead. In either case, distinguish FFmpeg’s own verbosity from the retention policy: fewer lines may slow growth, but only a finite cleanup policy bounds accumulated history.
Understand what stays open after a rename
A filename is a directory entry that points to a file; a running process writes through an open file descriptor. When a rotation job renames the current log and creates a new file at the original path, the pathname changes, but FFmpeg’s existing descriptor can still refer to the original file. The process may continue appending there, while the newly created file remains empty.
That is why a renamed log can appear to disappear from the expected path without releasing its disk space. The old file can be unlinked from the directory but continue consuming space while a process still has it open. You may see a deleted log reported under an open-file inspection tool even though ls no longer shows it. Space is typically reclaimed only after the last open reference is closed.
Before trusting a rename-based rule, inspect the running process’s open file descriptors and confirm which inode it is writing to. On Linux, tools such as lsof can help identify open files, including deleted ones, if installed and permitted. Compare the process’s descriptors before and after a test rotation rather than relying on the visible filename alone.
This behaviour is not unique to FFmpeg; it follows from how the operating system handles open files. It also explains why a rotation configuration can look successful in its directory listing while the VPS disk continues to fill. The relevant question is not merely “Did the file get renamed?” but “Did the writer switch to the new file or close the old one?”
If the stream is managed through a service definition, review that lifecycle before trying signals or scripts. A rotation example for a daemon that handles a particular signal does not prove FFmpeg will reopen redirected stderr on that signal. Do not assume that it will. Only use a reopen action if it is supported by your actual launch method and tested with the deployed process.
Choose reopen rotation or copytruncate
There are two practical paths. If your process or supervisor can reliably close and reopen the log destination, rename-and-create rotation can keep the old file intact as an archive and direct later output to a fresh file. If the long-running writer cannot be made to reopen its output, logrotate’s copytruncate option is designed for that situation: it copies the current file and truncates the original in place.
| Method | When it fits | Main trade-off |
|---|---|---|
| Lower, intentional verbosity | Routine output is more detailed than you need | Less diagnostic context may be available later |
| Rename, create and reopen | Your service has a verified way to reopen redirected stderr | Rename alone can leave the process writing to the old file |
copytruncate |
The writer cannot be told to close or reopen its log | Some output can be lost in the copy-and-truncate interval |
| Finite retention and compression | Old files would otherwise accumulate | Thresholds need measuring; compression uses time and resources |
With rename-and-reopen, the rotation sequence matters: preserve the old file, create a new one with suitable permissions, then use the documented mechanism for the service to reopen its output. Depending on the environment, that may be a supported supervisor action or a planned restart during a period when an interruption is acceptable. A restart may interrupt the broadcast, and an ostensibly seamless configuration should not be treated as a guarantee. Validate the exact arrangement before relying on it.
With copytruncate, logrotate copies the current file and truncates the original so the process can continue writing through its existing descriptor. The logrotate manual warns that some data may be lost in the small interval between copying and truncating. This is a compromise, not a lossless way to preserve every line. It can be appropriate when reopening is not available, but you should know what diagnostic gap it can create.
A generic logrotate shape might look like this:
/path/to/ffmpeg.log {
size <measured-threshold>
rotate <finite-count>
compress
copytruncate
}
This is a sketch to adapt, not a drop-in configuration. It omits ownership, permissions, scheduling and service-specific reopen handling. If you have verified reopen support, use an appropriate rename/create workflow instead of copying and truncating by habit. Check your local logrotate version and test its behaviour against a non-production or controlled stream before trusting the result.
Set finite retention and verify the files
Rotation and retention are separate decisions. A rule can rotate frequently but still keep old files without a useful bound. Logrotate’s rotate count sets how many rotated versions to retain; a count of zero removes old versions rather than keeping rotations. Compression can reduce the space taken by older logs, and delayed compression is available for cases where a program may still be writing to a prior file.
Do not pick a universal size or age from another operator’s setup. FFmpeg output varies with verbosity and runtime conditions, and the amount of history you need depends on how quickly you can investigate a fault. Measure the growth of your own log during ordinary operation and during the kinds of errors you are trying to diagnose. Then choose a threshold and finite count that fit your disk capacity and recovery needs.
Logrotate may be invoked on a schedule rather than continuously. A size rule therefore does not necessarily rotate at the instant a file crosses that threshold; it is evaluated when the rotation job runs. Check the scheduler on your distribution and use a schedule and policy that suit the observed growth. The logrotate manual documents the available directives; the local setup determines when the tool is actually run.
After applying a rule, inspect the active file and all retained rotations. Confirm that the current log continues to grow at the expected pathname, old files receive the intended names, compression completes, and the configured count is respected on subsequent runs. Check that rotated files have useful permissions and that the service can continue writing to its active destination. With copytruncate, inspect the active file after rotation to verify it was truncated rather than replaced.
Also check filesystem free space and total log use over time, not just the size of the current file. Deleted-but-open files can account for space that is missing from directory listings. If space is still disappearing, inspect open descriptors and other large files on the same filesystem rather than concluding that logrotate has failed or that the stream itself is responsible.
A disk alert is useful only if it gives you time to respond. Base its threshold on the filesystem’s capacity, the measured growth rate and how quickly you can intervene; the documentation does not prescribe a universal VPS alert level. For a broader view of what runs the broadcast, compare the available live-streaming apps with the tools and process you already use, but keep log retention as a deliberate part of whichever setup you choose.
Coordinate rotation with the service lifecycle
A rotation rule does not operate in isolation. It interacts with how FFmpeg starts, whether a supervisor restarts it, how stderr is captured, and what happens when the process exits. Write down the actual chain: service manager launches wrapper, wrapper launches FFmpeg, stderr goes to a destination, and a scheduled rotation job acts on that destination. This simple map prevents configuring logrotate against the wrong process or file.
If you choose reopen-based rotation, establish exactly what performs the reopen and how you know it worked. A supervisor may manage its own logs rather than FFmpeg’s redirected stderr. A wrapper may spawn FFmpeg in a way that makes signalling or replacing the process unreliable. Test the action and then verify the process descriptor points to the new file. Do not copy a postrotate signal from an example unless the signal behaviour is documented for your deployed arrangement.
If there is no reliable reopen action, copytruncate avoids requiring one, subject to its short potential data-loss interval. In some deployments, scheduling a planned restart is acceptable, especially if you already have a controlled way to bring the stream back. In others, the broadcast must remain undisturbed, so the restart cost may outweigh the value of preserving every old log line. Choose based on the actual stream’s operating needs, not a claim that one method is universally safe.
Test a configuration change before leaving it unattended. Use a representative test broadcast or a maintenance window, trigger a rotation manually only if you understand the local logrotate state and options, and watch both process status and file descriptors. Confirm that rotation does not leave an unbounded deleted file open, that the service keeps writing where expected, and that restarting behaves as you intend.
The larger stream workflow matters too: a file may be repeated, audio may be continuous, and the service may need to recover after a process failure. The practical notes on running a 24/7 prerecorded YouTube stream with OBS address a different tool, but reinforce the same operational habit: test the real launch and recovery path rather than assuming a setting behaves the same everywhere.
Check YouTube ingest health separately
A tidy local log is not evidence that YouTube is receiving a healthy stream. Logs show what FFmpeg reported locally; they cannot by themselves establish that the encoder settings, network path, ingest connection or viewer-facing output are all working. Likewise, a quiet log may simply reflect a low verbosity setting rather than a trouble-free broadcast.
After changing launch or logging behaviour, test before depending on the setup overnight. Check the YouTube preview, watch stream health and any messages in YouTube Studio, and confirm that the audio and picture are as expected. YouTube’s encoder guidance covers feed recommendations such as RTMP/RTMPS, CBR, supported codecs and keyframe frequency. Those are stream settings, not logrotate settings, and a correct local rotation rule cannot repair an ingest mismatch.
YouTube’s streaming tips recommend testing and monitoring stream health. Follow that advice alongside local checks: inspect FFmpeg errors, compare timestamps when correlating events, verify the local recording or archive where relevant, and watch free disk space and retained log sizes. Each check answers a different question.
If YouTube reports an ingest issue, investigate the feed and connection rather than treating rotation as the cause without evidence. If the VPS disk is filling while YouTube looks normal, inspect logs and other disk consumers. If the stream drops during a rotation-related restart, review the service lifecycle and recovery path. Keeping these diagnoses separate makes it easier to fix the right layer.
For operators who want the computer out of the streaming loop, StreamNeo removes the specific burden of keeping a local machine running by turning an uploaded video into a YouTube live stream that continues from the cloud; it does not make YouTube-only health checks or content decisions unnecessary. Whichever operating path you use, retain enough local evidence to diagnose problems without keeping logs indefinitely.
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
Will renaming an FFmpeg log file free the disk space?
Not necessarily. FFmpeg can continue writing to the file descriptor it opened before the rename, so the old file may remain in use even if its name disappears from the directory. Check open descriptors and confirm the process has switched or closed the old file before assuming space has been reclaimed.
Is copytruncate lossless?
No. The logrotate manual says some logging data may be lost during the small interval between copying and truncating the active file. It is intended for programs that cannot be told to close their log, so weigh that gap against the interruption or complexity of arranging a reopen.
Does FFmpeg reopen redirected stderr automatically?
Do not assume that it does. A rename changes a pathname, not an already-open descriptor; use a documented and tested reopen mechanism for your service or choose another rotation approach. A restart may be appropriate in some setups, but it can interrupt the broadcast.
Do FFmpeg logs prove that YouTube’s stream is healthy?
No. They record local process output and do not prove that YouTube is receiving a healthy feed. Check YouTube Studio’s preview, stream health and messages separately, while also verifying local disk use and log retention.