[GH-ISSUE #313] Сбрасываются все настройки после перезагрузки NAS #249

Closed
opened 2026-10-13 19:52:44 +00:00 by bsakaguchi · 6 comments
Owner

Originally created by @DrMashine on GitHub (Nov 4, 2019).
Original GitHub issue: https://github.com/werwolfby/monitorrent/issues/313

Добрый день.

Долго мучал установку мониторрента на NAS от Synology (DS218). Нигде не нашел мануала по установке на версию не поддерживающую докер, и я в этом крайний дилетант, поэтому совершенно неудивительно, что что-то не завелось.

Сервер запустил. Настроил несколько раздач с ЛФ и решил разобраться с автозапуском (до этого вручную сервер запускал через ssh). Создал задачу на запуск server.py и сервер действительно заводится после рестарта NAS, но абсолютно в дефолтном состоянии.

Насколько я понимаю БД в моем случае не создается и настройки не запоминаются. Или при рестарте NAS БД, при запуске сервера БД создается каждый раз новая, перезаписывая старую.
При старте сервера через python3, получаю следующее:
/volume2/@appstore/py3k/usr/local/lib/python3.5/site-packages/alembic/util/messa ging.py:73: UserWarning: 'connection' argument to configure() is expected to be a sqlalchemy.engine.Connection instance, got <sqlalchemy.orm.session.ContextSess ion object at 0x7f93332d68> warnings.warn(msg) Server started on 0.0.0.0:6687

И с сервером в таком состоянии вполне можно работать. Раздачи на ЛФ находит и в трансмишн передает. Единственная проблема - не сохраняются настройки после рестарта.

Версия monitorrent последняя: 1.1.11.

Заранее спасибо.

Originally created by @DrMashine on GitHub (Nov 4, 2019). Original GitHub issue: https://github.com/werwolfby/monitorrent/issues/313 Добрый день. Долго мучал установку мониторрента на NAS от Synology (DS218). Нигде не нашел мануала по установке на версию не поддерживающую докер, и я в этом крайний дилетант, поэтому совершенно неудивительно, что что-то не завелось. Сервер запустил. Настроил несколько раздач с ЛФ и решил разобраться с автозапуском (до этого вручную сервер запускал через ssh). Создал задачу на запуск server.py и сервер действительно заводится после рестарта NAS, но абсолютно в дефолтном состоянии. Насколько я понимаю БД в моем случае не создается и настройки не запоминаются. Или при рестарте NAS БД, при запуске сервера БД создается каждый раз новая, перезаписывая старую. При старте сервера через python3, получаю следующее: ` /volume2/@appstore/py3k/usr/local/lib/python3.5/site-packages/alembic/util/messa ging.py:73: UserWarning: 'connection' argument to configure() is expected to be a sqlalchemy.engine.Connection instance, got <sqlalchemy.orm.session.ContextSess ion object at 0x7f93332d68> warnings.warn(msg) Server started on 0.0.0.0:6687 ` И с сервером в таком состоянии вполне можно работать. Раздачи на ЛФ находит и в трансмишн передает. Единственная проблема - не сохраняются настройки после рестарта. Версия monitorrent последняя: 1.1.11. Заранее спасибо.
Author
Owner

@degorychev commented on GitHub (Nov 4, 2019):

Полагаю что проблема кроется в правах на запись файла. Каким образом устроен автозапуск скрипта? От чьего имени? Когда запускаете вручную, все нормально работает?

<!-- gh-comment-id:549494581 --> @degorychev commented on GitHub (Nov 4, 2019): Полагаю что проблема кроется в правах на запись файла. Каким образом устроен автозапуск скрипта? От чьего имени? Когда запускаете вручную, все нормально работает?
Author
Owner

@DrMashine commented on GitHub (Nov 4, 2019):

Я совсем запутался. Записал видео, для полного понимания (в моем случае полного непонимания) того, что я делаю и что из этого выходит.

Буду благодарен тем, кто сможет потратить 3 минуты своей жизни на просмотр того, как я краблю. Постарался сократить и ускорить видео по возможности. Само видео.

Что происходит на видео:
Смотрим, что сервер не запущен. Заходим на NAS и запускаем вручную команду на старт сервера прям из Task Manager'a (триггер стоит на boot-up). Проверяем процессы, сервер запустился. Видим одну из настроенных инстанций с добавленной одной закачкой.
Перезагружаем сервер. При запуске сработает эта же команда на запуск этого же сервера.
Сервер перезапустился. Коннектимся через ssh. Проверяем процессы. Тот же сервер запущен. Проверяем сам сервер. Пароль дефолтный, настройки все тоже.
Убиваем процесс и запускаем его же снова. Опять дефолтные настройки.
Открываем MC, лезем в в ту же самую папку, в которой запускали сервер, запускаем его же, просто через команду python3. Обнаруживаем, что не убили прошлый, убиваем, запускаем еще раз.
И, вуаля, получаем уже 3 инстанцию, со всеми предыдущими настройками.
Убиваем и запускаем еще раз, но используя ту же самую команду из Task Manager'a, с которой все и начинали, которая же и стартует сервер при запуске. И опять получаем полностью настроенную версию.

В итоге я совсем ничего не понимаю. Есть 3 инстанции. С полными настройками, еще одна с одной записью и полностью дефолтные. Какой командой запускать - не важно. Одна и та же команда приводила к разным результатам. Т.е. все-таки БД есть.

<!-- gh-comment-id:549527672 --> @DrMashine commented on GitHub (Nov 4, 2019): Я совсем запутался. Записал видео, для полного понимания (в моем случае полного непонимания) того, что я делаю и что из этого выходит. Буду благодарен тем, кто сможет потратить 3 минуты своей жизни на просмотр того, как я краблю. Постарался сократить и ускорить видео по возможности. Само [видео](https://youtu.be/7L9y_U2dQ_Y). Что происходит на видео: Смотрим, что сервер не запущен. Заходим на NAS и запускаем вручную команду на старт сервера прям из Task Manager'a (триггер стоит на boot-up). Проверяем процессы, сервер запустился. Видим одну из настроенных инстанций с добавленной одной закачкой. Перезагружаем сервер. При запуске сработает эта же команда на запуск этого же сервера. Сервер перезапустился. Коннектимся через ssh. Проверяем процессы. Тот же сервер запущен. Проверяем сам сервер. Пароль дефолтный, настройки все тоже. Убиваем процесс и запускаем его же снова. Опять дефолтные настройки. Открываем MC, лезем в в ту же самую папку, в которой запускали сервер, запускаем его же, просто через команду python3. Обнаруживаем, что не убили прошлый, убиваем, запускаем еще раз. И, вуаля, получаем уже 3 инстанцию, со всеми предыдущими настройками. Убиваем и запускаем еще раз, но используя ту же самую команду из Task Manager'a, с которой все и начинали, которая же и стартует сервер при запуске. И опять получаем полностью настроенную версию. В итоге я совсем ничего не понимаю. Есть 3 инстанции. С полными настройками, еще одна с одной записью и полностью дефолтные. Какой командой запускать - не важно. Одна и та же команда приводила к разным результатам. Т.е. все-таки БД есть.
Author
Owner

@makar0nin commented on GitHub (Nov 5, 2019):

@DrMashine , для начала стоит внимательно ознакомится с wiki.
Проблема скорее всего кроется в месте расположения файла monitorrent.db , при ручном запуске вы выполняете скрипт в папке где рядом лежит сам файл базы. При автоматическом запуске сервер стартует от имени полоьзователя и соответственно ищет файл в его домашней папке.
В каком месте расположен файл базы данных на вашей машине ?

Ну и естетственно права посмотрите на запись/ чтение от текущего пользователя , как писали выше

<!-- gh-comment-id:549702659 --> @makar0nin commented on GitHub (Nov 5, 2019): @DrMashine , для начала стоит внимательно ознакомится с [wiki](https://github.com/werwolfby/monitorrent/wiki/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0-MoniTorrent-%D0%BD%D0%B0-%D0%9E%D0%A1-Ubuntu-16.04-LTS). Проблема скорее всего кроется в месте расположения файла monitorrent.db , при ручном запуске вы выполняете скрипт в папке где рядом лежит сам файл базы. При автоматическом запуске сервер стартует от имени полоьзователя и соответственно ищет файл в его домашней папке. В каком месте расположен файл базы данных на вашей машине ? Ну и естетственно права посмотрите на запись/ чтение от текущего пользователя , как писали выше
Author
Owner

@dzart1991 commented on GitHub (Nov 5, 2019):

@DrMashine В файле server.py в районе 100 строки есть конструкция вот такого вида

 class Config(object):
        debug = False
        ip = '0.0.0.0'
        port = 6687
        db_path = '/opt/monitorrent-1.1.10/monitorrent.db'
        config = 'config.py'

Что в Вашей db_path написано? Если просто 'monitorrent.db', то оно будет искать базу там, где запускается. Полагаю, для полного счастья в Вашем server.py должно быть

db_path = '/usr/local/monitorrent/monitorrent.db'

чтобы оно работало при запуске любыми средствами из любого места.

<!-- gh-comment-id:549941246 --> @dzart1991 commented on GitHub (Nov 5, 2019): @DrMashine В файле server.py в районе 100 строки есть конструкция вот такого вида ``` class Config(object): debug = False ip = '0.0.0.0' port = 6687 db_path = '/opt/monitorrent-1.1.10/monitorrent.db' config = 'config.py' ``` Что в Вашей db_path написано? Если просто 'monitorrent.db', то оно будет искать базу там, где запускается. Полагаю, для полного счастья в Вашем server.py должно быть ``` db_path = '/usr/local/monitorrent/monitorrent.db' ``` чтобы оно работало при запуске любыми средствами из любого места.
Author
Owner

@DrMashine commented on GitHub (Nov 5, 2019):

@dzart1991 Да, просто имя файла, без пути. В этом видимо и была проблема. Благодаря наводке от @makar0nin и этому куску из вики и начал копать в этом направлении:

Будьте внимательны, база данных создается в том каталоге из которого вы запускаете server.py Например: Если Вы находится в корневом каталоге и выполните python3.5 /opt/monitorrent/server.py & база данных создастся в корне. Чтобы избежать путаницы можно запускать start.sh ( /opt/monitorrent/start.sh ) и вне зависимости от Вашей директории БД будет находится в каталоге /opt/monitorrent/

Т.е. получается в моем случае было 3 базы. Я не совсем понял как одной и той же командой я умудрялся создать базы в разных местах. Видимо она создавалась именно в том месте, где я непосредственно находился, а не в том месте, где находился запускаемый скрипт.

Переустановил сервер в opt/monitorrent, создал файл с содержанием

cd /opt/monitorrent/
/usr/local/bin/python3 server.py &

и засунул команду на его запуск в Task Manager. После нескольких перезагрузок подгружается одна и та же база.

Остались проблемы конечно с проксями, подгрузкой чего-либо с трекеров, отличных от лоста, и уведомления по email не заводятся, но это уже оффтоп.

Всем огромное спасибо за помощь и благожелательный тон. Может кому-то мой опыт будет полезен.

<!-- gh-comment-id:549959971 --> @DrMashine commented on GitHub (Nov 5, 2019): @dzart1991 Да, просто имя файла, без пути. В этом видимо и была проблема. Благодаря наводке от @makar0nin и этому куску из вики и начал копать в этом направлении: > Будьте внимательны, база данных создается в том каталоге из которого вы запускаете server.py Например: Если Вы находится в корневом каталоге и выполните python3.5 /opt/monitorrent/server.py & база данных создастся в корне. Чтобы избежать путаницы можно запускать start.sh ( /opt/monitorrent/start.sh ) и вне зависимости от Вашей директории БД будет находится в каталоге /opt/monitorrent/ Т.е. получается в моем случае было 3 базы. Я не совсем понял как одной и той же командой я умудрялся создать базы в разных местах. Видимо она создавалась именно в том месте, где я непосредственно находился, а не в том месте, где находился запускаемый скрипт. Переустановил сервер в opt/monitorrent, создал файл с содержанием > cd /opt/monitorrent/ > /usr/local/bin/python3 server.py & и засунул команду на его запуск в Task Manager. После нескольких перезагрузок подгружается одна и та же база. Остались проблемы конечно с проксями, подгрузкой чего-либо с трекеров, отличных от лоста, и уведомления по email не заводятся, но это уже оффтоп. Всем огромное спасибо за помощь и благожелательный тон. Может кому-то мой опыт будет полезен.
Author
Owner

@werwolfby commented on GitHub (Nov 8, 2019):

Спасибо всем кто помог я не успевал

<!-- gh-comment-id:551356337 --> @werwolfby commented on GitHub (Nov 8, 2019): Спасибо всем кто помог я не успевал
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
werwolfby/monitorrent#249
No description provided.