Jump to content

gvan

Forum Members
  • Content Count

    196
  • Joined

  • Days Won

    2

gvan last won the day on April 3 2018

gvan had the most liked content!

Community Reputation

88 Excellent

2 Followers

About gvan

  • Rank
    Advanced Member

Equipment

  • Keenetic
    Giga II, Extra II

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. В рамках данного решения (скрипта) этого не предусмотрено. Посмотрите каталог готовых решений для opkg. Возможно, что-то найдете для копирования (переноса) данных на облачные сервисы. Например, упоминается rclone. Соответственно, если получится его настроить, то в конец скрипта добавите необходимые строки для синхронизации локального каталога с бэкапами на облако.
  2. Ну, у меня проблемы с установкой не было, поскольку стояла версия 2.16.D.7.0-1, а обновляться выше в свое время я не стал (когда увидел, что на Giga 2, у некоторых после 8 версии начались проблемы с кирпичами). Как вышла 10 обновился успешно, правда только со второго раза. Первый раз после обновления осталась та же самая версия. Повторная установка 10 прошла нормально. 10-01 с первого раза без проблем поставилась.
  3. Вот еще здесь посмотрите. Аналогичная проблема была у людей как с подключенным модемом, так и без него. У самого Giga 2. Но почитав всё это, решил, что мне хорошо и на 2.16.D.7.0-1. Решил пока не обновляться.
  4. Достаточно было почитать предыдущие сообщения. Комрады хотели (просили), чтобы предыдущие файлы прошивки не удалялись, а именовались по номеру прошивки и оставались на диске. Но по коду скрипта сама прошивка в архив вообще не кладется. Непонятно, почему у вас так происходит. Что касается конфига, то его последняя версия кладется в файл -cur. Если были изменения от текущего его содержимого (а у вас, наверное, конфиг изменялся), старая версия конфига как раз перемещается в архив с датой. Не исключаю, что где-то в скрипте есть баг и нарушена логика именования файлов. У меня например во
  5. Тоже несложно. Достаточно мануал на команду find посмотреть. Выглядететь будет примерно так: find $BACSTORDIR -mtime +${DAYSTOR} -a ! -name 'firmware*' -delete
  6. Это не сложно. Можно заменить блок кода в скрипте, где делается бэкап прошивки на код следующего вида: Ключевой элемент здесь - получение номера версии прошивки: REL=`ndmq -p 'show version' -P 'release'` У себя код поменял. Вроде работает. Отредактировать первое сообщение уже не могу. Так что меняйте, проверяйте и у себя.
  7. В версии 2.16.D.1.0-0 Load Average нормализовался. Спасибо!
  8. Нет, журнал изменений 2.13-2.15 читал регулярно. Упоминаний об исправлении не встречал. Проблема наблюдалась на всех версиях 2.13-2.16 (может, конечно, какие-то промежуточные версии и пропустил). Также подтверждается на версии 2.16 на двух других Keenetic Giga II (их использую не я).
  9. Я понимаю. На работу не влияет, но графики статистики LA безбожно врут 😉 Уж очень хорошая и надежная "железка" получилась в виде Keenetic Giga II, которая верой и правдой служит уже несколько лет. Поэтому и хотелось окончательного фэншуя, т.к. в версии 2.12 LA работал, как и задумано. Но нет, так нет. Если исправляющую "затычку" для данного типа устройств сделать сложно, то значит не судьба...
  10. Баг тянется еще с версии 2.13. Судя по сообщениям в предыдущей теме, характерен только Keenetic Giga II и Keenetic II (устройства на 6856). На 2.16.D.0.0-0 также присутствует. Если смотреть загрузку Load Average (через SNMP или команду top в entware), то она всегда будет больше 1. Хотя, если при этом смотреть загрузку CPU (через веб-интерфейс или SNMP), то она будет околонулевая. Соответственно, и LA также должен быть невысоким (меньше 1). Но это не так. Насколько я понял, это фактически последний шанс исправить данный баг в прошивке 2.16 для снятых с поддержки устройств...
  11. Ротация никакого отношения к обновлению логов не имеет. Ее задача правильно перенести/архивировать файлы журналов. На скрине выше вообще непонятно, что вы там настроили. Повторюсь. Если у вас перестали обновляться логи, что ротация здесь не причем (за исключением уж совсем клинических случаев). Сначала разберитесь с обновлением логов и добейтесь того, чтобы данные в них писались. Удалите пакет logrotate и скрипт /opt/etc/cron.daily/logrotate, перезапустите роутер, проверьте данные.
  12. Логи в entware лежат по пути /opt/var/log. Файл messages тоже находится там. Если он перестал обновляться, то настройка ротации логов вряд ли виновата. Для проверки можно сделать рестарт службы syslog-ng и посмотреть, станут ли в него добавляться новые данные. Если нет, то вопрос следует задать в соответствующей теме (ссылка есть в первом сообщении).
  13. Сам сервис запускается через watchguard скрипт collectdmon. Соответственно, предполагаю, что из-за ошибок в конфиге/окружении collectd нормально не стартует, а collectdmon пытается его несколько раз перезапустить. Смотрите, конфиг на наличие ошибок. Пробуйте запустить collectd вручную: /opt/sbin/collectd и смотреть на терминале или в логе ошибки.
  14. Скорее всего, что-то не так с http-сервером. Какой устанавливали и настраивали? Как в инструкции - lighttpd? Нужно проверить, реально ли он запускается. Он также должен писать лог в /opt/var/log/lighttpd, если в его конфиге включена опция server.errorlog = "/opt/var/log/lighttpd/error.log" Возможно, для этого также потребуется включить службу syslong-ng (информация есть в каталоге готовых решений).
  15. Сбор статистики определяется не этим каталогом, а конфигом collectd. В данном каталоге находятся только шаблоны для отображения статистики. В самом конфиге collectd сбор данных с интерфейсов (в т.ч. и PPPoE) выполняется по шаблону. Т.е. для отключения сбора данных по конкретному интерфейсу его нужно будет добавить в правило Ignore. После этого удалить соответствующие файлы rrd в /opt/var/lib/collectd/rrd/. Либо вообще их не трогать - пусть данные пишутся (но не нужно было вручную удалять файлы rrd), но сами шаблоны отображения данных убрать.
×
×
  • Create New...