If FFmpeg runs as a systemd service on your VPS, start with systemctl status your-stream.service, replacing the example name with your actual unit. Then check YouTube Live Control Room: a service marked active tells you about the local process, not whether YouTube is receiving a healthy, advancing picture and sound.
Use both views when deciding whether a stream is still running. Systemd reports the service manager’s local state, FFmpeg can report encoding progress, and YouTube shows what has reached its ingest path and live event. None should be mistaken for the others.
Check the systemd service status
Connect to the VPS over SSH and ask systemd for the unit’s status:
systemctl status your-stream.service
The output is intended for a person reading a terminal. It normally shows a unit’s loaded state, whether systemd considers it active, the main process information when available, recent journal lines and a summary of the last exit. Read the whole output rather than relying on its first line: the recent log entries may explain a restart, an input error or an unsuccessful connection attempt.
The service name is not necessarily the name of the video file or the FFmpeg command. If you created a unit called bhajan-stream.service, use that exact name. If you do not remember it, list the relevant unit files with systemctl list-units --type=service and inspect the likely service. Avoid changing or restarting a unit merely to discover its status.
The systemctl manual documents the status and property commands. Your installed systemd version and unit configuration determine the details you see. If a command reports that the unit cannot be found, check spelling and whether the service is a system unit or a user service; do not infer from that message that FFmpeg is absent from the VPS.
A status view is a snapshot. If you suspect a brief interruption, run the check again after a short interval and compare it with the destination view. A single reading cannot show whether media has continued to advance over time.
Read service state and MainPID
For a short, script-friendly result, ask systemd for selected properties:
systemctl show your-stream.service -p ActiveState -p SubState -p MainPID
ActiveState gives the broad state, SubState gives a more specific state, and MainPID is the process identifier systemd currently records as the service’s main process. A nonzero MainPID means systemd currently records a main process; a zero value means it currently has no main PID. Neither value says whether YouTube is receiving usable media.
Do not substitute ExecMainPID for MainPID when checking current process presence. ExecMainPID can preserve information about the process from the last execution after that process has stopped. The systemd service property reference describes these properties and the service state fields.
The fields answer different questions. ActiveState=active is the manager’s current broad state; SubState helps explain what kind of active state it is. A unit may also be inactive, failed, activating or deactivating, depending on what systemd sees at that moment. When a service is restarting, the precise state and recent journal messages are more useful than treating one word as a complete diagnosis.
If you are writing a monitoring check, capture the unit name, timestamp and those properties together. A bare PID copied into a dashboard can become misleading when a process exits and another later takes its place. Keep access to the service’s journal as well, so a status change can be investigated rather than merely displayed.
What a running process proves, and what it does not
A process or active service proves something local: according to systemd, a process is associated with the unit at the time of the check. It does not prove that FFmpeg is reading the intended file, producing new frames, encoding audio, maintaining a connection, or sending acceptable media to YouTube. Those are different stages in the path from source file to viewer.
For example, an FFmpeg process can remain present while an input has stopped advancing, while its output is stuck, or while the connection to the destination has failed. Conversely, a recently restarted process may be attempting to recover even though the service is not yet in a stable state. Treat the service state as a useful first signal, not a health certificate.
This distinction matters especially for unattended streams. If a recorded playlist is supposed to loop, check that the source and loop behaviour are configured as intended; the FFmpeg guide to a 24/7 Telugu bhakti stream is useful context for that kind of setup. A process check cannot tell you whether the content sequence itself is progressing as expected.
For the same reason, a remote viewer’s report is worth checking against the control room and logs. A person seeing a frozen image may be looking at a playback or delivery problem, while systemd still sees a living process. Gather signals from both ends before deciding whether to restart the job.
Check FFmpeg output and errors
Systemd’s status output often includes recent journal entries. For a fuller view, inspect the journal for the unit:
journalctl -u your-stream.service
You can narrow the output to recent entries with journal options such as -n or follow new entries with -f. Check the service’s own logging configuration: output may be sent to the journal, redirected to a file, or handled another way. Do not assume every installation retains logs in the same place or for the same period.
Look for a sequence rather than one alarming line. An input-open error, repeated reconnect messages, encoder failures or a clean shutdown can explain why the stream stopped or became unhealthy. At the same time, a quiet log is not proof that the output is good; FFmpeg may not be configured to emit the detail you need, and a service can be running without useful progress messages.
FFmpeg’s command-line documentation describes -progress URL, which sends structured progress information to a destination such as standard output. The output is formatted as key=value lines; the last key in a sequence is progress, with a value of continue or end. The -stats_period option controls how often progress is reported. See the FFmpeg command-line documentation for details and version-specific behaviour.
A documented pattern is:
ffmpeg -progress pipe:1 -i INPUT OUTPUT
This is an illustration of progress reporting, not a complete YouTube command. Preserve your existing input, ingest destination, stream-key handling, encoding settings and output options if you add progress reporting. Do not paste a real stream key into a public issue, screenshot or shared log. Anyone who obtains a live stream key may be able to transmit to your channel, so treat it as a credential and redact it when sharing diagnostics.
FFmpeg’s normal encoding statistics are enabled by default; -nostats disables them. For a human watching a terminal, those statistics can help show that work is taking place. For a monitor or script, structured -progress output is easier to parse. Neither substitutes for YouTube’s view of received media: local progress can continue even when a destination-side problem remains.
Verify the feed in YouTube Live Control Room
Open YouTube Live Control Room for the event that should be receiving the VPS stream. Check whether YouTube identifies the stream as live or receiving data, and inspect the preview and the available stream-health feedback. Confirm that the event selected is the one using the stream key configured on the VPS; an unrelated event can look healthy while the intended broadcast is not.
Watch the preview long enough to tell whether the image changes when it should. Listen for audio if the programme is meant to contain it. A preview image alone does not establish that every viewer can play the stream correctly, but it gives you a destination-side check that systemd cannot provide. Also inspect any warnings YouTube presents rather than assuming that an active event means every part of the feed is sound.
If the control room does not show incoming video, compare its event and ingest details with the FFmpeg output and unit configuration. Check for a wrong or outdated key, a mismatched event, a failed connection, or a stopped input. Do not expose the key while investigating. If you replace it, update the service configuration securely and restart only when you understand which event and output the unit is meant to serve.
YouTube’s interface and health messages can change, so use the current YouTube Help guidance for live streaming when interpreting a warning or setting up the event. The important practical point is to consult YouTube’s own receiving status alongside the server checks. A VPS can report a working process while the event is not receiving the programme you expect.
Compare process and YouTube health signals
Use the signals together, and ask what each one can establish. The table is a troubleshooting aid, not a guarantee that any individual combination diagnoses the cause on its own.
| Signal | What it tells you | What it does not establish |
|---|---|---|
systemctl status |
The unit’s current manager view, recent journal context and reported process information | That frames and audio are advancing or reaching YouTube |
ActiveState, SubState, MainPID |
Selected systemd state properties and the currently recorded main PID | That the destination accepts a healthy feed |
| FFmpeg journal output | Errors or messages emitted and retained through the service logging setup | That the control room or viewers receive correct playback |
FFmpeg -progress |
Structured local progress updates from FFmpeg | That YouTube has accepted and is presenting the media |
| YouTube Live Control Room | Destination-side event and stream-health information available in the interface | That your local process is correctly managed or will recover later |
If the service is inactive and YouTube is not receiving data, start with the unit’s exit information and journal. Find the first relevant error rather than repeatedly restarting without understanding the cause. The issue may be an input path, permissions, a configuration error or another failure visible in the logs.
If systemd says active but the control room shows no incoming feed, treat the difference as a real fault to investigate. Examine FFmpeg output, the selected event, destination settings and key handling. A running process is not a reason to dismiss what YouTube reports.
If FFmpeg is reporting progress and YouTube shows a healthy incoming feed, those are stronger complementary signs than either alone. Still, if the programme itself appears frozen or silent, check the preview and content source. A process can make measurable progress through a file while the resulting programme is not the intended one.
For future runs, decide in advance what you will check when an alert arrives: service state, recent journal messages, structured FFmpeg progress and the correct YouTube event. Keep a record of the unit name and the safe way to access its logs. This makes a night-time diagnosis quicker without encouraging a blind restart that could interrupt a recoverable stream.
If you are choosing how to run an always-on channel rather than diagnosing an existing VPS, first weigh the maintenance you want to own. A VPS gives you control over the operating system and process configuration, but you remain responsible for service setup and checking it. The continuous podcast VPS guide covers the hosting question, while the prerecorded video streaming guide helps distinguish a computer-based workflow from a server-based one. For a looping source, see also the guide to looping a video on a YouTube live stream.
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 nonzero MainPID mean YouTube is receiving my stream?
No. It means systemd currently records a main process for the service. Check FFmpeg’s output and the relevant YouTube Live Control Room event to see whether the feed is progressing and arriving as expected.
What does ActiveState=active tell me?
It tells you the broad state systemd currently reports for that unit. It does not guarantee a healthy live event, advancing video or working audio, so pair it with logs and destination-side checks.
Why should I check MainPID instead of ExecMainPID?
MainPID describes the main process currently known to systemd and is zero when there is no current main PID. ExecMainPID can refer to the last execution, so an old value should not be mistaken for a process that is still running.
How can I monitor progress on later runs?
FFmpeg’s -progress option can emit structured key=value updates, with progress=continue or progress=end at the end of a sequence. Configure where that output goes and how it is retained, then still compare it with the YouTube event’s own incoming-feed status.