Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

On a Linux host that uses systemd, run your Python monitor as a foreground process managed by a .service unit. Systemd can start it now, launch it at boot, restart it after certain failures, and route its output to the journal—without requiring the script to daemonize itself.

Before you create the service

First confirm that the monitor runs successfully from a shell and remains in the foreground. Systemd supervises the process, so the script does not need to fork itself into the background. Identify the exact Python interpreter and script or module entry point the service should run. If the application depends on relative paths, configuration files, or other files in a particular directory, note its working directory too.

This guide applies to Linux systems using systemd. The tutorial underlying the workflow uses systemd version 229 as its example baseline; behavior and available settings can vary by release. Check the target host with systemctl --version and consult its installed systemd manual pages.

Choose a system service or a user service

Choice When it fits Important distinction
System service The monitor should run for the machine independently of a particular user’s interactive login. Use a deliberate runtime account and grant it only the access the monitor needs. A system service is administered through the system manager.
User service The monitor belongs to one user’s systemd instance and its permissions or lifecycle. User services normally follow that user’s manager and session lifecycle. The tutorial describes loginctl enable-linger to keep the user manager and service running without a logged-in session.

The example below is a system service. If the monitor needs to run independently of a login, this is usually the clearer choice. A user service can be preferable when machine-wide administration or privileges are unnecessary, but account for its session behavior.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Create a systemd unit

Create a plain-text unit file named /etc/systemd/system/server-monitor.service. Adapt the account, paths, and restart timing to the target host; this instructional example has not been tested as a universal configuration.

[Unit]
Description=Python server monitor

[Service]
Type=simple
User=server-monitor
Group=server-monitor
WorkingDirectory=/opt/server-monitor
ExecStart=/opt/server-monitor/venv/bin/python -u /opt/server-monitor/monitor.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
  • ExecStart= uses absolute paths to the virtual-environment interpreter and monitor script. This avoids depending on the interactive shell’s PATH. If you do not use a virtual environment, substitute the correct interpreter path for the host.
  • WorkingDirectory= sets the process’s working directory. Keep it if the application relies on relative paths; otherwise choose a suitable directory or omit the setting.
  • User= and Group= select the service identity. Create that account and ensure it can read the code, virtual environment, configuration, and certificates it needs, and access only the required files and network resources. Avoid running the monitor as root unless its required operations genuinely need that privilege.
  • Restart=on-failure asks systemd to restart the service after a failure. RestartSec=5 sets a five-second delay in this example, not a required value. Choose restart behavior and delay for the application’s failure modes; repeated attempts can encounter systemd start-rate limiting.
  • python -u requests unbuffered standard streams, which can make output appear promptly in the journal. Python 3.14.8 documents this option; check the documentation for the interpreter actually installed. An alternative described in the tutorial is PYTHONUNBUFFERED=1.

The unit uses Type=simple for a foreground process. Do not add After=network.target as proof that the network is usable: ordering after that target does not guarantee the network is fully online. If the monitor requires network access, build in application-level retries and timeouts, and consult the distribution’s systemd guidance for stronger ordering needs.

Load, start, and enable the service

Reloading the manager after a unit-file change, starting the service now, and enabling it for boot are separate actions. Run these commands on a systemd host:

  1. sudo systemctl daemon-reload — load the new or edited unit definition.
  2. sudo systemctl start server-monitor.service — run the monitor now.
  3. sudo systemctl status server-monitor.service — check whether it started and review its current state and recent messages.
  4. sudo systemctl enable server-monitor.service — configure activation at boot. Enabling does not, by itself, start a service immediately, so use the start command when you also want it running now.

After editing the unit later, run sudo systemctl daemon-reload and restart the service so the running process uses the updated configuration.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Inspect output and follow logs

When the service writes to standard output or standard error, the tutorial’s systemd example sends that output to system logging. The official journalctl manual describes the command as a way to print entries stored in the journal by systemd’s journal services.

  • sudo journalctl -u server-monitor.service shows journal entries for the unit.
  • sudo journalctl -f -u server-monitor.service follows new entries as they arrive.

System-journal visibility depends on permissions. If logs are inaccessible, use an account authorized to read them or ask an administrator. If print() messages appear late, use unbuffered output as shown above, set PYTHONUNBUFFERED=1, or configure the application’s logging to write appropriately to the journal.

Use a user service instead

For a user-scoped unit, place the unit in that user’s systemd configuration and use the user manager rather than the system manager. The corresponding commands use systemctl --user; for example, reload with systemctl --user daemon-reload, start with systemctl --user start server-monitor.service, and inspect with systemctl --user status server-monitor.service. To follow its logs, use journalctl --user-unit server-monitor.service -f.

A user service normally follows the user’s session lifecycle. If it must continue without an interactive login, the tutorial describes enabling lingering for that user with loginctl enable-linger. Alternatively, use a system service when the monitor should be managed independently of a particular user’s session.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose restart behavior deliberately

Restart=on-failure is a reasonable starting point for a long-running monitor that should return after an abnormal exit. A restart policy does not fix an invalid executable path, missing dependency, bad configuration, or persistent application error. If the process fails repeatedly, systemd’s start-rate limit can also stop further attempts. Check the installed systemd service-unit manual for the precise restart semantics and available settings on the host’s release.

Use the narrowest policy that matches the monitor’s intended behavior. A process that exits successfully by design may not need to be restarted; one that is meant to run continuously may need recovery after abnormal exits. Add delays and other controls only after considering how the application behaves during outages and repeated failures.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Troubleshoot common problems

Systemd cannot find the unit, or edits have no effect

  • Check the unit’s filename and location. For the system unit in this example, the path is /etc/systemd/system/server-monitor.service.
  • Run sudo systemctl daemon-reload after creating or editing the file.
  • Inspect sudo systemctl status server-monitor.service for the manager’s current view of the unit.

The process exits or restarts repeatedly

  • Inspect sudo journalctl -u server-monitor.service for the failure message.
  • Run the same interpreter and entry point manually as the service account, rather than only testing from your own login.
  • Verify the interpreter and script paths, working directory, file permissions, configuration, and dependencies.
  • Check whether repeated starts have reached systemd’s rate limit; a restart policy cannot cure a persistent application fault.

The service is enabled but not running

Enablement configures boot activation; it is separate from starting the unit now. Run sudo systemctl start server-monitor.service, then inspect its status.

The user service stops after logout

This can follow the normal relationship between a user manager and the user’s session. Use a system service if the monitor should not depend on that login, or configure lingering for the user manager as described above.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Journal entries are missing or inaccessible

Confirm the service is writing output and inspect the correct unit name with journalctl -u server-monitor.service. If you cannot read system logs, use an authorized account. If entries arrive only after a delay, address Python output buffering or configure application logging for the journal.

Check behavior against the installed versions

This procedure is specific to systemd, not a universal recipe for every Linux init system. The tutorial’s example is based on systemd version 229; consult the local manual pages for version-specific unit behavior. Python’s cited command-line reference is for CPython 3.14.8 and notes that other implementations can differ. Check systemctl --version and the documentation for the interpreter used by the service before relying on version-specific options.

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.