1Перевіряємо бота на міцність

Досі ти перевіряв, що бот працює: відповідає на /start, записує людей у базу, пускає до списку лише тебе. Сьогодні перевіриш, що він не ламається, коли все йде не за планом: хтось надсилає повідомлення на п’ять тисяч літер, одні емодзі, стікер замість тексту чи порожнє оновлення, процес служби раптом убивають, а файл бази псується. Так роблять професійні розробники (ті, хто пише програми за гроші) перед тим, як показати програму людям, і називають це перевіркою на міцність.

До кінця заняття в бота з’явиться:

• щит robust.py над handle_update(): погане повідомлення не валить бота, а відповідь людині ніколи не довша за межу Telegram (4096 символів);
• журнал оновлень ~/logs/app.log — рядок із датою й часом на кожне повідомлення, яке отримав бот (без самого тексту);
• щоденний бекап бази — таймер сам робить копію о 03:30, а в ~/backups зберігаються 14 останніх;
• перевірене відновлення — копію розгорнуто в окрему теку ~/restore-test, і видно, що таблиці на місці;
• досвід бою Red Team проти Blue Team — ви з однокласником по черзі нападаєте й захищаєтесь, борючись за «прапорець» у базі; вам видно, що справді витримав твій бот;
• файл BUGS.md — щонайменше три знахідки: що ти зробив, що сталося, чому й як ти це закрив.

Показати можна буде: вивід stress.py — «добре» на всі погані повідомлення; рядки app.log, які з’являються наживо; копії в ~/backups і вивід restore.py; бота, що сам піднявся після kill -9; BUGS.md на GitHub.

Сьогодні ми захищаємося, а не нападаємоПеревіряєш лише свого бота. Бота однокласника — тільки з його дозволу, тільки повідомленнями в Telegram — і так, щоб нічого не зіпсувати. Заходити в чужий акаунт, відкривати чужі файли, підбирати паролі, засипати бота повідомленнями не можна навіть «для перевірки». Знайдене кажеш власникові, а не використовуєш. Чому так — у першому розділі теорії.

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

Ті самі дії з чужим сервісом без дозволу — уже не перевірка, а втручання: межу визначає не те, що ти робиш, а те, чи дозволив власник. Фахівців, які шукають слабкі місця за згодою власника, називають «білими хакерами», і компанії навіть платять їм за знахідки. Без згоди те саме — порушення. У законі це звучить як «несанкціоноване втручання в роботу комп’ютерних систем» (стаття 361 Кримінального кодексу України) і вважається злочином. Простими словами: заходити туди, куди тебе не пускали, не можна. А на нашому сервері діє ще й правило курсу: у чужий акаунт не заходять, чужих файлів не відкривають, паролів не підбирають.

Тому сьогоднішня перевірка однокласника має чотири умови:

1. Згода. Він сам сказав «так» і назвав нік свого бота.
2. Лише ззовні. Тільки повідомлення його боту в Telegram — ніякого SSH і ніяких файлів.
3. Нічого не зіпсувати. Кожен запит складаєш так, щоб він нічого не змінив, навіть якщо захисту немає. Замок на видаленні перевіряють командою /del 999999 до запису, якого не існує: працює замок — прийде відмова «лише для власника», не працює — «такого контакту немає», і все одно нічого не видалено. Це як смикнути ручку дверей, а не виламувати їх.
4. Знахідку — власникові. Особисто, а не в загальний чат: поки дірку не закрито, кожен, хто про неї знає, може нею скористатися. Таке правило називають відповідальним розкриттям.

Як користуватися ШІ-помічникомМожна попросити ШІ пояснити незнайомий рядок помилки або підказати, які ще погані дані спробувати на своєму сервісі. Не вставляй у чат .env, BOT_TOKEN і рядки з бази — там секрети й імена людей. Не запускай на спільному сервері команд, яких не розумієш. Виправлення пиши сам, а в BUGS.md пояснюй своїми словами: на занятті тебе попросять розповісти, що саме було не так.

Великі компанії, банки й армії перевіряють свою безпеку не лише списками правил, а навчальними боями. Беруть двох «суперників» усередині одного колективу:

