Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Create a systemd service for the account that should own the session, start GNU Screen detached with a fixed name, and enable the unit. After a reboot, reconnect with screen -r autoscreen. This gives systemd responsibility for boot ordering and service lifecycle instead of relying on a login shell or a fragile startup script.
Why a reboot requires a boot service
GNU Screen keeps programs running after you detach from a terminal, and those programs remain active even when the Screen session is no longer attached to a terminal. A reboot is different: the operating system terminates every process. To create the session again, something must launch Screen during the next boot.
On a systemd-based Linux distribution, a unit file is the appropriate mechanism. It can express when the session should start, which account owns it, how it is stopped, and which command should be used to start it. The service below starts a detached session named autoscreen; it does not attach a terminal to the session during boot.
Prepare the account and executable
Decide which unprivileged account should own the Screen socket and the processes inside the session. In the examples, that account is alice. Substitute the real account everywhere; using a different account when reconnecting will make the session appear to be missing because Screen sessions are separated by user.
- Install GNU Screen using your distribution’s package manager if it is not already installed.
- Confirm the executable path with
command -v screen. The example uses/usr/bin/screen, but package layouts can differ. - Choose a long-lived command if the session is meant to host a worker or server. A session whose command exits immediately will disappear, even though systemd itself may still show the unit as active.
Do not create the session manually as root and then expect alice to find it. The Screen process, socket directory, files, and child programs should all belong to the account that will administer them.
Create a systemd template unit
Create /etc/systemd/system/screen@.service with the following contents:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →[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.targetThe @ makes this a template unit. When you enable screen@alice.service, systemd substitutes alice for %i. One template can therefore serve several accounts, although each instance in this example uses the same session name within its own user’s Screen namespace.
What each directive does
| Directive | Purpose |
|---|---|
After=network-online.target |
Orders startup after the distribution’s network-online target. It expresses ordering, not a guarantee that every remote service is reachable. |
Wants=network-online.target |
Pulls in the network-online target when the service is started. The target’s effectiveness depends on the network implementation installed on the distribution. |
Type=oneshot |
Tells systemd that the start command performs an action and then exits. Screen itself detaches and continues as a separate process. |
RemainAfterExit=yes |
Leaves the unit in an active state after the one-shot command exits, so systemd treats the session as started until the unit is stopped. |
User=%i |
Runs Screen as the account named by the template instance instead of as root. |
ExecStart |
Creates a detached Screen session with the stable name autoscreen. GNU Screen’s -D -m form is intended for detached startup, including startup scripts; -S assigns the session name. |
ExecStop |
Sends Screen’s quit command to the named session when systemd stops the unit. |
WantedBy=multi-user.target |
Places the enabled service in the normal multi-user boot transaction. |
The name is deliberately stable. A generated or changing name makes automated reconnects and administration harder. If you need a different name, replace autoscreen consistently in both Screen commands and in every reconnect command.
Enable the session for boot
Reload systemd after creating or changing the unit, then enable and start the instance for the intended account:
sudo systemctl daemon-reload
sudo systemctl enable --now screen@alice.service
sudo systemctl status screen@alice.service
sudo -u alice screen -ls
sudo -u alice screen -r autoscreensystemctl daemon-reloadmakes systemd read the new unit file.systemctl enable --nowcreates the boot-time enablement and starts the service immediately, so you can test it without rebooting.systemctl statusdisplays the unit state and recent start errors.screen -ls, run asalice, lists sessions visible to that account. You should see a session containing the nameautoscreen.screen -r autoscreenreattaches to the named session. Detach later with Screen’s detach key sequence rather than terminating the shell if the program should continue running.
To test the actual reboot path, reboot after this immediate-start test succeeds. Once the machine returns, run sudo systemctl status screen@alice.service and sudo -u alice screen -ls before attempting to reattach. Testing both views distinguishes a systemd failure from a Screen ownership or naming problem.
Launch a specific long-running program
Starting an empty shell is useful for an administrative session. For a worker, daemon-like command, or monitoring process, append the program and its arguments to ExecStart:
ExecStart=/usr/bin/screen -DmS autoscreen /usr/local/bin/my-workerUse the full path to the program and quote or escape arguments as required by systemd’s command-line rules. Verify the path independently before placing it in the unit. After editing the file, run sudo systemctl daemon-reload and restart the instance:
sudo systemctl restart screen@alice.service
sudo -u alice screen -lsScreen does not keep a session alive after its only foreground command exits. If my-worker fails during startup, the session may vanish immediately. Check the unit journal and run the command directly as the target user to identify missing files, permissions, environment variables, or configuration.
A program that expects a login shell may behave differently under systemd because there is no interactive terminal setup. Put required environment variables in the service deliberately, use absolute paths, and make the program log somewhere that can be inspected. Do not assume aliases, shell profiles, or a working directory from an interactive login are available.
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 problemsReconnect and administer the named session
List sessions as the owning account:
sudo -u alice screen -lsReattach by exact name:
sudo -u alice screen -r autoscreenScreen also provides -R, which can reattach an existing session and, depending on the situation, create one when no matching session exists. For a boot-managed service, prefer -r autoscreen when diagnosing failures: it reports that the session is absent instead of silently creating a replacement that systemd does not know about.
To stop the managed session cleanly, stop the unit:
sudo systemctl stop screen@alice.serviceThe unit’s ExecStop sends quit to the session. Starting it again uses the original ExecStart command. If you terminate Screen manually, systemd may still show the one-shot unit as active because of RemainAfterExit=yes; start or restart the unit to recreate the session.
Network-dependent programs and boot ordering
network.target is primarily an ordering milestone. Reaching it does not prove that an address has been assigned, DNS works, routes exist, or a remote endpoint accepts connections. A worker that contacts a database, queue, or API at startup can therefore fail even though the service is ordered after network.target.
The example uses network-online.target and a matching Wants= relationship. This is a better expression of intent for network-dependent work, but the target only helps when the distribution’s network stack provides an appropriate wait-online implementation. If the client still fails at boot, inspect the network manager’s wait-online configuration and the worker’s own retry behavior. A service-level retry or restart policy may be more reliable than assuming the first connection attempt will succeed.
Choosing system, user, compatibility, or scheduled startup
Several mechanisms can start a command, but they do not provide the same ownership, ordering, or lifecycle controls.
| Approach | Boot ordering | Ownership and logout behavior | Lifecycle and logs | Best fit |
|---|---|---|---|---|
| Systemd system unit | Explicit dependencies such as network-online.target |
Runs under the account named by User=; independent of an interactive login |
Start/stop state and journal entries are managed by systemd | Default for a server-wide reboot requirement |
| Systemd user unit | Controlled by the per-user manager | Can stop when the user manager ends or the user logs out unless that manager is configured to persist | User-level service controls and logs | Appropriate when the account’s user manager is deliberately kept alive |
/etc/rc.local |
Weak and distribution-dependent | Usually runs with broad privileges and little explicit ownership | No native unit lifecycle or dependency model | Compatibility with specific legacy System V setups |
| Cron or anacron | Not designed for precise boot dependency ordering | Environment and ownership depend on the scheduler entry | No service state for a continuously running session | Occasional jobs, not a persistent terminal session |
Systemd’s own documentation describes /etc/rc.local support as a compatibility mechanism and recommends proper unit files with dependencies for new boot work. Cron and anacron can launch commands, but they do not naturally express that a process should be considered a service, stopped deliberately, or diagnosed through a unit journal.
User units: when they are appropriate
A user service can be a good choice when the session belongs entirely to one user and that user’s systemd manager is configured to remain active without an interactive login. Without that persistence configuration, a user unit can stop when the user manager ends or the account logs out, defeating the goal of a reboot-persistent server session.
If you choose this model, keep the session and all administration commands in the same user context. Do not mix a user unit with a root-owned Screen session. Validate the behavior on the target distribution, especially across logout and reboot, before relying on it for unattended work. A system unit avoids the dependency on a persistent user manager and is generally simpler for a server that must start regardless of login state.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting failures
The unit is not found
Check that the file is exactly /etc/systemd/system/screen@.service, then run:
sudo systemctl daemon-reload
sudo systemctl status screen@alice.serviceA template file must include the @ before .service; the enabled instance includes the account name between them.
The service fails immediately
Inspect both the unit status and its journal:
sudo systemctl status screen@alice.service
sudo journalctl -u screen@alice.serviceCommon causes are an incorrect Screen path, a nonexistent account, a malformed unit directive, or a session name collision. Run command -v screen and update the absolute path if necessary. If the unit was edited, reload systemd before restarting it.
screen -ls shows no session
Run the listing command as the owning user:
sudo -u alice screen -lsThen verify the exact name in the unit and reconnect command. A root listing can be empty while alice has a valid session, and vice versa. If a specific program was appended to ExecStart, run that program directly as alice; it may be exiting immediately.
screen -r autoscreen cannot reattach
- Confirm that the session name is exactly
autoscreen, including capitalization. - Use the same account that owns the service.
- Check whether the target program exited.
- Read
journalctl -u screen@alice.servicefor startup errors. - Check for stale or conflicting sessions with
sudo -u alice screen -ls.
The network client fails only during boot
Review the unit’s ordering and confirm that it uses network-online.target rather than only network.target. Then inspect the distribution’s network-wait implementation and the application’s own connection logs. The online target improves ordering but cannot guarantee that a particular remote service is ready.
The session disappears after logout
This usually indicates a user service whose user manager is not persistent, or a process that was started in the wrong account context. For a server-wide requirement, use the system unit with User=alice. If retaining a user unit, configure and test persistence for that account on the distribution.
Change, disable, or remove the service
After changing the unit file, reload systemd and restart the instance:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo systemctl daemon-reload
sudo systemctl restart screen@alice.serviceTo prevent it from starting at future boots while leaving the unit file in place:
sudo systemctl disable --now screen@alice.serviceThe --now option stops the current session as it disables boot enablement. To remove the configuration entirely, disable and stop the instance first, delete /etc/systemd/system/screen@.service, and run sudo systemctl daemon-reload again. Removing the unit does not recover a program that has already exited or restore files deleted by a child process; handle those separately.
Quick Recap
Pre-reboot checklist
- The unit is stored at
/etc/systemd/system/screen@.service. User=%inames the account that will reconnect.command -v screenmatches the absolute path inExecStartandExecStop.- The session name is consistent everywhere.
- A specific command, if supplied, is long-running and works when run directly as the target user.
sudo systemctl enable --now screen@alice.servicesucceeds.sudo -u alice screen -lslists the session before reboot.- Network-dependent work is ordered after
network-online.targetand has suitable retry behavior. - You have checked the unit status and journal, not just whether a shell appears.
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.
