A Linux server running systemd can start a Gurbani stream after a reboot by running its stream command through an enabled service unit. That boot setting is separate from the service’s restart policy, which determines what happens if the process exits unexpectedly while the server is running.
The steps below use a generic foreground process and a clearly labelled Liquidsoap example. Adapt the service name, command, account and file paths to your actual software; a Gurbani stream does not necessarily use Liquidsoap, Icecast or any particular layout.
Identify the stream process and its command
Before writing a unit, find out what actually creates and sends your audio. A setup may use a playlist player, an encoder, a radio automation program, a media server or a combination of them. The process you put under systemd should be the one that is expected to stay running and whose exit should count as a stream-process failure.
Write down the command that starts it, including its executable path, configuration or script argument, and any options. For example, a Liquidsoap installation might run /usr/bin/liquidsoap /etc/liquidsoap/gurbani.liq; that is only an example, not a default to copy blindly. Check the command you use on this host and where its files live. If you do not know, consult the software’s documentation or the person who installed the stream.
A command that works in your interactive shell may rely on that shell’s current directory, environment variables, user permissions or mounted files. A service starts in a different context. Make paths explicit, and note any environment setting the program genuinely needs. Do not paste passwords or stream keys into a public article, ticket or command history; store secrets only in a location and format supported by your software, with access restricted to the service account.
Also separate the audio generator from the delivery path. Your program may create audio, send it to a streaming server, and then expose a listener URL. These are distinct links: the process can be alive while the output is misconfigured, or the server can be running without receiving a source. A process status is an important check, but not proof that listeners hear the intended Gurbani.
If the stream is built around a playlist loop rather than a continuous radio process, first map how the playlist and output are joined. The guide to setting up a YouTube playlist loop in India offers context on that kind of workflow. For a server-based arrangement, the comparison of Lightsail and Hetzner for a YouTube playlist stream can help you think through hosting separately from service supervision.
Create a foreground systemd service
A systemd service gives the operating system a named process to start, monitor and report in its journal. For this to work cleanly, the program should remain in the foreground rather than detach itself into the background. If the command returns immediately after launching a separate child process, systemd may regard the managed process as finished and be unable to supervise the process you care about.
Create a unit under /etc/systemd/system/, for example /etc/systemd/system/gurbani-radio.service. A descriptive name makes status and log commands easier to read. A minimal template looks like this:
[Unit]
Description=Gurbani audio stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamuser
Group=streamuser
WorkingDirectory=/srv/gurbani
ExecStart=/usr/local/bin/your-stream-command /srv/gurbani/config-file
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
Replace every example value, including the executable, working directory, account, group and configuration argument. Type=simple is appropriate for a command that stays in the foreground; systemd treats the process it starts as the main service process. Do not add a forking service type merely because a program is a stream tool. If your software is designed to daemonise and cannot run in the foreground, follow its official service guidance rather than adapting this template as if all programs behaved the same way.
The example’s Wants= and After= lines ask systemd to bring in the network-online target and order this service after it. They do not test whether your particular remote endpoint is reachable, whether DNS is ready for your application, or whether the stream server has accepted a connection. If the process attempts a connection too early, inspect how your Linux distribution and network manager implement the target, and use the application’s supported retry behaviour where appropriate.
For a reference implementation, Liquidsoap’s production guide recommends running it in the foreground under a service manager and shows a systemd unit. Treat its command and account details as Liquidsoap-specific examples, not as requirements for every Gurbani stream. After creating or editing any unit file, tell systemd to reload unit definitions before asking it to use the updated configuration.
Set the service account, paths and dependencies
A system service should run as the account that has the access it needs, not automatically as root. Set User= and Group= to a real account on your host. The account must be able to execute the program, read its configuration and audio files, and write only to the log, cache or state directories the software requires. Check parent directory permissions too: read access to a file is not useful if the account cannot traverse the directories leading to it.
Some packages create a dedicated service account; others do not. Liquidsoap’s production guide describes account creation for certain package installations, but that does not mean the account exists on your machine or that its name matches this example. Verify with your system administrator or package documentation. Do not change ownership of broad directories or loosen permissions to make an error disappear without understanding what is being exposed.
WorkingDirectory= is useful when the program opens relative paths, but it does not replace explicit paths for important files. Prefer an absolute executable path and configuration path in ExecStart=. If the software reads credentials or environment variables, use its documented mechanism and protect the file or unit accordingly. Keep a private copy of the original configuration before making changes.
Dependencies need the same care. Ordering after network-online.target may be sensible for a stream that connects to an external endpoint, but it is not a guarantee of network reachability. If the process depends on a local media server, database, mounted storage or another service, identify that dependency and consult its unit documentation before adding an ordering relationship. A blind dependency can make recovery harder, while omitting a real one can create a race at boot.
There is a difference between making the generator run and making a full YouTube broadcast appear. If your design includes a separate encoder or a player on another host, verify how each component starts and reconnects. The article on testing a YouTube live stream privately before making it public is useful for checking the public-facing side without treating a running local service as the whole test.
Enable the service for boot
Once the unit file is saved, reload systemd’s unit definitions and enable the service for the appropriate boot target. The common system-service commands are:
sudo systemctl daemon-reload
sudo systemctl enable gurbani-radio.service
sudo systemctl start gurbani-radio.service
systemctl is-enabled gurbani-radio.service
systemctl status gurbani-radio.service
enable arranges for the unit to be started through its configured target during boot. It does not itself start a service that is already running, unless you use the combined enable --now form. Conversely, start starts it now but does not by itself arrange a start on the next boot. You can use sudo systemctl enable --now gurbani-radio.service after reviewing the unit if you want both actions together.
This distinction answers a common source of confusion: enabling a unit is about boot activation, not a promise that systemd will restart every crashed process. A service can be enabled and still fail at boot because its command is wrong, its account lacks access, a dependency is unavailable or the program exits. The Debian Project’s systemd services guide covers unit setup, enabling and checking service state. Commands can vary in permissions and surrounding tools, so use your distribution’s own documentation when needed.
Before rebooting a production channel, check that the service starts successfully now. This lets you fix syntax, path and permission errors while you still have access to the machine. Keep a record of the exact unit file and the command that works; it will make a later rollback much simpler. If you need to compare a managed process with a desktop-driven setup, the article on VLC versus Streamlabs Desktop for a pre-recorded YouTube channel discusses a different operating context, rather than replacing this service configuration.
Choose and understand a restart policy
The Restart= setting governs what systemd does after the service’s main process exits. It is independent of enabling the unit. For a long-running stream process, systemd’s service documentation identifies on-failure as the recommended choice. With that policy, systemd can try again after an unsuccessful exit or certain failure conditions, while an intentional clean exit does not automatically mean the service should be relaunched.
Restart=always is another possible choice when any process exit, including a clean exit, should result in another start. The Liquidsoap production example uses that policy. Whether it is right for you depends on what a clean exit means in your software: it might be unexpected for a continuous stream, or it might be a deliberate way to stop the programme. Do not copy the policy without deciding which behaviour you want.
The example includes RestartSec=5, a pause before a restart attempt. It is an illustrative value, not a universal tuning recommendation. A pause can prevent immediate repeated attempts, but it will not repair a missing file, invalid configuration, expired credential or unreachable destination. Check the systemd manual for the effects of the policy and the host’s configured start-rate limits; repeated failures can eventually be rate-limited instead of being retried indefinitely.
| Choice | What it means | Consider it when |
|---|---|---|
Restart=on-failure |
Restart after a failure, rather than after an ordinary clean exit. | A clean exit should remain stopped or be investigated. This is systemd’s recommended policy for long-running services. |
Restart=always |
Restart after a clean exit as well as a failure, subject to systemd’s rules and limits. | Any exit from a continuously required process should lead to another attempt. |
| No automatic restart | Leave the process stopped after it exits. | You need an operator to inspect every exit, or automatic attempts would be unsafe. |
A deliberate systemctl stop is not supposed to trigger the same automatic restart as an unexpected process exit. That makes it practical to stop the stream for maintenance even when a restart policy is configured. For more detail, consult the systemd.service manual, including its restart behaviour and start-rate caveats. Restart automation is a recovery aid; if the process repeatedly fails, read the reason and fix it rather than treating more attempts as a solution.
Check service status and logs after reboot
When the unit starts, check both whether it is enabled and whether it is currently active. After a planned reboot, use:
systemctl is-enabled gurbani-radio.service
systemctl status gurbani-radio.service
journalctl -u gurbani-radio.service -b
The status output provides a summary and often the latest log lines. The journal command narrows output to this service for the current boot, which helps distinguish a new failure from an older one. If the logs are too brief, check the program’s own logging settings and whether it writes to standard output and error, which systemd can collect for the service.
Read the actual error rather than stopping at a red or green status indicator. “No such file” points towards a path or working-directory problem. A permission error suggests the service account cannot access something it needs. An authentication or connection error may come from the remote stream destination or a separate local server. A repeated start followed by exit usually means the underlying command is failing, not that the enable step is missing.
If is-enabled reports the unit is disabled, enable the unit you intend to use and confirm the service name is correct. If it is enabled but inactive after reboot, inspect the current-boot journal and the unit’s dependencies. If it is active but there is silence, check the source audio, generator output, streaming endpoint and listener URL individually. The status only describes systemd’s managed process; it cannot tell you whether the right Gurbani programme is reaching a listener.
Test recovery and refine the setup
Test in stages, with a maintenance window if listeners depend on the channel. First confirm the command and unit start correctly without rebooting. Then restart the service deliberately and verify that it returns to the expected state. Finally reboot the host and repeat the status and journal checks. From a separate device or network, open the listener URL and confirm that the expected audio is present rather than relying only on the server’s local view.
If you specifically need to test automatic recovery after a process exit, plan a safe test rather than killing arbitrary processes on a live host. A controlled stop through systemd is useful for verifying how the unit behaves when an operator stops it, but an intentional stop is not equivalent to a process crash. For a failure-policy test, use a non-production copy or a maintenance window and follow the software’s guidance for a safe simulated failure. Check both the resulting journal and the listener path.
A useful checklist is to confirm that the unit is enabled, the foreground command remains the main process, the account can read the required media and configuration, dependencies are available, and the stream reaches the expected endpoint. If the unit starts but the output does not, inspect each hop separately: audio source, generator or encoder, any media server, and the client URL. If a local listener works but the intended platform does not, troubleshoot that hand-off separately rather than changing the service restart policy at random.
For a Liquidsoap script, its production guide recommends checking a modified script with liquidsoap --check and the relevant file path before relying on a restart. Other software will have its own validation tools; use those rather than assuming this command applies. Keep a copy of the known-good configuration, make one change at a time, and record what changed. If failures repeat, the journal should guide the correction; a restart loop can otherwise obscure the first useful error.
If the maintenance burden is keeping a channel offline when a server restarts, a managed file-to-live workflow may remove the need to keep your own computer running the broadcast. StreamNeo is relevant to that specific pain when the goal is a YouTube-only stream from an uploaded file, rather than supervision of a Linux process you administer yourself. It does not replace checks of your content, channel or listener experience.
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 systemctl enable restart a stream if it crashes?
No. Enabling arranges for a unit to start through its configured boot target; the Restart= setting controls the service manager’s response to process exits. Configure and test both behaviours for your actual service.
Should I use Restart=on-failure or Restart=always?
Use on-failure if a clean exit should leave the process stopped, and consider always if every exit should trigger another start. Systemd recommends on-failure for long-running services, while the Liquidsoap example uses always; choose based on the program’s intended behaviour.
Does this setup require Liquidsoap or Icecast?
No. The example is a systemd pattern, not a claim about your stream stack. Use the actual foreground command and identify any separate generator, streaming server or listener components in your setup.
Why can the service show as active while listeners hear silence?
An active service means systemd considers its managed process active; it does not verify the entire audio path. Check the source, generator output, any media server or endpoint, and the listener URL separately.