Raspbery pi 4

[Alexander]

А эти логи для чего нужны? Если какая ошибка начинает вылезать, и надо её отловить? Если так, то логи можно собрать, переведя файловую систему опять read/write, или просто, скопировав из tmpfs. Это так?

Да

А бэкапы чего? Для чего они нужны? Я почти 3 года пользуюсь Д:К и только сейчас узнал про бэкапы...

БД = баз данных. ДЭНСИ:КАССА использует PostgreSQL для хранения данных. Справочники и "Настройки программы" хранятся в БД LinCash, журнал продаж (транзакции, которые потом выгружаются в файл с отчетом) - в БД Transaction. Вот эти базы и бэкапятся на случай, если с PostgreSQL, файловой системой или рабочими базами что-то случится.

Журнал продаж для выгрузки в report.txt хранится в БД Transaction.

А это где? Прошу извинить, но реально не понял.

См. предыдущий вопрос.

А что с папкой /etc/hwsrv? Её тоже отправить tmpfs, чтоб был доступ на запись, но всё сгорало по аналогии с /tmp, или там что-то важное, и надо на ssd её оставить?

В этой папке настройки сервера оборудования и информация, необходимая для активации. Можно попробовать сделать её readonly.

Такой же вопрос и про /etc/dancy. Там, как я понял *.conf файлы и два файла isload_up(un)load. Туда что-то касса писать вдолгую должна? Или эту папку можно readonly держать и лишь временно переводить в read/write когда менять настройки надо?

В этой папке есть файлы, в которых демоны обмена данными сохраняют служебную информацию. Ее делать readonly не желательно, думаю.

[a.m.samarin]

А бэкапы чего? Для чего они нужны? Я почти 3 года пользуюсь Д:К и только сейчас узнал про бэкапы...

БД = баз данных. ДЭНСИ:КАССА использует PostgreSQL для хранения данных. Справочники и "Настройки программы" хранятся в БД LinCash, журнал продаж (транзакции, которые потом выгружаются в файл с отчетом) - в БД Transaction. Вот эти базы и бэкапятся на случай, если с PostgreSQL, файловой системой или рабочими базами что-то случится.

Журнал продаж для выгрузки в report.txt хранится в БД Transaction.

А это где? Прошу извинить, но реально не понял.

См. предыдущий вопрос.

Вот опять не понял, где находятся эти базы данных. В какой папке и как конкретно называются? Для тех, кто на бронепоезде, можете ещё раз разжевать?

А что с папкой /etc/hwsrv? Её тоже отправить tmpfs, чтоб был доступ на запись, но всё сгорало по аналогии с /tmp, или там что-то важное, и надо на ssd её оставить?

В этой папке настройки сервера оборудования и информация, необходимая для активации. Можно попробовать сделать её readonly.

Такой же вопрос и про /etc/dancy. Там, как я понял *.conf файлы и два файла isload_up(un)load. Туда что-то касса писать вдолгую должна? Или эту папку можно readonly держать и лишь временно переводить в read/write когда менять настройки надо?

В этой папке есть файлы, в которых демоны обмена данными сохраняют служебную информацию. Ее делать readonly не желательно, думаю.

Про «ридонли» я понял, что не надо, а как с переносом этих папок в tmpfs? Там будет всё доступно для записи, а после перезагрузки, всё будет возвращаться к первоначальной версии файлов. А, в случае необходимости, можно отредактировать папку-эталон.
Заранее, спасибо.

[Alexander]

Вот опять не понял, где находятся эти базы данных. В какой папке и как конкретно называются? Для тех, кто на бронепоезде, можете ещё раз разжевать?

Прочитайте мануал по PostgreSQL, если это так интересно. СУБД хранит все данные в специальной служебной структуре файлов. Нет конкретного одного файла, содержащего всю базу данных.

Про «ридонли» я понял, что не надо, а как с переносом этих папок в tmpfs? Там будет всё доступно для записи, а после перезагрузки, всё будет возвращаться к первоначальной версии файлов. А, в случае необходимости, можно отредактировать папку-эталон.
Заранее, спасибо.

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

[a.m.samarin]

Добрый день.
1)Как добавить выполнение своего скрипта по отправке логов и копированию данных при нажатии кнопок: "выключить" или "перезагрузить"? Именно в программе, а не в openbox-е.

2)И как отследить, что вызывает во время запуска КАССЫ притормаживание "фоновых сервисов" до 30 сек? Точнее, я знаю, что это возникает при добавлении скрипта запуска вентилятора в rc.local. При том, что этот скрипт отнимает, судя по top-у, менее 0,5% у процессора и ещё меньше у памяти. И если запустить его не через rc.local, а через консоль, то всё хорошо. Потребление ресурсов при этом не изменяется. Кассу я запускаю во всех этих ситуациях через меню openbox-а. Хочу понять механизм возникновения проблемы и как это грамотно исправить.
Спасибо.

[Alexander]

1)Как добавить выполнение своего скрипта по отправке логов и копированию данных при нажатии кнопок: "выключить" или "перезагрузить"? Именно в программе, а не в openbox-е.

