If your Gurbani stream generator and the server that serves listeners are both on the VPS being rebooted, listeners should expect an interruption. A restart policy can bring a stopped process back after the host returns; it cannot keep that host available while it is rebooting.
To keep a public listening endpoint available through maintenance, that endpoint must remain on another running system with audio to serve, or a tested standby and traffic-switching design must take over. Even then, listeners may need to reconnect. The right plan depends on whether you are changing configuration, restarting a service, or rebooting the VPS.
What listeners hear during a VPS reboot
A stream has a chain of parts. A generator such as Liquidsoap produces or schedules audio, a streaming server such as Icecast accepts that audio and makes it available at a mount, and listeners connect to the public stream address. These parts can share a host or be split across hosts. The arrangement determines what breaks when you perform maintenance.
If the VPS running the generator and listener-facing server reboots, both stop serving while the machine shuts down and starts again. A listener’s player may buffer briefly, then fall silent or report that the stream has ended. Some players retry the address on their own; others wait for the listener to press play. Do not assume an existing connection will resume without interruption.
A Gurbani channel may use a repeating programme, a live source, or a mixture of scheduled and fallback audio. A loop in the playlist does not solve an unavailable host: the playlist can continue only while the process playing it is running and can reach the listener-facing server. If you want to examine the playback side separately, the guide to creating and using YouTube playlists for live streams covers how YouTube playlists relate to a live channel; it does not change what happens to a separate radio-style endpoint during a VPS reboot.
Be precise about the service you mean by “stream”. A VPS radio mount for direct listening, an RTMP feed sent to YouTube, and a YouTube live broadcast have different delivery paths. If the audience listens on YouTube, a VPS failure may interrupt the encoder’s feed while YouTube’s player and the stream generator are different components. Check each public destination you actually use rather than treating one green service status as proof that all listeners have audio.
Why a restart policy cannot bridge host downtime
A process manager watches a process, not the physical availability of the machine around it. A policy such as systemd’s Restart=always can start Liquidsoap again when the process exits, including after the operating system comes back and the service is started. It cannot run that process while the VPS itself is powered down, applying updates, or waiting to boot.
This distinction matters because “automatic restart” is useful recovery, not continuous availability. It shortens the work needed after an application crash or a reboot, but listeners still have no functioning endpoint during the host outage if that host is their only endpoint. Liquidsoap’s production guidance recommends running it in the foreground under a service manager; that is sensible process management, not a claim that a service manager makes one host survive its own reboot.
On a single VPS, prepare for a recoverable interruption. Keep the stream service enabled at boot, make sure the service manager can start it, and validate any edited script before restarting. For Liquidsoap, the research notes describe checking a script with liquidsoap --check /etc/liquidsoap/radio.liq; confirm the command and configuration path for your installed version. After the machine returns, check service status, confirm the source has connected to the server, and listen at the public mount. A running process alone does not prove that audio is reaching listeners.
If the stream is a YouTube broadcast rather than an Icecast mount, confirm the encoder or upload process has resumed sending to YouTube and check the channel’s live output. The guide to telling whether YouTube is receiving RTMP audio and video separately can help distinguish an incoming feed issue from a playback issue. It is still necessary to test the audience-facing playback after maintenance.
Check whether an in-place reload is supported
Not every change needs a host reboot or even a full service restart. For a configuration-only change, first check whether the relevant application supports reloading its configuration while it runs. Liquidsoap’s Icecast-compatible server documentation describes a reload that preserves connected sources and listeners for the reload operation. Its Icecast server documentation also distinguishes settings that take effect immediately from settings that only apply after a restart.
That is a narrow, useful option, not a universal promise. The behaviour depends on the setting being changed, the server architecture, and the installed software version. Consult the documentation for the exact release running on your VPS and identify which changes require restart. The documentation pages in the research notes are development documentation; do not copy a setting or command without checking the matching stable reference for your installation.
An in-place reload is appropriate only when the component supports it and the change falls within the supported reload behaviour. It does not preserve listeners through an operating-system reboot, because the host and its network endpoint still go away. Nor does a configuration reload mean every source, listener, or server will remain connected for every change. Plan for the documented behaviour and test the particular change before relying on it for a devotional programme with listeners present.
If a reload is not supported, or the setting requires a restart, choose a quiet maintenance window and treat it as a service interruption unless another system is already serving listeners. Save the current configuration and note the previous working version so you can revert if the updated service does not accept its source or mount correctly. For a change to the visual side of a YouTube stream, the keyframe interval guide for Streamlabs OBS addresses an encoder setting, but changing encoder settings and restarting an Icecast service are separate operations.
Keep the listener endpoint on another running system
A second system can help only if it does the part listeners need during the primary host’s absence. One possible design keeps the public listener-facing relay on an independent host while the generator VPS is updated. The relay must have either a viable source that remains available or a fallback audio plan. Simply moving Icecast to a second machine while leaving the only audio generator on the rebooting VPS may leave the relay running but silent.
Think through the audio path, not just the server labels. Where does the source audio come from during maintenance? Does the relay receive that source independently? If the normal source disappears, does the relay play a prepared fallback, and does that fallback suit the channel? Which address do listeners use, and does that address continue to resolve to the running relay? Each answer is part of the design; a spare host by itself is not continuity.
Liquidsoap’s Icecast-compatible server documentation describes the generator-to-server-to-listener model and fallback mounts within that architecture. A fallback mount can help switch the source feeding a mount when the conditions are configured for it. It does not make a single VPS available during its own reboot. Read the relevant documentation for your version and test source loss and recovery deliberately.
For YouTube, keeping an independent public radio relay available is not the same as keeping the YouTube live broadcast running. The YouTube feed needs a separate healthy ingest path, and the broadcast’s audience-facing playback should be checked in its own right. Write down which destination your listeners use before choosing a maintenance design. That prevents a technically healthy Icecast mount from being mistaken for an uninterrupted YouTube channel, or vice versa.
Plan standby and traffic switching
An active-standby design has a primary system and a second, prepared system that can take over. For listeners to reach it, there must also be a traffic-switching method supported by the hosting provider or by the network design. That could involve moving an address or changing routing, but the method and its behaviour vary by provider. AWS’s floating-IP pattern for active-standby stateful servers is an example for AWS architecture, not a feature to assume on every VPS service.
A standby should be ready before maintenance begins. Consider whether it has the same configuration, media references, mount names, source credentials, and fallback material that the primary uses. Decide how it knows the primary is unavailable, who or what triggers the switch, and how you will avoid sending listeners to a standby that is itself unhealthy. A second machine with old configuration or no audio source is not a tested standby.
Traffic switching can reduce interruption, but existing listener sessions may still drop. The client’s connection is attached to a stream endpoint and a particular session; switching the address or server does not necessarily migrate that session to another machine. AWS’s architecture guidance notes that media endpoints may need reconnection and that active sessions can be dropped unless continuity is engineered separately. Tell listeners to reconnect if playback stops, and test this with real client players.
Compare the maintenance choices before selecting one:
| Change or design | What happens to the listener endpoint | What listeners should expect |
|---|---|---|
| Supported in-place reload | Same running server; only a documented reload occurs | Connections may remain for supported changes, but verify the exact setting and version |
| Service restart on one VPS | Endpoint is unavailable while its service stops and starts | A pause or dropped connection; process recovery does not bridge the stop |
| VPS reboot with one host | The only host and its endpoint are unavailable during reboot | Interruption until boot and service recovery; some listeners must reconnect |
| Independent relay with viable source or fallback | Relay remains on another running system | Audio may continue if source, fallback, and public address are all working |
| Tested standby with traffic switching | Traffic can move to a prepared system | Reduced interruption is possible, but sessions may drop and reconnect |
Choose based on the disruption you can accept and the complexity you can test and maintain. For a small channel with predictable maintenance, a communicated window and careful recovery checks may be more practical than a second host. If continuous listener access matters, invest in an independent path and test its failure mode rather than treating an additional VPS as an automatic solution.
Test maintenance and listener reconnection
Test the procedure before relying on it during a busy listening period. Start with a change that resembles the planned maintenance, using a test mount or a quiet window where practical. For a reload, verify that the exact configuration change is supported and observe whether existing source and listener connections remain. For a restart or reboot, record the actual sequence of events and how listeners recover; do not infer the result from service-manager status alone.
Use the public URL from a device or network outside the VPS. Listen long enough to confirm that audio is present and not merely that a connection opens. Check the source-to-server connection, the expected mount, the public stream, and any monitoring alerts. If you use a standby, test the trigger, switch, fallback audio, and the return to the primary. Verify whether the public address stays the same and whether a listener must press play again.
Keep a short maintenance checklist with the exact commands appropriate to your operating system and installed software. It can include saving the current configuration, checking the edited script, confirming services are enabled, notifying listeners, observing the update, checking the source and mount, and listening from the public endpoint. The guide to fixing buffering in a YouTube 24/7 stream can help investigate a separate playback symptom, but buffering checks do not replace a post-maintenance audio test.
Monitoring should check the listener-facing service, and ideally whether audio is actually present, rather than only whether the VPS responds to a ping. An online host can still have a stopped source, a failed mount, or silence on the public stream. Decide who receives an alert and what they will do with it, especially if the channel is unattended overnight.
Schedule and communicate maintenance
Before applying an update, classify it: configuration reload, application/service restart, or host reboot. This simple decision determines whether a single-host setup is expected to interrupt listeners. Save the known-good configuration and playlist or media references, check the provider’s maintenance notice if the provider is rebooting the VPS, and make sure you can reach the host if a service fails to start.
For a required reboot without an independent, tested endpoint, announce a maintenance window through the channel’s usual means. Do not promise an exact outage duration unless you have a reliable basis for that estimate; provider notices and your own measurements are the relevant sources. State plainly that playback may stop and that listeners may need to reconnect. For a community listening to a Gurbani programme, a clear notice is more useful than implying that an automatic restart means uninterrupted prayer or music.
If maintenance affects only an application setting, check the relevant reload documentation first and avoid rebooting the host unnecessarily. If the update requires a restart, prepare to verify the service after it returns. If continuity is a firm requirement, design and rehearse the independent relay or standby path before the maintenance date. StreamNeo can remove the need to keep your own computer running for a file-based YouTube broadcast, but it does not replace the separate planning needed for a VPS-hosted radio endpoint or make a VPS reboot invisible to listeners.
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 systemd keep my Gurbani stream live while the VPS reboots?
No. A service manager can start the process again after the host has booted, but it cannot keep a single rebooting host available. Expect an interruption unless another running system is already serving the listener endpoint.
Can an Icecast reload keep listeners connected?
Liquidsoap documents reload behaviour for its Icecast-compatible server that can preserve connected sources and listeners. Whether that applies depends on the setting and installed version; some settings need a restart. A reload does not protect listeners through a VPS reboot.
Does moving Icecast to another VPS guarantee that audio continues?
No. The relay needs an audio source that remains available or a configured fallback, and listeners need a stable route to the relay. If the only generator is on the rebooting VPS, the separate relay may stay online but have no programme audio.
Will listeners reconnect automatically after failover?
Some players may retry, while others may require the listener to press play. Existing sessions can be dropped when traffic switches, so test with the player types your audience uses and tell listeners how to reconnect.