Уточните где именно пожалуйста…Такого файла в последних прошивках не наблюдается к сожалению
up
Дайте пожалуйста инструкцию. У нас больше 200 контроллеров висят по этой причине. Вообще чтоб не логировало ничего.
В файле /etc/systemd/journald.conf
измените секцию “Storage” на:
Storage=none
И перезапустите:
systemctl restart systemd-journald
А что в логах то? Странно лечить перелом ампутацией.
Логируется mqtt конкретно. Мы купили у вас более 200 контроллеров Wirenboard 7. Встают регулярно по переполнению памяти. Что делать? Прошу у Вас инструкцию по полному выключению логирования. Планируем закупать еще большое количество для промышленной телемеханики нефтяных кустов. Дайте расклад по этому поводу, если это невозможно, то почему, и что нам делать с этой ситуацией. Заранее благодарю.
В /etc/mosquitto/conf.d/
замените
log_dest syslog
на
log_dest file /var/log/mosquitto/mosquitto.log
И перезагрузитесь.
Это вернет старое логирование mqtt. Но после обновления проблема может восстановится.
Причину этого изменения надо выяснять у коллег из WB.
Но логи могли бы и показать. Что у вас пишется в таком объеме в логи? У меня, например, кривой клиент гадит. Клиент написан не мной, так что исправить проблему не могу.
И да простят меня админы форума, но топик можно было бы и новый создать.
Хорошо бы сообщить нам подробности, почему вы решили, что память забивают логи? Логи чего забивают память? В стандартной поставке и при стандартных настройках такой проблемы точно нет.
Мы можем помочь устранить причину, а не пытаться что-то сделать сбоку, а потом в случае проблем вы останетесь без логов.
Ответьте, пожалуйста, на вопросы и пришлите вывод команды df -HT
на контроллерах, которые подвержены проблеме.
/mnt/data/var/log/messages файл растёт… по ходу линуксовый…
messages (510,0 КБ)
@It_Support Перенёс ваше сообщение в отдельную тему.
В нашем контроллере логами рулит jpurnald, которым можно управлять через journalctl. По умолчанию jpurnald настроен так, чтобы занимать максимум 10% от объёма доступной файловой системы. Эти и другие настройки можно посмотреть в документации, вам нужны параметры SystemMaxUse и RuntimeMaxUse.
То есть даже если в журнал кто-то очень много пишет, он будет просто быстрее затираться.
Поэтому, чтобы понять вашу проблему и помочь, опишите, пожалуйста, подробно по рекомендациям вашу ситуацию: Правила - Wiren Board Support и приложите диагностический архив с проблемного контроллера, создание архива описано по ссылке выше.
Теперь к файлу. Вижу в нём периодическую ругань сервиса wb-mqtt-gpio, который сообщает о проблемах конфигурации бокового модуля или модуля расширения:
Dec 12 15:37:42 wirenboard-AAUKH3J3 wb-mqtt-gpio[9642]: ERROR: [gpio] FATAL: duplicate GPIO offset in config: '0' at chip '/dev/gpiochip' defined as 'EXT2_R3A1'. It is already defined as 'EXT1_DR1'. To override set similar MQTT id (name). @ config.cpp:47
В остальных сообщениях я особых проблем не вижу, попрошу более опытных коллег глянуть с утра. @BrainRoot
В общем, начинать надо с диагностического архива, версий контроллера и описания контекста появления проблем, а также самой проблемы не в терминах «переполнилась память», а конкретно — как узнали, что переполнилась, на каком именно разделе переполнилась и т.п.
Мы поможем разобраться и устранить проблему, но сейчас очень мало информации.
Установил голый Home assistant, python docker и все зависимости к ним.
При этом использую ETH0 который просто смотрит в интернет. Хардвары ноль, правила тоже добавил на несколько минут и далил. Ругаться не на что…
mnt/var/log/messages растёт поминутно растёт
не помогло.
root@wirenboard-ANFMHVHI:~# du -h -d 1 -b /mnt/data/var/log
25174016 /mnt/data/var/log/journal
4652 /mnt/data/var/log/nginx
4096 /mnt/data/var/log/watchdog
14924 /mnt/data/var/log/mosquitto
86147 /mnt/data/var/log/apt
27817838 /mnt/data/var/log
root@wirenboard-ANFMHVHI:~# du -h -d 1 -b /mnt/data/var/log
25174016 /mnt/data/var/log/journal
4652 /mnt/data/var/log/nginx
4096 /mnt/data/var/log/watchdog
14924 /mnt/data/var/log/mosquitto
86147 /mnt/data/var/log/apt
27818373 /mnt/data/var/log
messages (2,3 МБ)
Так же на рабочик контроллерах растёт /mnt/data/var/log/journal в котором появляются дополнительные файлы
прошивка:
Welcome to Wiren Board 7.3.4 (s/n ANFMHVHI), release wb-2207 (as stable)
Linux wirenboard-ANFMHVHI 5.10.35-wb120+wb101 #2 SMP Tue Nov 22 12:49:35 UTC 2022 armv7l GNU/Linux
Еще высылаю архив /var вечерний
Утром дополню утренним что происходит…
И общая картина
root@wirenboard-ANFMHVHI:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 999320 616856 313652 67% /
devtmpfs 503312 0 503312 0% /dev
tmpfs 512016 0 512016 0% /dev/shm
tmpfs 512016 1844 510172 1% /run
tmpfs 5120 0 5120 0% /run/lock
tmpfs 512016 0 512016 0% /sys/fs/cgroup
/dev/mmcblk0p6 5109956 3204424 1626248 67% /mnt/data
overlay 5109956 3204424 1626248 67% /mnt/data/.docker/overlay2/9e79548570be20bc0f9795648f5054a49269b410f32cc9cffc640c6114992b05/merged
overlay 5109956 3204424 1626248 67% /mnt/data/.docker/overlay2/594a2b27dc1ae7719b277b00ada7b81182ac974aedf23502685e56dafec036b0/merged
tmpfs 102400 0 102400 0% /run/user/0
Очень срочно нужно решение! Заранее благодарю.
Каталог /mnt/data/var за ±10 часов увеличился.
Добрый день.
Как я вижу у вас стоит bullseye.
А зачем настроено логирование в messages?
То есть - по умолчанию этого файла в актуальных релизах нет. Чтобы он появился - нужно специально включить вывод логов в него. Предполагаю что зачем-то включили.
Считаете что 29 мегабайт - это очень много для логов? То есть текущий размер - большой?
Контроллер как и любой другой компьютер работает ровно так как он настроен. Покажите пожалуйста текущие настройки логирования, напишите что работет не в соответствии с настройками.
Ну и коллега выше попросил описать что именно вызывает подозрения и беспокойство, из вывода df - совершенно непонятно, к сожалению.
На 400 кБ, да.
А как настроен logrotate для него? Ну или что примянете для ротирования.
Ни в коем случае! я сам ничего не включал… У нас stretch
Простите конечно за выражение, но не просил Вас “умничать”, подскажите пожалуйста какую именно вам надо информацию для решения данной проблемы, мы крупные заказчики и хотели бы дальше с Вами работать, и прошу чтобы Вы пошли нам на встречу, опишите пожалуйста по инструкции что именно нужно от нас, мы всё предоставим, проблем нет, мы уже закупили у Вас их около 300 штук, и собираемся работать массово с ними, мы у Вас не один контроллер купили для “Умного Дома”, в планах на них строить диспетчеризацию и телемеханику. Пожалуйста отнеситесь серьёзно ,и пойдите нам на встречу а так же помогите решить проблему. Можно в личку. Заранее спасибо.
Вы их специально для нас с нашим лейблом выпускаете, ввиду крупного заказчика…
Поддержка stetch заявлена до апреля следущего года. А почему не обновляете?
А как (сейчас) настроено ротирование файла?
Я, к сожалению - еще не выяснил с какой проблемой планируете бороться.
Описание “Встают регулярно по переполнению памяти” - совершенно не добавляет понимания.
Пожалуйста подключите к переписке специалиста который занимается настройкой контроллеров, возможно так быстрее смогу понять.
Как описано
- Что вы делаете?
- Какое поведение ожидаете увидеть?
- Что происходит в действительности?
- Можно ли это воспроизвести? С какой вероятностью (примерно) это происходит?
Да, естественно. Поэтому ожидаю описания.
Спасибо за помощь, тольк добрался до объекта и проанализировал всё что с ними происходит. С VAR вроде разобрался. Растут логи докера, за 3 месяца работы папка докер выросла до 6 GB, хотя должна быть 2-3. Из всего что там есть, это home assistant, portainer,nodered. Не должно это 6гб весить.
root@wirenboard-AES4NEJS:~# du -h -d 1 /mnt/data/
625M /mnt/data/c_usr
4.0K /mnt/data/py
17M /mnt/data/.HA
376K /mnt/data/etrv2mqtt-master
4.0K /mnt/data/ftp
4.0K /mnt/data/.wb-restore
8.0K /mnt/data/uploads
6.0G /mnt/data/.docker
144M /mnt/data/var
648K /mnt/data/.HA1
36M /mnt/data/root
25M /mnt/data/venv
1.8M /mnt/data/etc
6.8G /mnt/data/
Самая большая папка в .docker называется overlay2.
После первой установки на WB всего ПО mnt/data быз занят на 68%…
Что с этим можно сделать?
root@wirenboard-AES4NEJS:~# du -h -d 1 /mnt/data/.docker
4.4G /mnt/data/.docker/overlay2
108K /mnt/data/.docker/volumes
72K /mnt/data/.docker/buildkit
4.0K /mnt/data/.docker/trust
64K /mnt/data/.docker/network
4.0K /mnt/data/.docker/tmp-old
4.0K /mnt/data/.docker/runtimes
9.7M /mnt/data/.docker/image
1.6G /mnt/data/.docker/containers
4.0K /mnt/data/.docker/swarm
20K /mnt/data/.docker/builder
4.0K /mnt/data/.docker/tmp
20K /mnt/data/.docker/plugins
6.0G /mnt/data/.docker
root@wirenboard-AES4NEJS:~# du -h -d 1 -b /mnt/data/.docker
4031836168 /mnt/data/.docker/overlay2
132623 /mnt/data/.docker/volumes
81920 /mnt/data/.docker/buildkit
4096 /mnt/data/.docker/trust
73728 /mnt/data/.docker/network
4096 /mnt/data/.docker/tmp-old
4096 /mnt/data/.docker/runtimes
8740991 /mnt/data/.docker/image
1710949402 /mnt/data/.docker/containers
4096 /mnt/data/.docker/swarm
20480 /mnt/data/.docker/builder
4096 /mnt/data/.docker/tmp
20480 /mnt/data/.docker/plugins
5751880368 /mnt/data/.docker
root@wirenboard-AES4NEJS:~# du -h -d 1 -b /mnt/data/.docker
4031836168 /mnt/data/.docker/overlay2
132623 /mnt/data/.docker/volumes
81920 /mnt/data/.docker/buildkit
4096 /mnt/data/.docker/trust
73728 /mnt/data/.docker/network
4096 /mnt/data/.docker/tmp-old
4096 /mnt/data/.docker/runtimes
8740991 /mnt/data/.docker/image
1710966184 /mnt/data/.docker/containers
4096 /mnt/data/.docker/swarm
20480 /mnt/data/.docker/builder
4096 /mnt/data/.docker/tmp
20480 /mnt/data/.docker/plugins
5751897150 /mnt/data/.docker
root@wirenboard-AES4NEJS:~# du -h -d 1 -b /mnt/data/.docker
4031836168 /mnt/data/.docker/overlay2
132623 /mnt/data/.docker/volumes
81920 /mnt/data/.docker/buildkit
4096 /mnt/data/.docker/trust
73728 /mnt/data/.docker/network
4096 /mnt/data/.docker/tmp-old
4096 /mnt/data/.docker/runtimes
8740991 /mnt/data/.docker/image
1711001175 /mnt/data/.docker/containers
4096 /mnt/data/.docker/swarm
20480 /mnt/data/.docker/builder
4096 /mnt/data/.docker/tmp
20480 /mnt/data/.docker/plugins
5751932141 /mnt/data/.docker
Вот такая динамика роста при повторении du -h -d 1 -b /mnt/data/.docker
Короче, росли логи Докер контейнеров… Придумал такое правило
defineVirtualDevice("clear", {
title: "clear_timer",
cells: {
enabled: {
type: "switch",
value: false
},
run: {
type: "switch",
value: false
}
}
});
defineRule("clean_time", {
asSoonAs: function () {
return dev["clear/enabled"];
},
then: function () {
startTicker("timer", 3600000 * 12);
}
});
defineRule("Clean", {
when: function () { return timers.timer.firing; },
then: function () {
if (dev["clear/enabled"] == true) {
runShellCommand('rm -R /mnt/data/var/log'); // удаляем полностью папку LOG
runShellCommand('mkdir /mnt/data/var/log/'); //создаём папку LOG пустую, пусть WB пишет туда чё хочет в пустую
runShellCommand('truncate -s 0 /mnt/data/.docker/containers/*/*-json.log'); // чистим кэш контейнеров Docker
dev["clear/run"] = !dev["clear/run"];
}
else {
timers.one_second.stop();
}
}
});
Чистит каждые 12 часов, как Вам решение? Если что то не так скажите пожалуйста…
Решение удалять логи контейцнеров может быть и рабочим, но все ж - это как по мне устранение симптомов. Не лучше ли настроить ведение логов в контейнерах?
{
“data-root”: “/mnt/data/.docker”,
“log-driver”: “json-file”,
“log-opts”: {
“max-file”: “2”,
“max-size”: “1m”
}
}
Кладём этот конфиг в /mnt/data/etc/docker/daemon.json пересоздаём контейнер и вуаля, логи не более 2 мегабайт)))))