А якщо все впаде

Що ти зробиш сьогодні

Теорія

1. Три поломки, які трапляються насправді

Твій сервіс працює три місяці. За цей час він жодного разу не зупинявся надовго, і коли щось працює саме, легко забути, що воно взагалі може зупинитися. Сьогодні розберемо три поломки. Вони не вигадані для заняття: кожну з них ти цілком можеш зустріти на своєму сервері, і всі три трапляються без жодної складної причини.

Перша: зникли або зіпсувалися дані. Уся твоя база — це один файл ~/data/app.db. Його можна видалити командою rm, набраною не в тій теці. Його можна зіпсувати запитом DELETE FROM habits, у якому забули WHERE, — і тоді таблиця лишиться, а рядків у ній не буде. Його можна перезаписати, скопіювавши старий файл поверх нового по FTP — це спосіб передавати файли між своїм компʼютером і сервером, для нього на компʼютері ставлять окрему програму-клієнт. У всіх трьох випадках код цілий, служба працює, сторінка відкривається — і на ній порожньо.

Друга: зупинився процес.

Процес

Запущена програма. Коли ти набираєш python main.py, система створює процес: виділяє йому памʼять, дає номер і починає виконувати код. Закриється процес — програма перестане відповідати, навіть якщо файл із кодом нікуди не подівся.

PID

Номер процесу (process identifier). Ціле число, яким система розрізняє запущені програми між собою. За цим номером процесу можна надіслати команду, наприклад «завершитися».

Служба

Процес, який сервер тримає запущеним постійно і сам запускає знову, якщо той зупинився. Твоя служба називається club-api, ти налаштував її на занятті 02.

systemctl --user

Команда, якою дивляться стан своїх служб і керують ними: запустити, зупинити, перезапустити. Частина --user означає «мої служби, запущені від мого імені», а не системні — на них у тебе немає прав. Далі на сторінці ця команда трапляється постійно: systemctl --user status club-api показує докладний стан, systemctl --user is-active club-api — одне слово (active, failed або inactive).

Журнал, journalctl

Усе, що твоя програма друкує під час роботи, система записує в журнал — спільне сховище повідомлень від усіх служб. Читають його командою journalctl --user -u club-api -n 30 --no-pager: -u (unit) обмежує вивід однією службою, -n 30 лишає останні 30 рядків, --no-pager друкує їх одразу, без гортання. Саме туди потрапляють повідомлення про помилки, які інакше ніхто б не побачив.

Порт

Число від 1 до 65535, за яким на одному сервері розрізняють програми, що приймають запити. Твоя служба слухає свій порт, наприклад 8014, і саме тому адреса http://127.0.0.1:8014/api/ping потрапляє до неї, а не до чужої програми. Два процеси не можуть зайняти той самий порт: другий не стартує.

Твій процес може зупинитися з трьох причин. Помилка в коді: якщо в main.py зʼявився SyntaxError, то uvicorn — програма, яка запускає твій застосунок і приймає для нього запити, — не зможе стартувати взагалі. Перевищення обмежень: службі можна задати межу памʼяті рядком на кшталт MemoryMax=200M, і якщо твій код почне складати в список мільйони рядків, система зупинить процес, щойно він цю межу перевищить. І людина: хтось виконав команду завершення процесу, зокрема ти сам, коли перевіряв щось у терміналі.

Третя: скінчилося місце на диску. Це найменш очевидна з трьох, бо вона настає поступово. Файли логів стають більшими з кожним записом, копій бази щодня додається ще одна, і в якийсь день на розділі не лишається вільних байтів. Тоді SQLite — програма, яка веде твій файл бази, — не може записати новий рядок і відповідає помилкою database or disk is full. Служба при цьому запущена, сторінка відкривається, читання працює — не працює тільки додавання.

Спільне в усіх трьох поломок одне: коли вони трапляються, ти дізнаєшся про це не одразу, а коли хтось спробує скористатися сервісом. Тому сьогодні ми робимо дві речі — готуємо копію даних заздалегідь і записуємо порядок дій, поки є час подумати спокійно.

2. Копія бази і чому звичайне копіювання підводить

Бекап

Копія бази, збережена в окремому файлі на випадок, коли робочий файл зникне або зіпсується. Слово походить від англійського backup — «запасний». Українською кажуть також «резервна копія»; далі на сторінці — «копія».

Перше, що спадає на думку: скопіювати файл бази командою cp. Так роблять, і здебільшого це працює, але в цьому способі є дві проблеми.

Проблема перша: одне імʼя. Команда cp ~/data/app.db ~/backups/app.db щоразу створює файл із тим самим імʼям, тобто затирає попередній. Через тиждень у тебе буде одна копія — учорашня. Уяви, що в суботу в коді зʼявилася помилка й він почав записувати порожні назви. У вівторок ти це помічаєш, відкриваєш копію — а вона зроблена в понеділок і містить ті самі порожні назви. Ось чому копій має бути кілька, з різними іменами, і серед них — старіші за помилку.

Ротація копій

Правило, за яким старі копії видаляються, щойно їхня кількість перевищує задану. У нас зберігається сім останніх: цього досить, щоб повернутися на тиждень назад, і при цьому копії не заповнять диск.

Проблема друга: копіювання під час запису. SQLite зберігає базу не одним шматком, а сторінками — блоками по кілька кілобайтів. Коли ти додаєш запис, змінюється відразу кілька сторінок у різних місцях файлу. Якщо cp почне читати файл посеред такого запису, він устигне прочитати частину сторінок у новому стані, а частину — у старому. Файл скопіюється, розмір буде правильний, а всередині опиниться суміш двох станів. SQLite назве такий файл malformed — пошкодженим — і відкрити його не вдасться.

Ймовірність цього невелика: запис триває мілісекунди. Але копія робиться раз на добу протягом місяців, і рано чи пізно копіювання збіжиться із записом. Розвʼязання просте: копію робить сам SQLite. У Python для цього є метод backup() — він працює через ту саму бібліотеку, що й звичайні запити, тому знає про сторінки й блокування і віддає узгоджений файл.

src = sqlite3.connect(DB)          # робоча база
dst = sqlite3.connect(out)         # новий файл під копію
with dst:
    src.backup(dst)                # копіюємо силами самої SQLite

І ще одне про місце зберігання. Наші копії лежать у ~/backups — на тому самому диску, що й база. Від видаленого файлу це захищає, від відмови самого диска — ні. Тому копію корисно час від часу забирати до себе на компʼютер по FTP: тоді вона є у двох різних місцях. Для курсу цього достатньо.

3. Перевірка відновлення

Копія, яку жодного разу не відкривали, нічого не гарантує. У теці можуть лежати сім файлів по сорок кілобайтів, а всередині — порожні бази: скрипт відпрацьовував, але брав шлях до бази, якої вже немає, і щоразу створював новий порожній файл. Це виявляється тільки тоді, коли копію відкривають, — тобто коли вона вже потрібна. Тому копію треба хоча б раз відкрити й подивитися, що в ній.

Перевірка складається з двох питань. Перше: чи файл цілий? Друге: чи в ньому ті самі дані, що в робочій базі?

PRAGMA integrity_check

Команда SQLite, яка читає всю базу від початку до кінця і перевіряє, чи узгоджені між собою її внутрішні структури. Якщо все гаразд, вона повертає одне слово ok. Якщо ні — перелік того, що зламано. Слово PRAGMA означає, що це не запит до даних, а вказівка самій базі щось зробити або щось про себе розповісти.

Тимчасова тека

Тека, куди кладуть файли на короткий час. Копію бази перед перевіркою переносять туди навмисно: SQLite під час відкриття може дописати до файлу службові дані, і робити це просто в теці з копіями не варто — нехай копії лишаються такими, якими їх записали.

Друге питання — про кількість рядків. Якщо в робочій базі 34 записи, а в копії 34, копія свіжа й повна. Якщо в копії 12 — вона стара або зроблена не з того файлу. Якщо 0 — скрипт копіює порожнечу, і це треба виправляти сьогодні, а не тоді, коли копія знадобиться.

Саме ці два кроки виконує автоперевірка заняття: бере останній файл із ~/backups, кладе його в тимчасову теку, виконує PRAGMA integrity_check і звіряє кількість рядків із твоєю робочою базою. Назву головної таблиці програма бере з project.yaml, з поля main_table, — того самого, яке ти заповнював на занятті 04.

4. crontab: розклад команд без участі людини

Копія, яку треба робити руками, рано чи пізно перестане робитися. Значить, запускати скрипт має система.

cron

Програма, яка постійно працює на сервері й раз на хвилину дивиться, чи не настав час запустити якусь із запланованих команд. Якщо настав — запускає.

crontab

Особистий розклад команд одного користувача: список рядків, де в кожному спочатку записано «коли», а потім «що запустити». У кожного користувача сервера свій crontab, і команди з нього виконуються від його імені. Саме тому sudo тут не потрібен — ти плануєш свої команди у своїй теці, а не системні.

Рядок розкладу складається з пʼяти чисел і команди:

хвилина  година  день_місяця  місяць  день_тижня   команда
   17       3          *          *        *       /home/bohdan.g9/app/backup.py

Зірочка означає «будь-яке значення». Рядок вище читається так: коли хвилина дорівнює 17, а година дорівнює 3, у будь-який день місяця, у будь-який місяць, у будь-який день тижня — запусти цю команду. Тобто щодня о 3:17 ночі.

Чому саме 3:17, а не рівно третя. О рівних годинах у системі запускається багато чого одразу, і дванадцять учнівських скриптів у ту саму секунду створять непотрібне навантаження. Дивна хвилина розводить запуски в часі. Це звичайна практика, і в тебе може бути своя хвилина.

Далі — три речі, через які cron найчастіше не спрацьовує в того, хто налаштовує його вперше.

Оточення майже порожнє. Коли ти працюєш у терміналі, у тебе є змінні оточення, зокрема PATH — список тек, де система шукає програми за іменем. cron запускає команду з коротким PATH і без твоїх налаштувань. Тому в розкладі шляхи пишуться повністю: /home/bohdan.g9/app/backup.py, а не backup.py і не ~/app/backup.py.

Вивід нікуди не видно. Термінал не відкритий, тому все, що скрипт друкує, не побачить ніхто. Щоб не втратити цей вивід, його спрямовують у файл:

17 3 * * * /home/bohdan.g9/app/backup.py >> /home/bohdan.g9/logs/backup.log 2>&1

Знак >> означає «дописати в кінець файлу», один знак > означав би «затерти файл і записати заново». Запис 2>&1 додає до цього файлу ще й потік помилок: у Unix програма пише в два окремі потоки — звичайний вивід (номер 1) і повідомлення про помилки (номер 2), і без 2>&1 помилки пройшли б повз лог. А саме вони цікавлять найбільше.

Файл має бути запускним. cron не здогадається, що .py треба віддати Python. Тому скрипт починається з рядка, який називає потрібну програму, і йому ставлять ознаку «можна запускати» командою chmod +x. Про це — на практиці.

Рядок у розкладі працює доти, доки ти його звідти не прибереш: cron виконуватиме команду в заданий час щодня, незалежно від того, чи памʼятаєш ти про неї і чи є хтось на сервері.

5. Restart=always: чому процес піднімається сам

На занятті 02 ти зробив зі свого коду службу, і відтоді вона працює. Сьогодні розберемо, що саме тримає її запущеною.

systemd

Програма, яка запускається на сервері першою і відповідає за всі інші: стартує їх у потрібному порядку, стежить за їхнім станом і перезапускає, коли вони зупиняються. Твоя club-api — одна з таких служб.

unit-файл

Текстовий файл, у якому описано службу: яку команду запускати, з якої теки, що робити після зупинки. Твій лежить за шляхом ~/.config/systemd/user/club-api.service. Слово «unit» тут — просто назва такого опису.

Restart=always

Рядок в unit-файлі, який означає: щойно процес завершився, з будь-якої причини — запусти його знову. Цей рядок стоїть у твоєму файлі із заняття 02, сьогодні ми його не додаємо, а перевіряємо, що він на місці, і дивимося, як він працює.

RestartSec=3

Скільки секунд зачекати перед повторним запуском. Без паузи systemd намагався б перезапустити процес сотні разів на секунду.

Щоб побачити це в дії, процес треба зупинити. Для цього процесу надсилають сигнал.

Сигнал

Коротке повідомлення від системи до процесу. Найчастіші два. SIGTERM — прохання завершитися: програма отримує його, встигає закрити файли й вийти акуратно. SIGKILL — розпорядження зупинити процес негайно; його виконує саме ядро системи, і програма не може ні перехопити його, ні відкласти, ні щось доробити наостанок.

kill -9

Команда, яка надсилає процесові сигнал SIGKILL (він має номер 9). Після неї процес зникає миттєво. Це найгрубіший спосіб зупинки — і саме тому він годиться для перевірки: якщо служба піднімається після kill -9, вона підніметься й після мʼякших випадків.

Важлива межа, яку варто розуміти зараз. Restart=always повертає процес, коли той зупинився з причини, зовнішньої щодо коду: сигнал, перевищення памʼяті, перезавантаження сервера. Але якщо процес падає одразу після старту через помилку в самому коді, перезапуск не допоможе: він запуститься і впаде знову, і так по колу. Тому в systemd є обмеження на кількість спроб — типово пʼять спроб за десять секунд. Після них служба переходить у стан failed і сама більше не стартує. Це зроблено навмисно, щоб зламаний код не запускався нескінченно.

Стан failed знімається командою systemctl --user reset-failed club-api, але спершу треба виправити код, інакше все повториться. Скільки разів служба вже перезапускалася, показує окрема команда — вона буде на практиці.

6. RUNBOOK: інструкція, якою користуються під тиском

RUNBOOK

Файл із покроковими діями на випадок, коли сервіс не відповідає: які команди виконати, у якому порядку, що має бути у відповіді й що робити, якщо відповідь інша. Слово прийшло з практики адміністраторів і означає приблизно «інструкція для чергового».

Код відповіді

Тризначне число, яким сервер відповідає на кожен запит, ще до самої сторінки. 200 означає «запит оброблено, ось відповідь», 404 — «такої адреси немає», 500 — «на сервері сталася помилка під час обробки». Далі на сторінці ми питатимемо саме це число командою curl, і 200 буде ознакою, що сервіс відповідає.

Питання, яке тут доречне: навіщо записувати те, що й так знаєш. Відповідь у тому, коли цим доведеться скористатися. Сервіс зупиняється тоді, коли зупиняється, — увечері, у вихідний, за день до показу. Розбиратися доводиться швидко й часто з телефона, а згадувати в такий момент точний синтаксис команди довго, і помилитися легко.

Тому RUNBOOK пишуть за трьома правилами.

• Команди, а не описи. Рядок «подивитися стан служби» доводиться перекладати на команду. Рядок systemctl --user status club-api --no-pager копіюється й виконується.
• Повні шляхи й свої числа. У тексті мають стояти твій логін, твій порт, твої теки. Інструкція з чужим логіном не спрацює, а перевіряти це буде ніколи.
• Очікуваний результат біля кожного кроку. «Має бути active (running)», «має бути 200». Без цього незрозуміло, чи крок допоміг, чи треба йти далі.

Пояснень «як усе влаштовано» в RUNBOOK не пишуть: для цього є README. Тут потрібні тільки дії — команда, очікувана відповідь і що робити, коли відповідь інша.

Практика

Далі — тринадцять кроків. Скрипти пишемо на Python: він уже встановлений на сервері за шляхом /opt/club/venv — це окрема тека з Python і потрібними бібліотеками, спільна для всіх учнів. Ставити нічого не треба, достатньо звертатися саме до цього шляху. Усі команди виконуються на сервері, тому спершу заходимо туди.

ssh bohdan.g9@91.219.61.4

mkdir -p ~/logs ~/backups
df -h /home
ls -lh ~/data/
ls -lh ~/backups/
du -sh ~/app ~/data ~/logs ~/backups

nano ~/app/backup.py

