Добрый вечер! Столкнулся со странной проблемой.В Linux на базе Debian установил сервер 1С (64 бит).
После установки .deb пакетов в каталоге /etc/init.d появился файлик srv1cv83. Выполняю регистрацию, проверяю статус сервиса:
Получаю ошибку:
Начал искать причину. Сервер вручную запускается нормально через команду ./ragent -daemon
Стал копать внутренности скрипта и выяснил вот что. Если заменить строку в скрипте сервиса srv1c83:
на
То сервис стартует тоже нормально. Однако есть 2 проблемы, продолжает в статусе сервиса присутствовать ошибка "service failed to start!". Т.е. функция isRagentRunning не находит запущенный агент в процессах в течении 5 секунд (и 10 тоже, я увеличивал таймер).
Я эту проверку тоже закомментировал, но осталась самая главная ошибка - сервис остается неуправляемым, не поддается команде Stop или Restart, т.к. есть проблемы с файлом в переменной $SRV1CV8_PIDFILE, видимо функция getRagentPid не может корректно определить PID процесса.
Кто сталкивался, как решать помимо ребута всей ОС?
После установки .deb пакетов в каталоге /etc/init.d появился файлик srv1cv83. Выполняю регистрацию, проверяю статус сервиса:
systemctl enable srv1cv83
systemctl status srv1cv83
Получаю ошибку:
● srv1cv83.service - LSB: Starts and stops the 1C:Enterprise daemons
Loaded: loaded (/etc/init.d/srv1cv83; generated; vendor preset: enabled)
Active: active (exited) since Fri 2020-07-31 21:37:31 MSK; 1min 51s ago
Docs: man:systemd-sysv-generator(8)
Process: 14500 ExecStop=/etc/init.d/srv1cv83 stop (code=exited, status=0/SUCCESS)
Process: 14528 ExecStart=/etc/init.d/srv1cv83 start (code=exited, status=0/SUCCESS)
июл 31 21:37:26 srv-1 systemd[1]: Stopped LSB: Starts and stops the 1C:Enterprise daemons.
июл 31 21:37:26 srv-1 systemd[1]: Starting LSB: Starts and stops the 1C:Enterprise daemons...
июл 31 21:37:26 srv-1 su[14554]: Successful su for usr1cv8 by root
июл 31 21:37:26 srv-1 su[14554]: + ??? root:usr1cv8
июл 31 21:37:26 srv-1 su[14554]: pam_unix(su:session): session opened for user usr1cv8 by (uid=0)
июл 31 21:37:31 srv-1 srv1cv83[14528]: Starting 1C:Enterprise 8.3 server: Error: service failed to start!
июл 31 21:37:31 srv-1 srv1cv83[14528]: FAILED
июл 31 21:37:31 srv-1 systemd[1]: Started LSB: Starts and stops the 1C:Enterprise daemons.
ПоказатьНачал искать причину. Сервер вручную запускается нормально через команду ./ragent -daemon
Стал копать внутренности скрипта и выяснил вот что. Если заменить строку в скрипте сервиса srv1c83:
su -s /bin/bash - "$SRV1CV8_USER" -c "KRB5_KTNAME=\"$SRV1CV8_KEYTAB\" $cmd2run"
на
$cmd2run
То сервис стартует тоже нормально. Однако есть 2 проблемы, продолжает в статусе сервиса присутствовать ошибка "service failed to start!". Т.е. функция isRagentRunning не находит запущенный агент в процессах в течении 5 секунд (и 10 тоже, я увеличивал таймер).
Я эту проверку тоже закомментировал, но осталась самая главная ошибка - сервис остается неуправляемым, не поддается команде Stop или Restart, т.к. есть проблемы с файлом в переменной $SRV1CV8_PIDFILE, видимо функция getRagentPid не может корректно определить PID процесса.
Кто сталкивался, как решать помимо ребута всей ОС?
По теме из базы знаний
- Собираем образ виртуальной машины с PostgreSQL и платформой 1С. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 2
- Запуск нескольких экземпляров сервера 1С на GNU/Linux посредством systemd
- Xubuntu 20.04 для бухгалтера 1С
- Запуск сервера хранилища конфигураций и сервера удаленного управления на Linux, посредством systemd
- Экосистема 1С:Предприятие: вчера, сегодня, завтра
Найденные решения
В общем выкрутился таким образом, в файле сервиса /etc/init.d/srv1cv83:
Заменил эту строку
На эту
Теперь демон запускается под пользователем usr1cv8 от root'a без пароля, команды сервиса start,stop,status работают.
Будет ли это работать НЕ под Debian не знаю. Файл сервиса прилагаю на всякий случай. Если будете использовать надо отредактировать версию платформы в ключе SRV1CV8_VERSION=, ну и флаг +x поставить файлу, чтобы был выполняемым.
Заменил эту строку
su -s /bin/bash - "$SRV1CV8_USER" -c "KRB5_KTNAME=\"$SRV1CV8_KEYTAB\" $cmd2run"
На эту
start-stop-daemon --start --chuid "$SRV1CV8_USER" --oknodo --pidfile "$SRV1CV8_PIDFILE" --start --exec /usr/bin/env KRB5_KTNAME=\"$SRV1CV8_KEYTAB\" "$SRV1CV8_BINDIR/ragent" -- "-daemon"
Теперь демон запускается под пользователем usr1cv8 от root'a без пароля, команды сервиса start,stop,status работают.
Будет ли это работать НЕ под Debian не знаю. Файл сервиса прилагаю на всякий случай. Если будете использовать надо отредактировать версию платформы в ключе SRV1CV8_VERSION=, ну и флаг +x поставить файлу, чтобы был выполняемым.
Прикрепленные файлы:
srv1cv83.zip
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
В общем выкрутился таким образом, в файле сервиса /etc/init.d/srv1cv83:
Заменил эту строку
На эту
Теперь демон запускается под пользователем usr1cv8 от root'a без пароля, команды сервиса start,stop,status работают.
Будет ли это работать НЕ под Debian не знаю. Файл сервиса прилагаю на всякий случай. Если будете использовать надо отредактировать версию платформы в ключе SRV1CV8_VERSION=, ну и флаг +x поставить файлу, чтобы был выполняемым.
Заменил эту строку
su -s /bin/bash - "$SRV1CV8_USER" -c "KRB5_KTNAME=\"$SRV1CV8_KEYTAB\" $cmd2run"
На эту
start-stop-daemon --start --chuid "$SRV1CV8_USER" --oknodo --pidfile "$SRV1CV8_PIDFILE" --start --exec /usr/bin/env KRB5_KTNAME=\"$SRV1CV8_KEYTAB\" "$SRV1CV8_BINDIR/ragent" -- "-daemon"
Теперь демон запускается под пользователем usr1cv8 от root'a без пароля, команды сервиса start,stop,status работают.
Будет ли это работать НЕ под Debian не знаю. Файл сервиса прилагаю на всякий случай. Если будете использовать надо отредактировать версию платформы в ключе SRV1CV8_VERSION=, ну и флаг +x поставить файлу, чтобы был выполняемым.
Прикрепленные файлы:
srv1cv83.zip
(2) Спасибо, Вы действительно правы, в случае если систему ставить с включённым "Использовать sudo с паролем", без данной опции, сервис автоматически стартует и управляется без данных изменений.
(15)Я поторопился с ответом.. удалось ещё поэкспериментировать, Виноват пакет libpam-systemd, который у меня ставиться с firewalld, осталось понять, правильное ли такое поведение и можно ли его настроить, чтобы он не ломал запуск служб, это может ведь касаться не только 1С.. конфиг у него /usr/share/pam-configs/systemd
(15)Я поторопился с ответом.. удалось ещё поэкспериментировать, Виноват пакет libpam-systemd, который у меня ставиться с firewalld, осталось понять, правильное ли такое поведение и можно ли его настроить, чтобы он не ломал запуск служб, это может ведь касаться не только 1С.. конфиг у него /usr/share/pam-configs/systemd
(2)Извините за офтоп )
Было интересно разобраться, на 3-ей чистой установке.. понял зависимость в Astra, не знаю как в оригинальном Debian, но такое происходит, после установки пакета libpam-systemd.
Который в свою очередь прописывает библиотеку pam_systemd.so в /usr/share/pam-configs/systemd
Лично я её закомментировал в файле, не знаю на сколько это плохо, но данный пакет у меня подтянулся при установке firewalld, для чего ему аутенфикация, мне не понятно, мне главное, чтобы 1С корректно отрабатывал..
Было интересно разобраться, на 3-ей чистой установке.. понял зависимость в Astra, не знаю как в оригинальном Debian, но такое происходит, после установки пакета libpam-systemd.
Который в свою очередь прописывает библиотеку pam_systemd.so в /usr/share/pam-configs/systemd
Лично я её закомментировал в файле, не знаю на сколько это плохо, но данный пакет у меня подтянулся при установке firewalld, для чего ему аутенфикация, мне не понятно, мне главное, чтобы 1С корректно отрабатывал..
(2) Столкнувшись с такой же болью, применил Ваш метод - сработало, спасибо за сэкономленные часы.
Но, пользуясь наличием платной тех. поддержки Астры, написал письмо с данной проблемой и методом решения, и вопросом - насколько правильно так делать?
В ответ быдл предложено следующее решение:
После установки пакетов, необходимо в файле /etc/systemd/logind.conf изменить параметр KillExcludeUsers и добавить в список имен имя служебного пользователя usr1cv8. В итоге строка с параметром должна выглядеть примерно так:
KillExcludeUsers=root usr1cv8
либо в этом же конфигурационном файле изменить параметр KillUserProcesses= приведя его к виду:
KillUserProcesses=no
Вернул все в исходное состояние, поправил в соответствии с ответом, работает!
Но, пользуясь наличием платной тех. поддержки Астры, написал письмо с данной проблемой и методом решения, и вопросом - насколько правильно так делать?
В ответ быдл предложено следующее решение:
После установки пакетов, необходимо в файле /etc/systemd/logind.conf изменить параметр KillExcludeUsers и добавить в список имен имя служебного пользователя usr1cv8. В итоге строка с параметром должна выглядеть примерно так:
KillExcludeUsers=root usr1cv8
либо в этом же конфигурационном файле изменить параметр KillUserProcesses= приведя его к виду:
KillUserProcesses=no
Вернул все в исходное состояние, поправил в соответствии с ответом, работает!
(3) Плохо читаете первый пост. Есть абсолютно идентичная команда в переменной $cmd2run, которая выполняется в зависимости от прав root или usr1cv8 двумя различными способами:
- напрямую
- или через /bin/bash -c
Так вот первый вариант нормально срабатывает под root'ом. Я даже менял переменную скрипта SRV1CV8_USER=usr1cv8
прописывал туда root. Но через /bin/bash сервер не стартовал. Я даже пробовал прописывать так, добавляя команду sleep:
И знаете что происходило? Все 3 процесса 1С ragent,rmngr,rphost работали (!) ровно до того момента пока не истекал таймер в 500 секунд. Затем они прибивались системой, т.к. происходил выход из скрипта srv1cv83.
Судя по тому, что удалось найти в интернете - это нормальное поведение, когда shell прибивает все дочерние процессы, которые наплодил при завершении работы. А для 1С надо уже переходить из legacy системы сервисов на .service файлы, где есть ключи в скриптах как раз разрешающие подобные ситуации.
Кстати запускать агент через консоль вручную прописывая: su -s /bin/bash - usr1cv8 -c /opt/1c... и вводя пароль пользователя usr1cv8 я тоже пробовал, сервер стартует под ним без проблем и не жалуется на права.
- напрямую
- или через /bin/bash -c
Так вот первый вариант нормально срабатывает под root'ом. Я даже менял переменную скрипта SRV1CV8_USER=usr1cv8
прописывал туда root. Но через /bin/bash сервер не стартовал. Я даже пробовал прописывать так, добавляя команду sleep:
su -s /bin/bash - "$SRV1CV8_USER" -c "KRB5_KTNAME=\"$SRV1CV8_KEYTAB\" $cmd2run && sleep 500"
И знаете что происходило? Все 3 процесса 1С ragent,rmngr,rphost работали (!) ровно до того момента пока не истекал таймер в 500 секунд. Затем они прибивались системой, т.к. происходил выход из скрипта srv1cv83.
Судя по тому, что удалось найти в интернете - это нормальное поведение, когда shell прибивает все дочерние процессы, которые наплодил при завершении работы. А для 1С надо уже переходить из legacy системы сервисов на .service файлы, где есть ключи в скриптах как раз разрешающие подобные ситуации.
Кстати запускать агент через консоль вручную прописывая: su -s /bin/bash - usr1cv8 -c /opt/1c... и вводя пароль пользователя usr1cv8 я тоже пробовал, сервер стартует под ним без проблем и не жалуется на права.
(5) 1С из коробки "просто" работать не может даже на винде, о чем Вы говорите. Я за эти 6 лет такого навидался с платформой.
У меня один и тот же дистрибутив Linux, на одной виртуалке клиент 1С установился и вроде как работает, а на второй не завелась, хотя вроде бы делал все тоже самое.
У меня один и тот же дистрибутив Linux, на одной виртуалке клиент 1С установился и вроде как работает, а на второй не завелась, хотя вроде бы делал все тоже самое.
(6) Тогда я живу в параллельном мире, наверное.
Уже давно в Linux ставите дополнительные библиотеки и шрифты, ставите последовательно common - server - client - и все просто работает.
Иногда бывают проблемы с клиентом, но там все довольно просто и быстро решается запуском в консоли и изучением вывода.
Где можно накопать такой пласт проблем как у вас я просто теряюсь в догадках. Могу лишь предположить слабое знание Linux-систем, тогда да, даже простейшие вещи могут вызывать проблемы.
Уже давно в Linux ставите дополнительные библиотеки и шрифты, ставите последовательно common - server - client - и все просто работает.
Иногда бывают проблемы с клиентом, но там все довольно просто и быстро решается запуском в консоли и изучением вывода.
Где можно накопать такой пласт проблем как у вас я просто теряюсь в догадках. Могу лишь предположить слабое знание Linux-систем, тогда да, даже простейшие вещи могут вызывать проблемы.
Ну поставьте хотя бы себе последовательно на компьютер пользователя, который будет в дальнейшем работать на станции под Linux:
- common
- сервер (раз уж без него клиенты не работают)
- толстый клиент версии 32 бита, 64 бита, толстый клиент другой версии платформы 32 бита, 64 бита
- тонкий клиент обоих версий 32 и 64.
Всё это без проблем можно сделать на виндовой машине, только почему-то не в Linux...
- common
- сервер (раз уж без него клиенты не работают)
- толстый клиент версии 32 бита, 64 бита, толстый клиент другой версии платформы 32 бита, 64 бита
- тонкий клиент обоих версий 32 и 64.
Всё это без проблем можно сделать на виндовой машине, только почему-то не в Linux...
(8)Понятно. Начнем с того, что Linux - это не Windows и некоторые вещи в этих системах принципиально расходятся.
По вашим пунктам:
1. Ставим common и server
2. Ставим client - этот пакет содержит тонкий и толстый клиент, отдельно ставить пакет тонкого клиента не надо, да вы и не поставите, он конфликтует с client.
3. Для x32 включаем мультиархитектуру и повторяем все действия для x32 пакетов, только вот смысл этого действа мне непонятен, зачем?
4. Другую версию платформы вы так просто не поставите, но при некоторой доработке напильником можно, инструкций полно, в том числе и здесь.
Поэтому налицо непонимание работы Linux даже в базовых моментах и откровенно странные требования. Особенно в плане сочетания на одной Linux-машине x32 и x64 одновременно. Для чего вам это? Можете пояснить?
По вашим пунктам:
1. Ставим common и server
2. Ставим client - этот пакет содержит тонкий и толстый клиент, отдельно ставить пакет тонкого клиента не надо, да вы и не поставите, он конфликтует с client.
3. Для x32 включаем мультиархитектуру и повторяем все действия для x32 пакетов, только вот смысл этого действа мне непонятен, зачем?
4. Другую версию платформы вы так просто не поставите, но при некоторой доработке напильником можно, инструкций полно, в том числе и здесь.
Поэтому налицо непонимание работы Linux даже в базовых моментах и откровенно странные требования. Особенно в плане сочетания на одной Linux-машине x32 и x64 одновременно. Для чего вам это? Можете пояснить?
Ну вот видите, а говорите "из коробки". В Linux без крепкого словца и напильника ничего не сделать. Тонкий клиент конфликтует не с client, а с common пакетом от серверной части. Мультиархитектура давно включена, но некоторые зависимые пакеты не ставятся, т.к. просто отсутствуют в репозитории... А вообще ничего поставить нельзя без интернета. Зависимая Linux со всех мест от него. Приходится извращаться с apt offline. Много нюансов.
Одновременно нужно потому, что предприятие большое, количество серверов разных версий тоже. Есть и 8.2 с обычными приложениями. Есть конфигурации, где есть только 32 битные компоненты, на 64 битном клиенте они просто не работают (очередное спасибо компании 1С за это).
Инструкций действительно много. Они все разные, под разные варианты Linuxa, разные версии пакетов. И т.д. и т.п. Это "АД зависимостей" и условностей. Что работает на одном дистрибутиве, уже не работает на другом.
Одновременно нужно потому, что предприятие большое, количество серверов разных версий тоже. Есть и 8.2 с обычными приложениями. Есть конфигурации, где есть только 32 битные компоненты, на 64 битном клиенте они просто не работают (очередное спасибо компании 1С за это).
Инструкций действительно много. Они все разные, под разные варианты Linuxa, разные версии пакетов. И т.д. и т.п. Это "АД зависимостей" и условностей. Что работает на одном дистрибутиве, уже не работает на другом.
(10)
Базовые задачи решаются из коробки, "напильник" нужен для того, чтобы сделать то, что нельзя, но можно если очень хочется.
(10)
Пакет тонкого клиента вам не нужен, это совершенно отдельный пакет для узких случаев применения. Все что нужно для работы есть в client, все это описано в желтых книжках, которые вы не читали.
(10)
Это какие? Все зависимости есть в репозиториях, некоторые их них правда нужно включить (в Debian), но это уровень базовых знаний о системе.
(10)
А что, где-то это не так? В наши дни без интернета, как без рук. Хотя вы можете пойти скачать Deb-пакеты на флешку и поставить их руками.
(10)
Например? Типовые вполне кросплатформенны. Если речь идет об отраслевых и в частности о подключаемом оборудовании, то это отдельная история. Есть вполне обоснованное мнение, что эти компоненты не будут работать в Linux вообще. Но это не проблема Linux, и даже не проблема 1С, все вопросы конкретным разработчикам. Особый привет Рарусу.
(10)
Во всех случаях принцип один - установка в отдельную директорию и правка скриптов запуска.
(10)
Нет там давно никакого ада, если знать и понимать что вы делаете.
(10)
Да ладно, я еще соглашусь, что инструкция для DEB-систем не подходит к RPM-системам и наоборот. Но никакой принципиальной разницы между Debian, Ubuntu и каким нибудь Mint нет. Принципы работы системы везде одинаковы.
Ну вот видите, а говорите "из коробки". В Linux без крепкого словца и напильника ничего не сделать.
Базовые задачи решаются из коробки, "напильник" нужен для того, чтобы сделать то, что нельзя, но можно если очень хочется.
(10)
Тонкий клиент конфликтует не с client, а с common пакетом от серверной части.
Пакет тонкого клиента вам не нужен, это совершенно отдельный пакет для узких случаев применения. Все что нужно для работы есть в client, все это описано в желтых книжках, которые вы не читали.
(10)
Мультиархитектура давно включена, но некоторые зависимые пакеты не ставятся, т.к. просто отсутствуют в репозитории...
Это какие? Все зависимости есть в репозиториях, некоторые их них правда нужно включить (в Debian), но это уровень базовых знаний о системе.
(10)
А вообще ничего поставить нельзя без интернета.
А что, где-то это не так? В наши дни без интернета, как без рук. Хотя вы можете пойти скачать Deb-пакеты на флешку и поставить их руками.
(10)
Есть конфигурации, где есть только 32 битные компоненты, на 64 битном клиенте они просто не работают (очередное спасибо компании 1С за это).
Например? Типовые вполне кросплатформенны. Если речь идет об отраслевых и в частности о подключаемом оборудовании, то это отдельная история. Есть вполне обоснованное мнение, что эти компоненты не будут работать в Linux вообще. Но это не проблема Linux, и даже не проблема 1С, все вопросы конкретным разработчикам. Особый привет Рарусу.
(10)
Инструкций действительно много. Они все разные, под разные варианты Linuxa, разные версии пакетов
Во всех случаях принцип один - установка в отдельную директорию и правка скриптов запуска.
(10)
И т.д. и т.п. Это "АД зависимостей" и условностей.
Нет там давно никакого ада, если знать и понимать что вы делаете.
(10)
Что работает на одном дистрибутиве, уже не работает на другом.
Да ладно, я еще соглашусь, что инструкция для DEB-систем не подходит к RPM-системам и наоборот. Но никакой принципиальной разницы между Debian, Ubuntu и каким нибудь Mint нет. Принципы работы системы везде одинаковы.
В общем я подумал и пришел вот к какому решению. Я просто посижу и подожду, пока импортозамещение пройдет по стране и 1С сподобится сделать нормальные графические инсталлеры или сделает наконец свой собственный закрытый репозиторий пакетов. Потраченная неделя впустую в попытке поставить сервер на Astra Linux и хоть как-то завести её выбили меня из сил. Время - деньги.
(12)
Для Linux можете не ждать, их никогда не будет.
(12)
Astra - DEB-based, никаких проблем с ней нет, 1С ставится и работает прекрасно. Ваша проблема в том, что вы сами не понимаете, что делаете и для чего.
Единственная сложность в вашем случае - это несколько платформ на одном ПК. Хотя это вполне решаемо. Все остальное выглядит как натягивания совы на глобус без понимания кому и зачем это нужно, главное - сделать как в Windows.
Если есть реальные сложности - приводите конкретику. Будем разбираться.
Я просто посижу и подожду, пока импортозамещение пройдет по стране и 1С сподобится сделать нормальные графические инсталлеры
Для Linux можете не ждать, их никогда не будет.
(12)
Потраченная неделя впустую в попытке поставить сервер на Astra Linux и хоть как-то завести её выбили меня из сил. Время - деньги.
Astra - DEB-based, никаких проблем с ней нет, 1С ставится и работает прекрасно. Ваша проблема в том, что вы сами не понимаете, что делаете и для чего.
Единственная сложность в вашем случае - это несколько платформ на одном ПК. Хотя это вполне решаемо. Все остальное выглядит как натягивания совы на глобус без понимания кому и зачем это нужно, главное - сделать как в Windows.
Если есть реальные сложности - приводите конкретику. Будем разбираться.
(13)
Уже есть, в 8.3.20. И деинсталлятор тоже есть.
А в 8.3.21 обещают свой собственный unit file для systemd...
Я просто посижу и подожду, пока импортозамещение пройдет по стране и 1С сподобится сделать нормальные графические инсталлеры
Для Linux можете не ждать, их никогда не будет.
Для Linux можете не ждать, их никогда не будет.
Уже есть, в 8.3.20. И деинсталлятор тоже есть.
А в 8.3.21 обещают свой собственный unit file для systemd...
Точно такая же ситуация была когда по каким-либо причинам был удален (или изменен) файл кластера.
лежит тут по умолчанию - /home/usr1cv8/.1cv8/1C/1cv8/1cv8wsrv.lst
Перебрал всякое - в итоге. перемещаете файлы кластера куда-нибудь чтоб сохранить жр (если он нужен)\
оставляете папку /home/usr1cv8/.1cv8/1C/1cv8/ пустой.
Запускаете службу - пустой кластер стартанул.
Заново добавляете базы и у же дальше подкидываете жр если надо.
Вот так выглядит поломаный файл
Вот так здоровый
в целом не плохая идея делать копии файлов кластера. тогда можно будет и восстановить
лежит тут по умолчанию - /home/usr1cv8/.1cv8/1C/1cv8/1cv8wsrv.lst
Перебрал всякое - в итоге. перемещаете файлы кластера куда-нибудь чтоб сохранить жр (если он нужен)\
оставляете папку /home/usr1cv8/.1cv8/1C/1cv8/ пустой.
Запускаете службу - пустой кластер стартанул.
Заново добавляете базы и у же дальше подкидываете жр если надо.
Вот так выглядит поломаный файл
Скрытый текст |
---|
{
{0}, {0},0,1} |
Вот так здоровый
Скрытый текст |
---|
{
{1, {63d0182a-791e-4e93-a6fc-16ca2225232c,"Локальный кластер",1541,"srv-1c-01",0,0,0,60,0,0,0, {1, {"test-1c-deb-01",1541} },0,0,1,0} }, {0},0,1} |
в целом не плохая идея делать копии файлов кластера. тогда можно будет и восстановить
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот