systemd: start, stop, journalctl

On a LogicWeb VPS you manage services with systemd. Use systemctl to start, stop, enable, or restart a unit, and use journalctl to read that unit’s log when something fails. Checking status first, then the recent journal lines, usually shows a missing file, a busy port, or a bad config before you change anything else.

Three kinds of commands matter day to day. start and stop act right now. enable and disable control whether the unit comes back after a reboot. restart stops then starts the process when it is stuck; reload asks the daemon to reread its config without dropping every connection, and systemd will say so if the unit has no reload support.

journalctl -u nginx -e –no-pager | tail -n 40

-u nginx selects the unit by name, not a log file path. -e jumps to the end of the journal. --no-pager prints straight to the terminal so you can copy the output. Those last lines often show bind failures, a wrong certificate path, or a config test that never ran. Add -b when you only want the current boot, so older noise does not hide today’s error.

Reading status and crash loops

Run systemctl status on the unit before you restart anything. A unit stuck in activating (auto-restart) is not healthy; status will show a rising restart counter. Read the journal first, then fix the config, the permissions, or a full disk. Do not delete whole trees under /var/log just to free space, because that removes the evidence of what filled the disk. Rotate logs or truncate a runaway access log, then find the process that was writing so hard.

systemd is what starts services when the server boots. Leaving a long-running process only in screen or a manual shell means it dies on logout and leaves no clear unit status. For most tickets, status, enable, and journalctl are enough. If the unit is failed and you already read the log, reset-failed and start is the next step, not a reinstall.

enable, start, and what happens after reboot

Starting a unit makes it run now, but it will not return after a kernel update or reboot unless it is enabled. The reverse also happens: a unit is enabled, fails early because a mount is late, and the console looks fine until the first real request. After you fix a crash loop, enable the unit if you want it after reboot, start it if you want it now, and confirm with systemctl is-enabled and systemctl is-active.

Logs from a previous boot remain available only when the journal is persistent on disk. If you rebooted to clear a bad state, journalctl -u nginx -b -1 shows the boot you actually need. The current boot may only show a clean start and hide the original failure.

A short checklist that works on tickets

1. Check systemctl status unitname and note Active state and the restart count.
2. Read recent lines with journalctl -u unitname -e --no-pager, adding -b for this boot only.
3. Fix the config, path, port, or disk issue the log names; then reload or restart as appropriate.
4. Use enable when you need the service after reboot, and verify with is-enabled and is-active.

You have root on a KVM VPS, so these commands run as root or via sudo. Shared hosting does not give root or systemd control; there you use cPanel and the tools on the account instead. Keep changes small, read the journal before you restart again, and you will solve most unit failures without guessing.