#!/opt/club/venv/bin/python
"""Копія бази з ротацією. Заняття 11."""
import sqlite3
import sys
import time
from pathlib import Path

import yaml

APP = Path.home() / "app"
CFG = yaml.safe_load((APP / "project.yaml").read_text(encoding="utf-8"))

DB = Path.home() / "data" / CFG["database"]["file"]
DIR = Path.home() / "backups"
KEEP = 7

if not DB.is_file():
    sys.exit(f"немає файлу бази {DB}: копію не роблю")

DIR.mkdir(exist_ok=True)

stamp = time.strftime("%Y-%m-%d_%H%M%S")
out = DIR / f"app-{stamp}.db"

src = sqlite3.connect(DB)
dst = sqlite3.connect(out)
with dst:
    src.backup(dst)
dst.close()
src.close()

copies = sorted(DIR.glob("app-*.db"), reverse=True)
for old in copies[KEEP:]:
    old.unlink()

print(f"{time.strftime('%Y-%m-%d %H:%M:%S')}  {out.name}  "
      f"{out.stat().st_size} байт  копій у теці: {len(copies[:KEEP])}")

chmod +x ~/app/backup.py
~/app/backup.py

2026-09-06 12:04:31  app-2026-09-06_120431.db  45056 байт  копій у теці: 1

ls -lh ~/backups/

for i in $(seq 1 9); do ~/app/backup.py; sleep 1; done
ls -1 ~/backups/app-*.db | wc -l

ls -1t ~/backups/

nano ~/app/check-backup.py

#!/opt/club/venv/bin/python
"""Перевірка, що остання копія читається й повна. Заняття 11."""
import shutil
import sqlite3
import sys
import tempfile
from pathlib import Path

import yaml

APP = Path.home() / "app"
CFG = yaml.safe_load((APP / "project.yaml").read_text(encoding="utf-8"))

DB = Path.home() / "data" / CFG["database"]["file"]
TABLE = CFG["database"]["main_table"]

if not TABLE:
    sys.exit("у project.yaml порожнє поле database.main_table — заповни його")

copies = sorted((Path.home() / "backups").glob("app-*.db"), reverse=True)
if not copies:
    sys.exit("копій немає: скрипт backup.py жодного разу не відпрацював")

last = copies[0]

tmpdir = Path(tempfile.mkdtemp())
tmp = tmpdir / last.name
shutil.copy(last, tmp)

conn = sqlite3.connect(tmp)
status = conn.execute("PRAGMA integrity_check").fetchone()[0]
rows_copy = conn.execute(f"SELECT COUNT(*) FROM {TABLE}").fetchone()[0]
conn.close()
shutil.rmtree(tmpdir)

live = sqlite3.connect(DB)
rows_live = live.execute(f"SELECT COUNT(*) FROM {TABLE}").fetchone()[0]
live.close()

print(f"копія:            {last.name}")
print(f"integrity_check:  {status}")
print(f"рядків у копії:   {rows_copy}")
print(f"рядків у базі:    {rows_live}")

if status == "ok" and rows_copy == rows_live:
    print("ПІДСУМОК: копія ціла й повна")
else:
    print("ПІДСУМОК: розбіжність, дивись рядки вище")
    sys.exit(1)

chmod +x ~/app/check-backup.py
~/app/check-backup.py

копія:            app-2026-09-06_120438.db
integrity_check:  ok
рядків у копії:   34
рядків у базі:    34
ПІДСУМОК: копія ціла й повна

( crontab -l 2>/dev/null; echo "17 3 * * * /home/bohdan.g9/app/backup.py >> /home/bohdan.g9/logs/backup.log 2>&1" ) | crontab -

crontab -l

date +'%H:%M'

export EDITOR=nano
crontab -e

47 12 * * * /home/bohdan.g9/app/backup.py >> /home/bohdan.g9/logs/backup.log 2>&1

cat ~/logs/backup.log
ls -1t ~/backups/ | head -3

nano ~/app/health.sh

#!/usr/bin/env bash
# Погодинна перевірка, що сервіс відповідає. Заняття 11.

UNIT="$HOME/.config/systemd/user/club-api.service"
PORT=$(grep -oP '(?<=--port[ =])\d+' "$UNIT")
LOG="$HOME/logs/health.log"

mkdir -p "$HOME/logs"

if [ -z "$PORT" ]; then
  echo "$(date '+%Y-%m-%d %H:%M:%S')  порт не знайдено в $UNIT" >> "$LOG"
  exit 1
fi

CODE=$(curl -s -m 5 -o /dev/null -w '%{http_code}' "http://127.0.0.1:$PORT/api/ping")
STATE=$(systemctl --user is-active club-api)

echo "$(date '+%Y-%m-%d %H:%M:%S')  ping=$CODE  служба=$STATE" >> "$LOG"

chmod +x ~/app/health.sh
~/app/health.sh
cat ~/logs/health.log

( crontab -l 2>/dev/null; echo "0 * * * * /home/bohdan.g9/app/health.sh" ) | crontab -
crontab -l

grep 'Restart' ~/.config/systemd/user/club-api.service

Restart=always
RestartSec=3

systemctl --user show club-api -p Restart -p RestartUSec -p NRestarts

Restart=always
RestartUSec=3s
NRestarts=0

systemctl --user show club-api -p MainPID --value

kill -9 $(systemctl --user show club-api -p MainPID --value)
systemctl --user is-active club-api

sleep 5
systemctl --user show club-api -p MainPID -p NRestarts
systemctl --user is-active club-api

PORT=$(grep -oP '(?<=--port[ =])\d+' ~/.config/systemd/user/club-api.service)
echo "порт: $PORT"
curl -s -o /dev/null -w '%{http_code}\n' "http://127.0.0.1:$PORT/api/ping"

df -h /home | tail -1

dd if=/dev/zero of=~/logs/velykyi.tmp bs=1M count=100
df -h /home | tail -1