В меню ДЭНСИ:КАССы вызываются системные функции poweroff и reboot. Их бинарники находятся в /sbin/. Можно попробовать сделать в /usr/bin/ скрипты-двойники для этих функций, добавив в них перед вызовом этих же команд свои алгоритмы. Но это сработает, только если /usr/bin/ для обычного пользователя имеет приоритет перед /sbin/, в чём я не уверен.

2)И как отследить, что вызывает во время запуска КАССЫ притормаживание "фоновых сервисов" до 30 сек? Точнее, я знаю, что это возникает при добавлении скрипта запуска вентилятора в rc.local. При том, что этот скрипт отнимает, судя по top-у, менее 0,5% у процессора и ещё меньше у памяти. И если запустить его не через rc.local, а через консоль, то всё хорошо. Потребление ресурсов при этом не изменяется. Кассу я запускаю во всех этих ситуациях через меню openbox-а. Хочу понять механизм возникновения проблемы и как это грамотно исправить.

Все, что в /etc/rc.local расположено до запуска dnc_edsd будет увеличивать время данного окна на экране. Ставьте всё дополнительное после dnc_edsd (но до exit 0, естественно). Если не дожидаться запуска фоновых сервисов, можно столкнуться с тем, что БД недоступна ДЭНСИ:КАССе в момент запуска, т.к. openbox стартанул раньше, чем postgresql - современные дистрибутивы стремятся запустить графический сервер как можно быстрее.

[a.m.samarin]

В меню ДЭНСИ:КАССы вызываются системные функции poweroff и reboot. Их бинарники находятся в /sbin/. Можно попробовать сделать в /usr/bin/ скрипты-двойники для этих функций, добавив в них перед вызовом этих же команд свои алгоритмы. Но это сработает, только если /usr/bin/ для обычного пользователя имеет приоритет перед /sbin/, в чём я не уверен

А вызываются эти функции с какими-то аргументами?
Просто, у меня идея возникла заменить указанные бинарники симлинками на скрипты + переименованные/перемещённые бинарники. Например, poweroff переименовать в poweroff.orig, а poweroff сделать симлинком на скрипт, вызывающий в том числе и poweroff.orig. И если программа передаёт какие-то аргументы, надо будет их также захватить и передать для poweroff.orig.
Также можно попробовать скомпилировать из скрипта бинарник при помощи shc.
А может попробовать заменить бинарник на скрипт без расширения?
Надо знать содержание строки вызова функций poweroff и reboot из Кассы.
Спасибо.

[Alexander]

Без аргументов

[a.m.samarin]

Все, что в /etc/rc.local расположено до запуска dnc_edsd будет увеличивать время данного окна на экране. Ставьте всё дополнительное после dnc_edsd (но до exit 0, естественно). Если не дожидаться запуска фоновых сервисов, можно столкнуться с тем, что БД недоступна ДЭНСИ:КАССе в момент запуска, т.к. openbox стартанул раньше, чем postgresql - современные дистрибутивы стремятся запустить графический сервер как можно быстрее.

Молниеносный запуск восстановлен, спасибо.

Дополнение:
Надо было поставить в конце строчки запуска скрипта символ "&". В rc.local можно не писать "nohup" и "> /dev/null".

[a.m.samarin]

В меню ДЭНСИ:КАССы вызываются системные функции poweroff и reboot. Их бинарники находятся в /sbin/. Можно попробовать сделать в /usr/bin/ скрипты-двойники для этих функций, добавив в них перед вызовом этих же команд свои алгоритмы. Но это сработает, только если /usr/bin/ для обычного пользователя имеет приоритет перед /sbin/, в чём я не уверен.

Решено:
Преамбула (правда, я могу ошибаться): В директории "/sbin" находятся симлинки "@poweroff" и "@reboot" ведущие к файлу "/bin/systemctl". На эти симлинки, в свою очередь, ведут одноимённые симлинки из "/bin". Systemctl засекает название симлинка (хотя, линк - ссылка, и симЛИНК должнА быть тоже женского рода...) которым он был вызван и запускает ту или иную функцию.
Собственно, моё решение: в директории "/home/pi" созданы одноимённые симлинкам пакетники (poweroff.sh и reboot.sh, чтоб не путаться). Ближние к systemctl'у, в /sbin, симлинки перенаправлены на выше названные пакетники. В этих пакетниках, помимо нужного мне кода, содержатся строчки "/bin/systemctl poweroff" и "/bin/systemctl reboot" соответственно.
Всё! Откуда бы ни вызывались команды reboot/poweroff: из openbox'а, из Кассы или из консоли,- сначала выполняется нужный мне код, а потом уже reboot или poweroff.
Вот, как-то так.

[a.m.samarin]

Добрый день.
При запуске Д:К через терминал ($/usr/bin/dnc_kassa_start) увидел необычные сообщения:
«chmod: невозможно получить доступ к ‘/tmp/dancy/eftpos_log’$’\r’: нет такого файла или каталога» и «/usr/bin/dnc_kassa_start: строка 32: $’\r’: команда не найдена».
Просто в “dnc_kassa_start” даже 32 строки нет их там только 31, и переменной $’\r’ нет.
Это нормально? Или я что-то «сломал»?