Назви прийшли з військових навчань: «червоні» грають за супротивника, «сині» — за своїх. Коли бій скінчився, обидві команди сідають разом і розбирають, що сталося: де нападники пройшли, де захисники помітили, а де проґавили. Таке спільне розбирання інколи називають Purple Team («фіолетові» — суміш червоного й синього). Саме тут народжується користь: гра не заради перемоги, а заради того, щоб після неї захист був міцнішим.

Чому гра, а не справжній нападЗахист, який жодного разу не перевіряли нападом, — це лише надія. Справжній злочинець не скаже, що пройшов. А товариш по команді скаже й допоможе закрити дірку. Тому нападати дозволено лише в грі, за згодою господаря, з правилами й словом «стоп». Без цього те саме було б правопорушенням.

Правила нашого бою

• Прапорець. Blue Team ховає в базі свого бота секретний рядок виду FLAG{…} (допоможе скрипт arena.py). Red Team має прочитати його через Telegram. Хто прочитав, той «захопив прапорець».
• Чотири раунди: розвідка, атака, оборона, відновлення. Між раундами — одна хвилина на розмову.
• Очки. Рахує викладач на дошці: у Red Team — за прапорець і знайдені слабкі місця, у Blue Team — за напади, які вчасно помітили, закриті дірки й відновлення.
• Межі. Лише повідомлення боту в Telegram. Жодного SSH, жодних файлів, жодних циклів, жодних чужих паролів. Слово «стоп» від господаря зупиняє бій одразу.
• Після бою. Усе повертається як було: прапорець зникає з бази, а базу можна відновити зі страхової копії.

Бот — це програма, яка приймає дані від незнайомих людей. А люди (і програми, які за них пишуть) надсилають усяке: порожнє повідомлення, стікер замість тексту, /ask без питання, повідомлення на п’ять тисяч літер, одні емодзі, команду зі сміттям після неї, відредаговане повідомлення, натискання кнопки. Це звичайні ситуації, а не аварії. Головне правило дня: на будь-які погані дані надійний бот відповідає спокійно й лишається живим. Якщо одне дивне повідомлення зупиняє бота для всіх, автор не передбачив такого випадку, і функція впала посеред роботи.

Що буває в оновленні, окрім звичайного тексту (update — це те, що Telegram віддає боту):

Є дві межі, про які треба пам’ятати. Telegram приймає повідомлення до 4096 символів: довшу відповідь він відхилить, і людина не отримає нічого. А ще — що довший вхідний текст, то більше роботи для бази й ШІ, тож задовгі повідомлення розумно обрізати ще на вході.

Перша лінія захисту у твоєму боті вже є: цикл poll_forever() загортає обробку кожного повідомлення в try … except. Якщо логіка впаде, людина отримає «Ой, щось пішло не так», у журнал служби піде рядок помилка обробки, а бот відповідатиме іншим. Але цей захист стоїть на доставці, а не на самій обробці. Сьогодні ти додаси другий — безпосередньо навколо handle_update(), у готовому файлі robust.py. Це декоратор: рядок @robust.safe над функцією, який огортає її, як обкладинка книжку, і щоразу, коли викликають handle_update, спершу виконується обгортка:

@robust.safe
def handle_update(update):
    ...

Щит (від англ. robust — «міцний») — це обгортка навколо handle_update(). Він робить чотири речі: обрізає надто довгий текст, ловить будь-яку помилку всередині й повертає спокійну відповідь замість Traceback, не дає відповіді перевищити 4000 символів (запас до межі Telegram у 4096) і дописує рядок у журнал (розділ 4). На будь-яке повідомлення з текстом бот відповідає; на стікер чи фото може мовчати, але не падає.

Чому таке потрібно, коли є except у циклі? По-перше, перевірку на міцність можна провести без Telegram: stress.py викликає handle_update напряму, і така перевірка бачить помилку одразу, а не з лог-файлу. По-друге, журнал записується для кожного оновлення, в тому числі й для тих, що закінчилися помилкою. По-третє, захист, який стоїть у двох місцях, переживе помилку в одному з них.

На занятті 04 ти дізнався, що значення в SQL-запит передають окремо, через знак ?. Подивімося, від чого саме це захищає. Уяви, що функцію додавання контакту написано склеюванням рядків:

execute("INSERT INTO users(name, first_seen, last_seen) VALUES('" + name + "', …)")

Поки людина вводить Оля, усе гаразд. Але для імені Оля'); DROP TABLE users; -- база отримає суцільний текст і не відрізнить, де закінчилася команда автора й почалися дані: лапка з імені закриває рядок, а далі йде нова команда — видалити таблицю. Це і є SQL-ін’єкція: текст, введений у поле, стає частиною команди до бази й змінює її зміст.

У твоєму коді (contacts.py, заняття 05) значення йдуть окремо: VALUES(NULL, ?, '', ?, ?, ?, 0)", (name, note, t, t). Текст запиту й дані потрапляють до бази різними шляхами, тому дані ніколи не стають командою. Ім’я Оля' OR '1'='1 так і запишеться в таблицю, дослівно, разом із лапками, — на практиці ти це побачиш.

Одне місце в contacts.py складає SQL f-рядком — edit(): changed(f"UPDATE users SET {field} = ? WHERE id = ?", …). Воно безпечне: у {field} потрапляє лише name або note — бот перевіряє це за списком раніше, — а самі значення й тут ідуть через ?. Правило: у текст запиту можна вставляти лише те, що написав автор коду, а все, що прийшло ззовні, — тільки через ?.

Журнал (його ще називають логом) — рядки, які програма пише про свою роботу: що сталося й коли. Сьогодні твій бот почне записувати кожне оновлення у файл ~/logs/app.log одним рядком:

2026-11-04 14:03:11 chat=100200300 /start ok 2ms len=6
2026-11-04 14:03:40 chat=777000111 текст ok 1ms len=4821
2026-11-04 14:04:02 chat=100200300 message без-тексту ok 1ms len=0
2026-11-04 14:05:17 chat=100200300 /add ПОМИЛКА KeyError 3ms len=14

Дата й час, номер чату, що це було (команда, «текст» або вид оновлення), чи закінчилося добре, скільки мілісекунд бот думав і довжина тексту. Найцінніше тут — час. Запис «було помилку» без часу не каже, коли це почалося: бот міг працювати три дні, а зламатися після твоєї правки о 14:30. Знаючи час, ти порівнюєш його з git log і бачиш, яка зміна винна. А ще видно, хто й коли стукав у зачинені двері: десяток відмов поспіль о третій ночі — привід задуматися.

Чому в рядку немає тексту повідомлення? Бо те, що люди пишуть боту, — їхні персональні дані (розділ 1 заняття 07). Журнал читають, показують на екрані, копіюють у бекап, а секрет чи ім’я, що туди потрапили, повернути вже не можна. У журнал йде лише команда, довжина й номер чату. Щит робить це сам.

Журналів у тебе два, і вони про різне. ~/logs/app.log — рядки про кожне оновлення, яке дійшло до handle_update(). ~/logs/club-bot.log — журнал служби: усе, що друкує бот (print), — запуски служби, Telegram недоступний і, головне, Traceback кожної помилки. Тому, якщо о 14:05 ти шукаєш причину, дивись у app.log, що тоді приходило, а в club-bot.log — чому воно впало.

Чого немає в app.logОновлення, які не дійшли до handle_update(): бот вимкнений, Telegram недоступний, служба перезапускається. Тому «у журналі нічого немає» не завжди означає «нічого й не було».

Уся пам’ять бота — один файл ~/data/app.db: хто писав, скільки разів, примітки. Утратити його можна безліччю способів: DELETE без WHERE, випадковий rm, зіпсований диск, помилка в коді, що затерла стовпець. Бекап — копія даних, зроблена заздалегідь, щоб після такої біди повернути все як було.

Чому б не просто cp ~/data/app.db ~/backups/? Бот пише в базу будь-якої миті, а cp копіює файл шматками: якщо посеред копіювання прийде повідомлення, у копії опиниться половина старого стану й половина нового — файл, який може й не відкритися. Тому backup.py робить копію через src.backup(dst) — вбудований у SQLite механізм, що копіює базу цілісною, навіть коли в неї саме пишуть. Ім’я копії містить дату й час (app-20261104-0330.db), а все, що старше за 14 останніх копій, видаляється, — інакше тека росла б, доки не скінчиться місце на спільному диску.

Тепер головне правило: бекап, з якого жодного разу не відновлювались, — не бекап. Буває, що скрипт місяцями копіює не той файл чи щоночі тихо падає, а помічають це в день біди. Тому відновлення пробують заздалегідь — і спершу в окрему теку. restore.py розгортає копію в ~/restore-test/app.db і показує, які там таблиці й скільки в них записів, а справжньої бази не чіпає: якщо копія погана, ти нічого не втратиш.

Робити копію руками щодня ніхто не стане, тому її робитиме таймер systemd — той самий systemd, що тримає твою службу, тільки за розкладом. Таймер — пара файлів: club-backup.service каже, що запустити (backup.py), а club-backup.timer — коли: OnCalendar=*-*-* 03:30, тобто «щодня о 03:30». Persistent=true означає: якщо о 03:30 сервер був вимкнений, копію зроблять одразу після його запуску.

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

Три історії про те, чому копії роблять регулярно

Ці історії вигадані, але такі випадки справді трапляються — і в школярів, і в дорослих.

• Видалили не те. Тарас дописував команду DELETE FROM users і випадково натиснув Enter, не написавши умову WHERE. З таблиці зникли всі люди, що писали боту. Копія, зроблена вночі, — і через п’ять хвилин усе повернулося, втрачено лише записи за кілька годин. Без копії довелося б починати з нуля.
• Помилка в новій функції. Олена додала нову функцію, після якої бот почав записувати в базу сміття. Помітила лише через тиждень. Якби копія була одна, вона вже містила б сміття. Тому зберігають кілька останніх копій — у нас 14: можна вибрати ту, що була до поломки.
• Зник сервер. Власник невеликої фірми орендував комп’ютер у хмарі, і на ньому зламався диск — разом із усією роботою. Копія лежала на тому самому диску, тож пропала разом з ним. Копія поруч з оригіналом від поломки диска не врятує. Одну копію треба тримати в іншому місці — на GitHub, на флешці чи в тебе вдома.

Висновок простий: копія корисна, коли вона регулярна (щодня, а не «коли згадаю»), кількох поколінь (не лише остання) і перевірена (ти вже хоч раз відновився з неї).

Щойно в інтернеті з’являється новий сервер, до нього починають стукати автоматичні програми — не твій Telegram-бот, а чужі, які шукають слабкі місця. Їх ніхто не спрямовує на конкретний сервер: вони просто перебирають адреси підряд, і за хвилини знаходять і твій сервер. Далі така програма пробує зайти на нього через SSH, підставляючи пароль за паролем. Це називають підбором паролів (англійською — brute force, «груба сила»): без розуму, зате безперервно — день і ніч, без вихідних.

Ось справжні цифри з журналу нашого навчального сервера за тиждень з 18 по 25 жовтня 2026 року:

Тобто на кожен справжній вхід припадає майже три тисячі спроб підбору. Роботи не знають, хто ти: вони пробують і в школярів, і в банків. Для них важливо лише одне — чи є на сервері людина зі слабким паролем. Якщо пароль 12345, qwerty чи ім’я з датою — його підберуть швидко. Саме тому пароль має бути довгим і випадковим, а ще краще — взагалі не потрібним (див. далі про ключі).

Журнал вдалих і невдалих входів на сервері — файл /var/log/secure; його читає лише адміністратор. Викладач покаже тобі на екрані, як порахувати такі спроби командою grep -c "Failed password" /var/log/secure.

Як сервер захищається

• Довгі випадкові паролі — ми видали тобі саме такі, а не «ім’я123».
• Тимчасове блокування — програма fail2ban блокує адресу, яка забагато разів помилилась. (На нашому навчальному сервері вона зараз вимкнена, бо 30 учнів з однієї школи часто помиляються в паролі й самі себе заблокували б.)
• Вхід за ключем — підібрати такий вхід не можна. Про нього — у наступному розділі.

SSH-ключ — це пара файлів, які створюються разом. Приватний ключ лишається в тебе на комп’ютері й нікому не показується. Публічний ключ можна давати будь-кому: ти кладеш його на сервер. Коли заходиш, сервер каже «доведи, що в тебе є пара до цього публічного ключа», і комп’ютер це доводить — а сам приватний ключ мережею не передається.

Порівняння: вхід за SSH — це пара «замок і ключ від нього». Замок (його файл називають публічним ключем) ти вішаєш на двері сервера, а ключ від замка (приватний ключ) лишається лише в тебе. Замків можна скільки завгодно повісити, а ключ від них — один, і він у тебе. Підібрати його роботу неможливо: приватний ключ — це число, у якому сотні знаків, а не слово, яке можна вгадати.

Вигоди ключа порівняно з паролем:

• його не можна підібрати перебором, як слабкий пароль;
• не треба нічого вводити щоразу — вхід швидший;
• якщо ноутбук загубився, ключ можна просто прибрати з сервера, а пароль довелося б міняти скрізь.

Важливо: приватний ключ (id_ed25519, без .pub) — як пароль: нікому не надсилай, не клади на GitHub і не вставляй у ШІ. Публічний (id_ed25519.pub) можна показувати. На справжніх серверах пароль взагалі вимикають і лишають тільки ключі. На нашому навчальному сервері пароль залишено, бо ви всі заходите вперше й помилки в налаштуванні ключа не мають закрити вам доступ.

Сервер схожий на будинок із багатьма дверима. Кожні двері — це порт, номер від 1 до 65535, на якому програма чекає з’єднань, тобто «слухає». SSH чекає на порту 22, nginx (він віддає твій сайт) — на 80. Які двері відчинені, показує команда ss -ltn: l — лише ті, що слухають, t — протокол TCP, n — номери портів замість назв.

А твій бот? Він нічого не слухає. Він сам ходить до Telegram і питає: «Є нові повідомлення?» (це і є long polling з заняття 02). Тобто бот — клієнт, який звертається за потреби, а не сервер, що постійно чекає на стук. Через це у твого бота немає власного порту, а значить, і зайвих дверей для чужих: усе, що може прийти ззовні, проходить через Telegram, який сам перевіряє, хто написав. Для безпеки це добре: менше відчинених дверей — менше що охороняти. Для сервера теж добре: програма, що не тримає порт і не чекає запитів, майже не їсть пам’яті.

Фаєрвол — програма, що пропускає або відкидає з’єднання ще до будь-яких дверей. На нашому сервері це firewalld, і ззовні він пропускає лише потрібне: SSH (22), HTTP (80), HTTPS (443, знадобиться на занятті 10). Налаштовує фаєрвол лише викладач: одна помилка в правилах відрізала б від сервера весь клас.

Ще кілька запобіжників стоять тому, що сервер спільний і на ньому мало пам’яті (близько 1,7 ГБ на всіх):

• служба club-bot має межі: не більше 100 МБ пам’яті й чверть одного ядра. Навіть якщо твій код зациклиться чи роздме пам’ять, сервер працюватиме для інших, а systemd просто перезапустить службу;
• шлюз ШІ школи один на всіх: десять запитів за хвилину на весь сервер і обмежена кількість за добу. Двадцять /ask «для перевірки» з’їдять ліміт усього класу;
• nginx обмежує кількість запитів до твого сайту ~/www з однієї адреси.

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

Список критеріїв і що саме вони означають — у таблиці вище, «Що перевіряє автоматика». Тут — та сама перевірка, але прямо зараз, без очікування на найближчий прохід за розкладом.

1. Закрий усе, що знайшов у тебе однокласник. На кожну знахідку порядок однаковий: повтори його повідомлення й переконайся, що проблема відтворюється; знайди причину в журналі (tail -n 30 ~/logs/club-bot.log і tail -n 30 ~/logs/app.log) або в правах (ls -l, як у кроці 11); виправ саму причину, а не наслідок; перезапусти службу й повтори — тепер відповідь спокійна. Допиши в рядок у BUGS.md, як закрив, і попроси однокласника повторити свою перевірку.
2. Переконайся, що таймер працює без тебе. Завтра, після 03:30:

   systemctl --user list-timers club-backup.timer
   ls -l ~/backups
   cd ~/app && python3 restore.py

   У стовпці LAST має стояти сьогоднішня ніч, у ~/backups — копія з часом 0330 в імені, а restore.py має відновити саме її. Якщо нової копії немає, подивись tail -n 20 ~/logs/club-backup.log.
3. Прочитай свій журнал, як детектив.

   awk '{print $4}' ~/logs/app.log | sort | uniq -c | sort -rn | head
   grep -c "ПОМИЛКА" ~/logs/app.log
   awk '{print $3}' ~/logs/app.log | sort | uniq -c | sort -rn | head -n 3

   awk '{print $4}' друкує четверте поле кожного рядка — команду, а sort | uniq -c | sort -rn рахує, скільки разів трапилась кожна, найчастіші першими. grep -c "ПОМИЛКА" — скільки разів щит упіймав помилку. Третя команда друкує номери чатів (третє поле), з яких писали найчастіше. Запиши в чернетку: які команди найпопулярніші, чи були помилки і від кого найбільше повідомлень.
4. Підготуйся пояснити. Чому бекап роблять через src.backup(), а не cp; чому відновлюють спершу в ~/restore-test; чому в app.log немає тексту повідомлень; чому в бота немає порту; як перевірити замок у чужого бота, нічого не зіпсувавши. На початку заняття 09 викладач спитає щось одне з цього.
5. Збережи. git add -A, git commit -m "Заняття 08: закрито знахідки однокласника", git push origin main і git push github main.

38Вхід за ключем не працює: сервер знову питає пароль

Найчастіші причини, по черзі:

• у authorized_keys потрапив не весь рядок або він розірваний на два. Має бути один рядок, що починається з ssh-ed25519. Перевір: cat ~/.ssh/authorized_keys;
• неправильні права: ls -ld ~/.ssh ~/.ssh/authorized_keys має показати drwx------ і -rw-------. Виправ: chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys;
• скопійовано приватний ключ замість публічного (файл без .pub) — тоді рядок починається з -----BEGIN. Негайно видали цей рядок із сервера й створи нову пару ключів;
• вказано не той файл після -i — перевір шлях і що на Windows немає зайвих пробілів.

39Після правки bot.py служба не стартує або бот мовчить

systemctl --user status club-bot --no-pager
tail -n 30 ~/logs/club-bot.log
cd ~/app && /opt/club/venv/bin/python3 -c "import bot" && echo готово

Остання команда показує помилку, не чекаючи служби. Що означає останній рядок:

• ModuleNotFoundError: No module named 'robust' — robust.py не в ~/app: ls ~/app/robust.py, якщо файлу немає — крок 3;
• NameError: name 'robust' is not defined — пропущено import robust;
• IndentationError — відступи поплуталися. Над @robust.safe не має бути пробілів, а під ним — порожніх рядків;
• стан failed і start request repeated too quickly — systemd кілька разів поспіль не зміг підняти службу й перестав пробувати. Виправ код, потім systemctl --user reset-failed club-bot і systemctl --user restart club-bot.

40Погані повідомлення ще валять бота (L08.1)

Повідомлення називає випадок, наприклад BAD: «дуже довге повідомлення»: відповідь 5012 символів… чи «message — не словник» валить бота: AttributeError.

• відповідь … символів, а Telegram приймає до 4096 — немає щита: grep -n -B1 "def handle_update" ~/app/bot.py має показати @robust.safe; перевір ще, що вставлено import robust;
• валить бота: … — те саме: помилка вилетіла з handle_update, а щит її не зловив. Щит має стояти безпосередньо над def handle_update, а не над іншою функцією;
• у відповіді людині видно Traceback — у твоєму коді є except Exception as e: return str(e) або подібне. Повертай людині спокійний текст, а подробиці — у print() для журналу служби;
• handle_update має повертати текст або None — функція повертає словник чи число. Перетвори на рядок.

Перед повторною перевіркою запусти python3 stress.py: це ті самі випадки, і видно, який саме падає.

41У ~/logs/app.log порожньо або перевірка L08.2 не зараховує

python3 try_bot.py "/start"
tail -n 3 ~/logs/app.log
ls -ld ~/logs
grep -n "robust" ~/app/bot.py

• grep нічого не знайшов — щит не підключено, крок 3;
• рядок з’явився, а перевірка пише рядків з датою й часом менше, ніж оновлень — журнал пишеться не для кожного оновлення. Усі оновлення (стікер, редагування, довге) мають лишати рядок; з готовим robust.py це так, а власну версію звір з ним;
• у журналі видно текст повідомлення — ти дописав у рядок журналу сам текст. Лиши лише команду, довжину й номер чату;
• ls -ld ~/logs має показати drwxr-x--- з твоїм логіном. No such file or directory — створи теку (mkdir ~/logs) і перезапусти службу; служба має право писати лише в ~/app, ~/data, ~/logs, ~/backups і ~/www;
• оновлень, які не дійшли до бота, у файлі не буде ніколи (теорія, розділ 4) — це не поломка журналу.

42backup.py або таймер не працюють (L08.3)

cd ~/app && python3 backup.py
ls ~/.config/systemd/user/
systemctl --user is-enabled club-backup.timer
systemctl --user list-timers club-backup.timer
tail -n 20 ~/logs/club-backup.log

• No module named 'db' — ти не в ~/app; No module named 'yaml' — запусти /opt/club/venv/bin/python3 backup.py;
• у ~/.config/systemd/user/ немає club-backup.service і club-backup.timer — повтори копіювання з кроку 11, потім обов’язково systemctl --user daemon-reload. Без цього enable відповідає Unit file club-backup.timer does not exist;
• is-enabled каже disabled — таймер не ввімкнено: systemctl --user enable --now club-backup.timer;
• у журналі can't open file '/home/…/app/backup.py' — backup.py не скопійовано в ~/app (крок 10);
• L08.3 пише найсвіжішому бекапу … год — таймер не спрацьовував: подивись стовпець LAST у list-timers, а поки розбираєшся, зроби свіжу копію: systemctl --user start club-backup.service.

43restore.py: немає копії, файл не відкривається або бракує таблиць (L08.4)

• у ~/backups немає жодної копії — спершу python3 backup.py — так і зроби: спершу копія, потім відновлення;
• sqlite3.OperationalError: unable to open database file після python3 restore.py ~/backups/… — такого файлу немає. Подивись ls ~/backups і скопіюй ім’я точно (допомагає Tab: набери початок імені й натисни його — оболонка допише решту);
• L08.4 пише у відновленій копії бракує таблиць: … — найсвіжіша копія старша за таблицю, яка вже є у справжній базі. Зроби нову копію й відновися з неї: python3 backup.py, потім python3 restore.py;
• L08.4 пише у відновленій копії таблиця users порожня — скопійовано порожню базу. Порівняй sqlite3 ~/data/app.db "SELECT COUNT(*) FROM users" із тим, що друкує restore.py. Якщо у справжній базі люди є, перевір у project.yaml рядок file: app.db: саме звідти backup.py бере шлях до бази.

44Після kill -9 служба не піднялася (L08.6)

systemctl --user status club-bot --no-pager
grep -E "^Restart" ~/.config/systemd/user/club-bot.service

• activating — systemd ще відраховує свої три секунди або служба саме стартує: зачекай і повтори;
• failed — служба впала вже під час нового запуску: причина в журналі (tail -n 30 ~/logs/club-bot.log), найчастіше це помилка в коді, як у пункті про запуск вище. Виправ, потім systemctl --user reset-failed club-bot і systemctl --user start club-bot;
• inactive (dead) — службу зупинив розклад групи, це не поломка. Перевіряй під час заняття або ввечері;
• grep не знайшов Restart=always — це до викладача: файл служби налаштовує він.

45BUGS.md не зараховано (L08.5)

ls -l ~/app/BUGS.md
grep -c "^- " ~/app/BUGS.md
grep -n "^- " ~/app/BUGS.md | cut -c1-60

• No such file or directory — файл названо інакше (bugs.md, BUGS.txt) або він лежить не в ~/app. Знайди його (ls ~ ~/app | grep -i bugs) і перейменуй: mv ~/app/bugs.md ~/app/BUGS.md;
• число менше за 3 — знахідки починаються з *, •, — або дефіса без пробілу, чи одну знахідку розбито на кілька рядків. Кожна знахідка — один рядок, що починається з - ;
• рядки коротші за дванадцять символів (- 500) не рахуються — та й нікому не допоможуть. Пиши, що зробив, що сталося, чому й як закрив. Третя команда показує початок кожного зарахованого рядка.