du -sh ~/app ~/data ~/logs ~/backups
du -sh ~/logs/* | sort -h | tail -5

rm -f ~/logs/velykyi.tmp
ls -1t ~/backups/app-*.db | tail -n +8 | xargs -r rm --
df -h /home | tail -1

nano ~/app/RUNBOOK.md

# RUNBOOK

Що робити, коли сервіс не відповідає.
Логін: bohdan.g9 · порт: 8014 · база: ~/data/app.db · копії: ~/backups/

## 1. Зрозуміти, що саме зламалося

    ssh bohdan.g9@91.219.61.4
    systemctl --user is-active club-api
    curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8014/api/ping
    df -h /home | tail -1

Має бути: active, 200, вільного місця більше за 200M.
Далі йди до того розділу, який відповідає побаченому.

## 2. Служба не active

    journalctl --user -u club-api -n 30 --no-pager

- SyntaxError або ImportError у main.py — код зламаний.
  Повернути версію main.py, збережену в git останнім комітом
  (усі незбережені зміни при цьому зникнуть):
      cd ~/app && git checkout -- main.py
      systemctl --user restart club-api
- Стан failed після виправлення коду:
      systemctl --user reset-failed club-api
      systemctl --user start club-api

## 3. Немає місця на диску

    df -h /home | tail -1
    du -sh ~/app ~/data ~/logs ~/backups
    du -sh ~/logs/* | sort -h | tail -5
    ls -1t ~/backups/app-*.db | tail -n +8 | xargs -r rm --
    : > ~/logs/health.log

Після цього перезапустити службу й перевірити ping.

## 4. База зникла або порожня

    ls -1t ~/backups/app-*.db | head -3
    systemctl --user stop club-api
    rm -f ~/data/app.db-wal ~/data/app.db-shm
    cp ~/backups/ІМʼЯ_КОПІЇ.db ~/data/app.db
    systemctl --user start club-api
    ~/app/check-backup.py

Далі відкрити сайт і переконатися, що список записів на місці.

## 5. Нічого з переліченого не допомогло

Написати викладачеві: логін, час, останні 20 рядків журналу
(journalctl --user -u club-api -n 20 --no-pager).

~/app/backup.py
~/app/check-backup.py

systemctl --user stop club-api
mv ~/data/app.db ~/data/app.db.vidkladena
rm -f ~/data/app.db-wal ~/data/app.db-shm
systemctl --user start club-api
PORT=$(grep -oP '(?<=--port[ =])\d+' ~/.config/systemd/user/club-api.service)
curl -s -o /dev/null -w '%{http_code}\n' "http://127.0.0.1:$PORT/api/ping"

ls -1t ~/backups/app-*.db | head -3

systemctl --user stop club-api
rm -f ~/data/app.db-wal ~/data/app.db-shm
cp ~/backups/app-2026-09-06_120438.db ~/data/app.db
systemctl --user start club-api
~/app/check-backup.py

rm ~/data/app.db.vidkladena

cd ~/app
git add backup.py check-backup.py health.sh RUNBOOK.md
git commit -m "щоденна копія бази, перевірка відновлення і RUNBOOK"
git push origin master

Що перевіряє автоматика

Чотири критерії заняття 11. Три перших перевіряє програма, четвертий зараховує викладач. Перевірка запускається за розкладом, тому відмітка в кабінеті зʼявляється не в ту саму секунду, коли ти виконав команду.

Домашнє завдання

cd ~/app
git log --reverse --pretty=format:'%ad  %s' --date=short

nano ~/app/CHANGELOG.md

# Що змінювалося

## 2026-06-28
- перша сторінка на сервері й опис проєкту в BRIEF.md

## 2026-07-05
- сервіс відповідає на /api/ping, служба піднімається сама після перезавантаження

## 2026-07-12
- історія в git, окреме сховище для неї в ~/repo.git

...

git add DEMO.md CHANGELOG.md
git commit -m "план демо і перші записи CHANGELOG"
git push origin master

Якщо щось не працює

crontab: command not found або no crontab for bohdan.g9

Друге повідомлення не є помилкою: воно просто означає, що розкладу в тебе ще немає. Додай рядок командою з кроку 7, і повідомлення зникне.

Перше означає, що cron на сервері не встановлений. Тоді скористайся розкладом systemd — той самий механізм, що вже тримає твою службу. Потрібні два файли.

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/backup.service

[Unit]
Description=Щоденна копія бази

[Service]
Type=oneshot
ExecStart=/home/bohdan.g9/app/backup.py

nano ~/.config/systemd/user/backup.timer

[Unit]
Description=Запуск копії бази о 3:17

[Timer]
OnCalendar=*-*-* 03:17:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl --user daemon-reload
systemctl --user enable --now backup.timer
systemctl --user list-timers backup.timer

Type=oneshot означає «запустити команду, дочекатися завершення й не тримати службу запущеною». Persistent=true — якщо в потрібний час сервер був вимкнений, запустити команду одразу після ввімкнення. Остання команда покаже, коли таймер спрацює наступного разу.

Рядок у crontab є, а нових копій немає

Спочатку подивись лог — саме для цього ми додавали >> ~/logs/backup.log 2>&1:

cat ~/logs/backup.log
crontab -l

Далі за тим, що побачив.

• Файлу немає — спершу перевір, чи існує сама тека: ls -ld ~/logs. Якщо її немає, перенаправлення >> не спрацює, і лог не зʼявиться, хоч би скільки разів команда запускалася. Створи теку: mkdir -p ~/logs — і чекай наступного запуску.
• Тека є, а лог порожній — cron не запускав команду взагалі. Перевір шлях у рядку розкладу: він має бути повний, /home/bohdan.g9/app/backup.py. Записи ~/app/backup.py і просто backup.py тут не працюють.
• Permission denied — забув chmod +x ~/app/backup.py.
• bad interpreter: /opt/club/venv/bin/python^M — файл редагували у Windows і поклали по FTP: там кінець рядка позначається двома символами. Прибрати їх: sed -i 's/\r$//' ~/app/backup.py.
• У логу є Traceback — скрипт запустився й упав. Читай останній рядок: там назва помилки. Найчастіше це FileNotFoundError з іменем project.yaml, і причина в тому, що шлях у скрипті записаний відносно поточної теки, а cron стартує з домашньої. У нашому скрипті всі шляхи будуються від Path.home(), тому такого бути не повинно — звір свій файл із кроком 2.

KeyError: 'main_table' або no such table під час перевірки

Скрипт перевірки читає назву головної таблиці з project.yaml. Подивись, що там записано:

grep -A5 '^database:' ~/app/project.yaml

-A5 означає «показати пʼять рядків після знайденого». Поле main_table має містити назву твоєї таблиці із заняття 04, наприклад habits. Якщо там порожні лапки, скрипт зупиниться з підказкою; заповни поле.

Повідомлення no such table: habits означає інше: поле заповнене, але такої таблиці в базі немає. Подивись, які таблиці є насправді:

/opt/club/venv/bin/python -c "import sqlite3,pathlib; print([r[0] for r in sqlite3.connect(pathlib.Path.home()/'data'/'app.db').execute(\"SELECT name FROM sqlite_master WHERE type='table'\")])"

sqlite_master — службова таблиця, у якій SQLite тримає перелік усього, що є в базі. Виправ назву в project.yaml так, щоб вона збігалася посимвольно.

Після kill -9 служба не піднялася

Дивимось стан і журнал:

systemctl --user status club-api --no-pager
journalctl --user -u club-api -n 30 --no-pager

--no-pager друкує все одразу, без гортання. Три типові випадки.

• Стан failed, у журналі SyntaxError або ImportError — процес падає одразу після старту, і systemd припинив спроби. Виправ код або поверни версію, збережену в git останнім комітом: cd ~/app && git checkout -- main.py. Май на увазі два наслідки: усі незбережені зміни в main.py ця команда знищить без запитань, а якщо останній коміт уже містив помилку, файл повернеться таким самим зламаним — тоді дивись git log і бери давніший коміт. Потім systemctl --user reset-failed club-api і systemctl --user start club-api.
• У журналі start request repeated too quickly — те саме обмеження на кількість спроб. Порядок дій той самий: спершу причина падіння, потім reset-failed.
• kill: (18432) - Operation not permitted — ти надіслав сигнал чужому процесу. Номер треба брати командою systemctl --user show club-api -p MainPID --value, а не з переліку всіх процесів на сервері.

database disk image is malformed або No space left on device

Перше повідомлення означає, що файл копії пошкоджений. Найчастіша причина — копію робили командою cp у момент, коли в базу писали. Зроби копію правильним способом і перевір ще раз:

~/app/backup.py
~/app/check-backup.py

Якщо нова копія теж не проходить перевірку, пошкоджена сама робоча база: копія знімається з неї, тому повторювати backup.py немає сенсу — вийде такий самий пошкоджений файл. Тоді перебирай копії від найновішої до давніших, поки якась не дасть ok, і відновлюйся з неї за розділом 4 свого RUNBOOK.

Друге повідомлення означає, що місця на диску немає. Подивись, скільки лишилося і що займає найбільше:

df -h /home | tail -1
du -sh ~/app ~/data ~/logs ~/backups
du -sh ~/logs/* | sort -h | tail -5

sort -h впорядковує за розміром з урахуванням одиниць, tail -5 лишає пʼять найбільших. Далі прибирай за розміром: зайві копії, великі файли логів, усе, що ти сам колись поклав у домашню теку й забув.

ls -1t ~/backups/app-*.db | tail -n +8 | xargs -r rm --
: > ~/logs/health.log
df -h /home | tail -1

Другий рядок спорожнює лог, лишаючи сам файл. Двокрапка тут — команда, яка нічого не робить, а > перед іменем файлу затирає його вміст.

Прибирати треба саме те, що лежить у твоїй домашній теці: df -h /home рахує місце тільки на цьому розділі. Журнал systemd лежить в іншому місці — /var/log/journal, — тому команда journalctl --user --vacuum-size=20M вільного місця в /home не додасть, і прав на ці файли у звичайного користувача зазвичай немає. Якщо всі твої теки маленькі, а місця однаково немає, — його зайняв не ти, напиши викладачеві.

Після звільнення місця перезапусти службу і перевір, що запис у базу знову працює: додай запис через форму на своєму сайті.