The slow way, made survivable Chapter 17 of 23 Svenska

The map · Part Two · The machine · Chapter 17 of 23

The nightly run

At half past ten a clock fires. Prices are re-checked against decisions already made, files are written, and the run leaves by one of two exits: a quiet signal to an outside observer, or a shout to the owner's phone. About 7 minutes.

Servers do not have a person sitting at them. To make something happen at the same time every day, you write two small files for the operating system's scheduler. One is a timer: it says when. The other is a service: it says what. The scheduler here is the one built into modern Linux, called systemd, and the files are called units.11deploy/vss.timer and deploy/vss.service.

The nightly cycle with both exitsA clock at 22:30 leads to a box, the run. A green arrow leads to a box with a tick: report and page written, one ping to the outside. A vermillion arrow leads to a box with a cross: a push to the phone saying what stopped. 22:30 every nightthe runfetch prices, compareto lines already setreport and page written;one ping to the outsidea push to the phone:what stopped, last log linessuccess is quiet on the phone and loud to the observer;failure is loud on the phone. Silence means something else.the run cannot write a decision: only the two foldersfor data and reports are writable to it
A clock fires, prices are checked against decisions already made, and files are written. Two exits: on success the machine tells an outside observer it is alive; on failure it tells the owner's phone what stopped.

When

Every day at 22:30, after the last European and American exchanges have closed and prices have settled. If the machine was off at 22:30, the timer runs the job as soon as the machine is back, rather than skipping the day.22OnCalendar=*-*-* 22:30:00; Persistent=true.

What

The nightly run loads the owner's file, fetches the day's prices, computes the fixed set of figures, compares each price with the lines already written for that name, writes the report, writes one row per name into the run database, and then generates the overview page. The page generation runs last and is arranged so that if it fails, the run is still a success: the report and the database row come first, and a failure to draw the page is logged as a warning, not a failure of the night.33The overview page 'rides on the same unit after the report and database row are written and cannot break the run'.

What it cannot touch

The run is fenced by the operating system, not only by its own code. It sees the whole system as read-only. It sees the owner's home directory as read-only. The only two folders it may write are the data folder and the reports folder. It cannot gain any new permissions once started, and it is killed if it runs for more than fifteen minutes.44ProtectSystem=strict; ProtectHome=read-only; ReadWritePaths= the data and reports folders only; NoNewPrivileges=true; TimeoutStartSec=15min. This is the first wall from chapter 14, drawn by a different hand: even if the code had a bug that tried to write a decision into the owner's file, the operating system would refuse.

The two exits

A run ends in one of two ways, and each way makes a different sound.

  • Success. Immediately after the run completes, a separate one-line script sends a single, empty request to an outside monitoring service. It carries no company name, no price, no report, no machine name: one request to an opaque address, meaning "the run happened". If that request itself fails, the run is still counted a success; a failed signal must not turn a good night into a bad one.55ExecStartPost=- the ping script; the leading dash means its failure does not fail the unit. The script's own comment: 'WHAT LEAVES THE MACHINE: one HTTP GET to an opaque UUID. No ticker, no price, no report, no hostname, no body.'
  • Failure. If the run exits with an error or is killed for running too long, the scheduler starts a second unit whose only job is to notify. That unit runs a plain shell script, deliberately not the program's own language, because the thing that broke may be the program's own environment. The script pushes a message to the owner's phone saying which unit stopped and what that means, with the last eight lines of the log.66OnFailure=vss-failure@%n.service; deploy/vss-notify-failure.sh. The heartbeat module: 'It is deliberately a plain curl in a shell script and NOT this package: the failure being reported may well BE this package.'

Notice the asymmetry. Success is silent on the phone. The owner does not want a message every night saying nothing happened; a message that always arrives is a message that stops being read. Success makes its sound somewhere else, to an observer whose job is to notice if the sound stops. That is chapter 18.

The weekly run

The screener runs on the same pattern, on Saturday mornings at 08:00, on Friday's settled prices, with a four-hour limit and a stricter fence: the folder holding the owner's file is not writable to it at all. That single line is the ruling "the scheduled screen never enters a name" written in the scheduler's language.77deploy/vss-screen.timer: Sat 08:00; the service's read-only configuration directory, described in the project brief as 'E93 in one line'. Measured 2026-08-31: about 38 minutes, 3,495 fundamentals requests, zero throttles. A third timer, at 09:30 every day, belongs to the dead man's switch.

The units, in words

vss.timer fires vss.service at 22:30 daily, catching up if missed. The service is one-shot, runs the nightly command in a sandbox writable only at the data and reports folders, pings the outside observer on success, and starts vss-failure@vss.service on failure. vss-screen.timer fires vss-screen.service on Saturdays at 08:00 with the configuration folder read-only. vss-checkin.timer fires vss-checkin.service at 09:30 daily. vss-failure@.service is a template: the name of the failed unit is filled in and passed to the notifier script, which always exits successfully, because "a failure notifier that can fail is a second thing to monitor".

Sources for this chapter

  1. The scheduler units and scripts — read from this repository: deploy/vss.timer, deploy/vss.service, deploy/vss-screen.timer, deploy/vss-checkin.timer, deploy/vss-failure@.service, deploy/vss-ping-healthcheck.sh, deploy/vss-notify-failure.sh, deploy/README.md

The slow way, made survivable. Built 2026-09-13 from the repository as it stood that day. NAME A and NAME B are fictional; no company, price or holding appears on this site. Not financial advice: one private investor's method, shared as it is.