Create a systemd service for the account that should own the session, start GNU Screen detached with a fixed name, enable the unit, and reconnect with screen -r NAME. This recreates the session during every boot and gives Linux a defined boot order and service lifecycle instead of relying on a shell login.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
# /etc/systemd/system/[email protected]
[Unit]
Description=GNU Screen session for %i
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
User=%i
ExecStart=/usr/bin/screen -DmS autoscreen
ExecStop=/usr/bin/screen -S autoscreen -X quit
[Install]
WantedBy=multi-user.targetSave the template as /etc/systemd/system/[email protected], replace alice below with the real account, then run:
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →sudo systemctl daemon-reload
sudo systemctl enable --now [email protected]
sudo systemctl status [email protected]
sudo -u alice screen -ls
sudo -u alice screen -r autoscreenWhat this setup does
GNU Screen is a terminal multiplexer. Programs inside a detached Screen session continue running even though no terminal is attached to it. The -d -m options (combined as -Dm) create a session in detached mode, which is why they are suitable for a boot service.
A reboot is different from disconnecting SSH or closing a terminal: the operating system terminates every ordinary user process during shutdown. Screen cannot preserve a process through that event by itself. The systemd unit solves the problem by creating a fresh session after the machine starts. It does not restore the old in-memory session or any unsaved program state.
The example uses a template unit. The @ lets the account name become the instance value, so [email protected] runs Screen as alice. Running it as the owning account is essential because Screen stores session sockets in that user’s runtime area and a different account will not see the same sessions.
Prepare the account, command and session name
Confirm that Screen is installed
Check the executable path before writing the unit:
command -v screenThe sample uses /usr/bin/screen, but package layouts differ between distributions. Replace that path in both service commands if command -v reports another location. An absolute path is preferable in a systemd unit because systemd does not provide the same interactive PATH as your login shell.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose the owning account
Use an existing, non-root account whenever the program does not genuinely require administrative privileges. The account must be able to read and execute the target program and access any files, sockets or credentials that program needs. The User=%i line means the instance name must resolve to a valid local account.
Choose a stable name
autoscreen is only an example. A predictable name makes reconnecting and troubleshooting easy:
screen -ls
screen -r autoscreenUse a different name if one already exists for that account. Screen names are scoped by user, so always run listing and reconnect commands as the same account that owns the session.
Decide whether Screen should run a program
A bare screen -DmS autoscreen creates an interactive shell in a detached session. If the objective is a worker, client or script, put its absolute command after the Screen options. For example:
ExecStart=/usr/bin/screen -DmS autoscreen /usr/local/bin/my-workerScreen remains useful here because the program has a terminal-like environment and can be inspected later by attaching. The session ends when the command exits, so verify that the target is genuinely long-running.
Create and enable the systemd template
1. Write the unit file
Create /etc/systemd/system/[email protected] with the following contents:
[Unit]
Description=GNU Screen session for %i
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
User=%i
ExecStart=/usr/bin/screen -DmS autoscreen
ExecStop=/usr/bin/screen -S autoscreen -X quit
[Install]
WantedBy=multi-user.target2. Understand the important directives
| Directive | Purpose |
|---|---|
After=network-online.target |
Orders this unit after the network-online target. It is useful when the command needs a usable network connection, not merely a network stack that has started. |
Wants=network-online.target |
Asks systemd to pull in the network-online target. The target’s effectiveness depends on the distribution’s network-wait implementation. |
Type=oneshot |
Treats the detached Screen launch as a one-time start action. |
RemainAfterExit=yes |
Keeps the unit in an active state after the start command returns, even though the detached Screen process is separate. |
User=%i |
Runs Screen as the account named by the template instance, such as alice. |
ExecStart |
Creates the detached session with the fixed name autoscreen. |
ExecStop |
Asks Screen to terminate the named session when the unit is stopped. |
WantedBy=multi-user.target |
Places the service in the normal multi-user boot target when enabled. |
3. Reload, enable and start it
After saving the file, make systemd reread unit definitions, enable the instance for future boots, and start it now:
sudo systemctl daemon-reload
sudo systemctl enable --now [email protected]
sudo systemctl status [email protected]enable creates the boot-time relationship; --now also starts the service immediately. If you prefer to inspect the unit before starting it, use sudo systemctl enable [email protected] followed later by sudo systemctl start [email protected].
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallReconnect and verify the session
List sessions as the correct user
Do not run the check as your own login account if the service belongs to someone else:
sudo -u alice screen -lsA healthy result lists a session whose name includes autoscreen. If you run plain screen -ls as root or another user, it may report no sessions even though the service worked, because each account has its own Screen socket directory.
Attach to the named session
Reconnect with:
sudo -u alice screen -r autoscreenOnce attached, use Screen’s normal detach keystroke to leave the program running. The exact key sequence depends on your Screen configuration; detaching is not the same as terminating the session.
Test the actual reboot path
After confirming the first start, reboot during a maintenance window and check again:
sudo reboot
# after reconnecting by SSH or console
sudo systemctl status [email protected]
sudo -u alice screen -lsThis test catches boot-order, account, path and network assumptions that are invisible when you start the unit manually after logging in.
Starting a specific long-running command
Append the command to ExecStart rather than launching it from an interactive shell. For example:
[Service]
Type=oneshot
RemainAfterExit=yes
User=alice
ExecStart=/usr/bin/screen -DmS autoscreen /usr/local/bin/my-worker
ExecStop=/usr/bin/screen -S autoscreen -X quitUse the real executable path and include required arguments on the same line. Check the path with command -v my-worker when the program is on the system PATH; for scripts, point to the interpreter or an executable wrapper with a valid shebang.
Keep initialization that needs shell syntax in a separate executable script instead of assuming that systemd will parse shell operators. Constructs such as pipes, redirection and variable expansion are not interpreted as they would be in an interactive shell unless you explicitly invoke a shell, and doing so introduces additional quoting and privilege considerations.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →What happens when the command exits
If the command finishes immediately, Screen has no process left to keep in its window and the session can disappear. This commonly explains a successful systemd start followed by “No screen session found.” Run the command directly as the target account first and confirm that it stays alive:
sudo -u alice /usr/local/bin/my-workerIf it is intended to run once, Screen is not a persistent-session solution for that workload; use a service designed to represent the command’s own lifecycle instead.
Why systemd is preferred over older boot hooks
For a new Linux boot service, systemd expresses ordering, ownership and stop behavior in one unit. The alternatives below can still appear on older systems, but they have different trade-offs.
| Approach | Boot ordering | Ownership and logout behavior | Lifecycle and diagnostics | When it fits |
|---|---|---|---|---|
| System systemd unit | Explicit dependencies such as network-online.target. |
Runs as the account specified by User=; independent of an interactive login. |
Inspectable with systemctl status and journalctl; can be started and stopped consistently. |
Default choice for a server-wide reboot requirement. |
| User systemd unit | Managed by that user’s systemd instance. | May stop when the user manager stops or the user logs out unless persistence is deliberately configured. | Convenient per-user ownership, but persistence must be tested on the target distribution. | Personal workloads where a persistent user manager is intentionally maintained. |
/etc/rc.local |
Usually broad and distribution-dependent. | Often runs with root’s environment unless the script drops privileges itself. | Compatibility mechanism with less precise dependency and failure handling. | Legacy scripts on systems that still provide it; not the preferred design for new services. |
| Cron or anacron | Does not model service dependencies such as network readiness. | Environment and ownership depend on the scheduler entry. | Weak fit for a continuously running terminal session and its stop/restart lifecycle. | Scheduled, finite jobs rather than a persistent Screen session. |
The systemd documentation describes rc.local support as a compatibility feature and recommends proper unit files with dependencies for new boot work. A cron entry can start Screen, but it does not give the same relationship to shutdown, ordering or service inspection.
Network-dependent programs need more than network.target
network.target expresses ordering; it does not prove that an interface has an address, a route or working DNS. If the Screen command connects to a remote service, use After=network-online.target and the matching Wants=network-online.target relationship, as in the example.
“Online” is implemented differently by network managers, and on some systems the target may provide little additional waiting. If a client still fails only during boot, inspect the distribution’s network-wait implementation and its journal. You may need the client itself to retry or a wrapper to wait for the specific endpoint rather than relying on a generic target.
Understand the unit’s supervision limits
The sample is intentionally a simple launcher. Because screen -DmS detaches and returns immediately, systemd records the start action as complete. RemainAfterExit=yes keeps the unit marked active, but it does not make systemd monitor every process inside the Screen window.
If the worker later crashes, the unit may still appear active while the Screen session is gone. Check the session with screen -ls when diagnosing this situation. Workloads that require automatic process restarts, health checks or resource limits are usually better represented by a dedicated foreground service; Screen can then be used separately for interactive observation when appropriate.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsTroubleshooting by symptom
systemctl enable --now fails
- Check syntax and the full failure reason with
systemctl status [email protected]. - Read the unit’s journal:
journalctl -u [email protected]. - Run
sudo systemctl daemon-reloadafter every edit to the unit file. - Verify that the instance account exists and that the Screen path in
ExecStartmatchescommand -v screen.
The service is active but no session appears
- List sessions as the owning account:
sudo -u alice screen -ls. - Confirm the exact name. The reconnect command must use
autoscreen, not the unit name. - Check whether the command appended to
ExecStartexited immediately. - Look for a second manually created session with a conflicting name and stop it before retrying.
screen -r autoscreen reports no session
- Use the same user that owns the service; Screen sockets are not shared across accounts.
- Run
screen -lsand copy the displayed session name exactly. - Inspect
journalctl -u [email protected]for an invalid executable, permission error or failed start.
A network client fails only after reboot
- Verify that the unit contains both
After=network-online.targetandWants=network-online.target. - Check the system’s network-wait implementation and the client’s own retry behavior.
- Read the service journal at boot time to distinguish DNS, authentication and application failures from Screen startup problems.
Stopping the unit does not cleanly close the session
Confirm that the session is named autoscreen and owned by the instance account. The stop command addresses that exact name. If the target program already exited, there may be no Screen session left to close; inspect screen -ls before treating that as a boot failure.
Operational and security considerations
- Least privilege: run the session under the service account that needs it, not root by default.
- Environment: systemd does not recreate every setting from an interactive login. Put required paths, working directories and configuration in the command or a controlled wrapper.
- Credentials: avoid placing secrets directly in a world-readable unit. Use permissions and a credential mechanism appropriate to the distribution.
- Logging: Screen provides the interactive view; systemd’s journal records unit start and stop failures. Configure the application’s own logging if you need a durable record after the session is gone.
- Duplicate starts: keep one authoritative unit and one stable session name. Manual launches with the same name can create confusion during recovery.
- Shutdown behavior: stopping the unit invokes
screen -S autoscreen -X quit, which terminates the named Screen session and the program running inside it.
Quick deployment checklist
- Choose the non-root account that should own the session.
- Run
command -v screenand use the returned absolute path. - Create
/etc/systemd/system/[email protected]with the template contents. - Replace
alicein commands with the real account name. - Append the target command to
ExecStartif the session should launch a worker or client. - Run
sudo systemctl daemon-reload. - Run
sudo systemctl enable --now [email protected]. - Verify with
sudo systemctl status [email protected]andsudo -u alice screen -ls. - Reconnect with
sudo -u alice screen -r autoscreen. - Test after a real reboot and inspect the journal if the session or network client is missing.
Bottom line
A named, detached Screen session launched by a systemd template is the dependable way to recreate an interactive session after reboot. Give systemd the correct Screen path, run it as the intended user, order network-dependent work after the appropriate target, enable the instance, and always verify the session as that same user. Remember that this pattern recreates the session; it is not a substitute for application-level supervision when the process must be restarted after a crash.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
