Как отключить логирование linux

Lubuntu.ru

Русскоязычное сообщество Lubuntu Linux

Как отключить логи?

Модератор: adventurer

Как отключить логи?

Сообщение aleks@ » 08 мар 2018, 00:15

Как отключить логи?

Сообщение alexkaptan » 08 мар 2018, 13:47

Как отключить логи?

Сообщение aleks@ » 08 мар 2018, 15:20

Как отключить логи?

Сообщение alexkaptan » 08 мар 2018, 18:24

Как отключить логи?

Сообщение adventurer » 08 мар 2018, 18:59

Как отключить логи?

Сообщение aleks@ » 09 мар 2018, 00:49

Я прочитал кучу всякой инфы на тему SSD. В основном статьи старые, когда SSD были не такими надёжными как сегодня. Понятно главное, для SSD лучше если на него не пишется постоянно.
О логах исследование https://wiki.archlinux.org/index.php/So . 8%D0%B9%29 в самом низу

«Отключение журналирования ФС

Использование журналируемых ФС типа ext3 или ext4 с отключенным журналом тоже сократит количество записей на SSD. Очевидным недостатком этого будет являться потеря данных при неудачном размонтировании (резкое отключение питания, блокировка ядра и т. д.). Однако, Ted Tso выступает в защиту журналирования на современных SSD, т. к. по его тестам оно незначительно влияет на количество записей в большинстве случаев:

Количество записанных данных (в мегабайтах) на ФС ext4 с параметром noatime.
операция — с журналом — без журнала — разница
git clone ——- 367.0 —————353.0 ———— 3.81 %
make ———— 207.6 —————199.4 ———— 3.95 %
make clean—- 6.45 ——————3.73 ———— 42.17 %

«Результаты показали, что записанный объём при работе с большим количеством мета-данных почти в 2 раза выше, чем реальный размер файлов. Это ожидаемо, т. к. все изменения в блоках мета-данных сначала пишутся в журнал, и транзакция журнала сбрасывается перед тем, как мета-данные будут записаны в конечное положение на диск. Однако же, для обычных задач, где данные пишутся сразу за мета-данными, разница в лишних операциях записи минимальна.»

Дальше не совсем по теме.
Логи — мелочь, по сравнению с Firefox, который грузит диск больше чем что либо другое. Немного не по теме прочитал в инете https://geektimes.ru/post/280792/ .
«. на твердотельный накопитель SSD загружаются большие объемы данных вплоть до 10 ГБ. Если в браузере постоянно открыто множество окон с «тяжелыми» сайтами, то можно ожидать еще большего количества записанных Firefox данных. Главным виновником случившегося оказался браузер Firefox. Он загружал от 300 КБ до 2 МБ ежесекундно. Запись велась в файл с названием recovery.js. Как оказалось, это резервная копия сессии Firefox. Она используется в том случае, если «падает» браузер или операционная система. Это полезная, но ресурсоемкая функция. И если учесть то, что у SSD ограниченный ресурс, то здесь уже нужно решить для себя, что полезнее — рабочий диск или же восстановление текущей сессии браузера после его падения. .

Проблема решается настройкой в about:config
browser.sessionstore.interval 15000

browser.sessionstore.interval — Настройка хранит количество миллисекунд, по истечении которых происходит сохранение сессии браузера. Если значение указано 15000, то каждые 15 секунд, сессия сохраняется на диск, чтобы в случае краха можно было восстановить все открытые вкладки.

меняем параметр на больший — 1800000 (30 минут) В этом случае количество генерируемых Firefox за день данных снижается с 10-15 ГБ до 2 ГБ.

Чтобы не мелочиться поставил 3600000 (60 минут), не падает у меня Firefox, не помню когда такое было.

Источник

Как отключить запись логов в ubuntu 10.04?

Всем доброго времени суток, мне нужно узнать как отключить запись логов в ubuntu 10.04 netbook remix.

чьих логов?
man init

ты задай вопрос так, как задал его мне в аське: как снизить энергопотребление?

логов системы и всего остального кто может их писать на хард.

Всё полностью?
Поставь bum (там почитаешь что отключить для)

А собственно оттуда и пришел, половина статьи не потходит, к примеру там заместо HDD SSD.

> заместо HDD SSD.

есть принципиальная разница?

>там заместо HDD SSD
так ещё меньше жрать будет если механика у тебя

Главное чтоб срок службы от этого не уменьшился этого я боюсь.

dron999or, посмотри в сторону

/etc/logrotate.conf и /etc/logrotate.d/

не включай компьютер и в лес не ходи 🙂

История из жизни
Открывается дверь в кабинет, я сижу, уткнулся в монитор. Вдруг — бац, на стол приземляется хард, через секунду раздаётся голос моего коллеги: «Жёсткий нужен на 80 гигов? Почти задаром». Отрываю глаза с наклейки WD, поднимаю — синий он (товарищ). Не :), говорю, уже не надо. Самое интересное, что он заходил ещё в кабинетов 5 и проделывал тоже самое (бросал хард на стол как пачку фисташек). И жёсткий до сих пор работает и хоть бы хны 🙂 купил один за 500 р. Это в году 2005 было 😉

Источник

Как отключить логи? Совсем.

Как бы отключить логи в системе с systemd? Ну чтобы совсем!

Чтобы сделать систему, малочувствительную к внезапному отключению питания.

Пока совершил такое:

Большинство логов действительно перестало записываться, но еще по-прежнему копошатся 4 лога —

и еще образовалась пустая папка /private

Как бы их отключить тоже? И позволительно ли это?

А то глянул, некоторые из этих логов связаны со входом в систему и паролями, может, их нельзя отключать.

Еще наверное, надо Своп отключить в fstab, чтобы у системы не возникало желания что-нибудь туда писануть.

PS. Понятно, что радикальнее перевести ФС в Read Only, но как глянул, как это муторно делается, так сразу и расхотелось —
https://wiki.debian.org/ReadonlyRoot
https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash

смонтируй /var/log в tmpfs

man journald.conf, костылестроитель

Гланды через жопу удалять ещё предложи

PS. Понятно, что радикальнее перевести ФС в Read Only, но как глянул, как это муторно делается, так сразу и расхотелось —

В ubuntu это делается элементарно, просто ты не туда смотришь. Смотреть надо сюда.

А при чем тут журналирование? Я не хочу, чтобы от Ext4 отвалилась такая важная фича, как журналирование.
Мне всего-навсего нужно отключить запись логов.

Или да, лучше отправить их в tmpfs —

— это так делается?

Заодно и /tmp и /run —

А, это троллинг тупостью. Сразу не распознал.

Сам ты тупой, еще тупее.

Вот, нашел даже для «Малины» классную прогу — Log2RAM,

а для настольного Линукса так и не сообразили сделать.

В OpenWRT /var это символьная ссылка на /tmp , который на tmpfs. Так что там как раз /var/log на tmpfs.

Так что там как раз /var/log на tmpfs.

Где там? У меня не OpenWRT, обычный настольный Debian.

/var/log в tmpfs вполне хорошее решение.

Так я это и сделал! Но не ковырянием в конфигах или в носу, как некоторые, а с помощью удобной утилиты Log2RAM!

Учитесь работать с удобством! 🙂

А онанимусы нонче тупые пошли, ну тупые! Только и делают, что прячут свою тупость за онанимным ником.

Ты такое же безликий аноним, или указывай в профиле паспортные данные и место прописки или щеки перестань надувать.

Весь твой спич основан на том, что ты даже найти информацию не можешь поисковиком, за тебя уже поисковик все ищет, а ты и так не смог.

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

Все, давай, пшелотседава, видеть тебя не могу, амеба.

Ты читал ОП-пост?

Или тоже тупостью троллишь, как ОП?

Ты читал ОП-пост?

Или тоже тупостью троллишь, как ОП и i-rinat?

Анонимусы, да вы прямо захлебываетесь от злости, значит, в точку попал :))

От злости и язвительности тут захлебывался только ты, и твои пафосные речи тому подтверждение. На самом же деле ты без подсказок прожить не можешь.

The script log2ram can work on every linux system

Чукча не читатель?

А что не так с systemd? Оно особенное и не даёт tmpfs работать? 4.2 же. /var/log/journal/ туда systemd гадит (если иное не прописано). Заодно все нормальные логи разом на 0 умножатся, а не только от systemd, ТС просит все логи убрать, а не только systemd. При этом логи за сессию можно будет посмотреть.

Ещё один думает что man journald.conf это про отключение журналирования на ext4?

Нет, просто ты клоун и думаешь что все логи управляются через journald.conf. Увы, это не так, порой и явные велосипеды логи пишут. В худшем случае в хомяк юзера и захардкожено. Но обычно надежды на то, что логи пишутся в /var/log более большие, чем то что journald.conf может их зарегулировать. vlc тот же тоже логами срать умеет и плевать ему на системд и всё остальное, вроде недавно научили срать в нормальный лог, но если хочет мейнтейнер или ты, то гадить будет куда душе угодно.

vlc из-под обычного юзера умеет писать в /var/log ?

Если очень не постараться, то нет. А вот rsyslog/syslog-ng вместе с systemd очень даже могут работать. В Debain и Ubuntu так было точно, как в самых свежих не знаю, не проверял.

Как бы отключить логи в системе с systemd?

Чтобы сделать систему, малочувствительную к внезапному отключению питания.

От отключения логов чувствительность к отключению никак не изменится.

Как бы отключить Чукчу. Совсем.

Чтобы сделать систему, малочувствительную к внезапному отключению питания.

IPS спасет отца русской демократии.

А ограничить ведение логов не судьба? Хотя отключай неаноним, не войдёшь в систему, будешь тут меньше срать

малочувствительную к внезапному отключению питания

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

при отключении питания портятся в первую очередь данные, то бишь фс. таким образом твой выбор методик если у тебя нет упса — ридонли разделов, отключение свапа и тюнинг твоей фс. если ext4, то использование фич в роде journal_data,nodelalloc и тп.

у меня на практике при отключении питания хорошо показывали себя такие фс, как zfs и ntfs (да-да, без проблем восстановить данные можно при любом раскладе). а наиболее худшие результаты при отключении питания показывали бздшние ffs и ufs. ext4 где-то посередине. ещё хуже btrfs, которую без упса я бы не использовал. ну или только на ноуте. btrfs вообще очень специфическая фс и если её плохо знаешь лучше сюда не суваться.

а толку от включения или отключения логов нет никакого. моргнёт у тебя свет, машина ребутнётся, и в терминале тебя ждёт приятный сюрприз:

и куча нечитаемых файлов где-нибудь в /home и в /etc

Источник

Управление логгированием в systemd

Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04). В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию.
В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений). При этом специально настраивать отправку логов не нужно: приложения могут просто писать в stdout и stderr, a journal сохранит эти сообщения автоматически. Работа в таком режиме возможна и с Upstart, но он сохраняет все логи в отдельный файл, тогда как systemd сохраняет их в бинарной базе, что существенно упрощает систематизацию и поиск.

Хранение логов в бинарных файлах также позволяет избежать сложностей с использованием парсеров для разных видов логов. При необходимости логи можно без проблем переконвертировать в другие форматы (более подробно об этом будет рассказано ниже).
Journal может работать как совместно с syslog, так и полностью заменить его.
Для просмотра логов используется утилита journalctl. Об особенностях и тонкостях работы с ней мы расскажем в этой статье.

Установка времени

Одним из существенных недостатков syslog является сохранение записей без учёта часового пояса. В journal этот недостаток устранён: для логгируемых событий можно указывать как местное время, так и универсальное координированное время (UTC). Установка времени осуществляется с помощью утилиты timedatectl.
Просмотреть список часовых поясов можно при помощи команды:

Установка нужного часового пояса осуществляется так:

По завершении установки будет нелишним убедиться в том, что всё сделано правильно:

В самой первой строке (Local time) должны быть показаны точное текущее время и дата.

Journalctl: просмотр логов

Для просмотра логов используется утилита journalctl.
Если ввести команду journalсtl без каких-либо аргументов, на консоль будет выведен огромный список:

Здесь мы привели лишь небольшой его фрагмент; на самом деле он включает гигантское количество записей.

Фильтрация логов

У утилиты journalctl есть опции, с помощью которых можно осуществлять фильтрацию логов и быстро извлекать из них нужную информацию.

Просмотр логов с момента текущей загрузки

С помощью опции -b можно просмотреть все логи, собранные с момента последней загрузки системы:

Просмотр логов предыдущих сессий

С помощью journalctl можно просматривать информацию о предыдущих сессиях работы в системе — в некоторых случаях это бывает полезным.
Следует, однако, учитывать, что сохранение информации о предыдущих сессиях поддерживается по умолчанию не во всех дистрибутивах Linux. Иногда его требуется активировать

Для этого нужно открыть конфигурационный файл journald.conf, найти в нём раздел [Journal] и изменить значение параметра storage на persistent:

Просмотреть список предыдущих загрузок можно с помощью команды:

Её вывод состоит из четырёх колонок. В первой из них указывается порядковый номер загрузки, во второй — её ID, в третьей — дата и время. Чтобы просмотреть лог для конкретной загрузки, можно использовать идентификаторы как из первой, так и из второй колонки:

Фильтрация по дате и времени

В journalctl имеется также возможность просмотра логов за определённые периоды времени. Для этого используются опции —since и —until. Предположим, нам нужно просмотреть логи начиная с 17 часов 15 минут 20 июля 2015 года. Для этого потребуется будет выполнить команду:

Если с опцией since не будет указано никакой даты, на консоль будут выведены логи начиная с текущей даты. Если дата указана, но при этом не указано время, будет применено значение времени по умолчанию — «00:00:00». Секунды также указывать не обязательно (в этом случае применяется значение по умолчанию — 00).

Можно воспользоваться и вот такими человекопонятными конструкциями:

Фильтрация по приложениям и службам

Для просмотра логов конкретного приложения или службы используется опция -u, например:

Приведённая команда выведет на консоль логи веб-сервера nginx.
Нередко возникает необходимость просмотреть логи какой-либо службы за определённый период времени. Это можно сделать при помощи команды вида:

C опцией -u также используется фильтрация по дате и времени, например:

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

Фильтрация по процессам, пользователям и группам

Просмотреть логи для какого-либо процесса можно, указав в команде journalctl его идентификационный номер (PID), например:

Для просмотра логов процессов, запущенных от имени определённого пользователя или группы, используются фильтры _UID и _GID соответственно. Предположим, у нас имеется веб-сервер, запущенный от имени пользователя www-data. Определим сначала ID этого пользователя:

Теперь можно просмотреть логи всех процессов, запущенных от имени этого пользователя:

Вывести на консоль список пользователей, о которых имеются записи в логах, можно так:

Для просмотра аналогичного списка пользовательских групп используется команда:

С командной journalctl можно использовать и другие фильтры. Просмотреть список всех доступных фильтров можно, выполнив команду

Фильтрация по пути

Просмотреть логи для какого-либо процесса также можно, указав путь к нему, например:

Иногда таким способом можно получить более подробную информацию (например, просмотреть записи для всех дочерних процессов).

Просмотр сообщений ядра

Для просмотра сообщений ядра используется опция -k или −−dmesg:

Приведённая команда покажет все сообщения ядра для текущей загрузки. Чтобы просмотреть сообщения ядра для предыдущих сессий, нужно воспользоваться опцией -b и указать один из идентификаторов сессии (порядковый номер в списке или ID):

Фильтрация сообщений по уровню ошибки

Во время диагностики и исправления неполадок в системе нередко требуется просмотреть логи и выяснить, есть ли в них сообщения о критических ошибках. Специально для этого в journalctl предусмотрена возможность фильтрации по уровню ошибки. Просмотреть сообщения обо всех ошибках, имевших место в системе, можно с помощью опции -p:

Приведённая команда покажет все сообщения об ошибках, имевших место в системе.

Эти сообщения можно фильтровать по уровню. В journal используется такая же классификация уровней ошибок, как и в syslog:

• 0 — EMERG (система неработоспособна);
• 1 — ALERT (требуется немедленное вмешательство);
• 2 — CRIT (критическое состояние);
• 3 — ERR (ошибка);
• 4 — WARNING (предупреждение);
• 5 — NOTICE (всё нормально, но следует обратить внимание);
• 6 — INFO (информационное сообщение);
• 7 —DEBUG (отложенная печать).

Коды уровней ошибок указываются после опции -p.

Запись логов в стандартный вывод

По умолчанию journalctl использует для вывода сообщений логов внешнюю утилиту less. В этом случае к ним невозможно применять стандартные утилиты для обработки текстовых данных (например, grep). Эта проблема легко решается: достаточно воспользоваться опцией −−no-pager, и все сообщения будут записываться в стандартный вывод:

После этого их можно будет передать другим утилитам для дальнейшей обработки или сохранить в текстовом файле.

Выбор формата вывода

C помощью опции -o можно преобразовывать данные логов в различные форматы, что облегчает их парсинг и дальнейшую обработку, например:

Объект json можно представить в более структурированном и человекочитаемом виде, указав формат json-pretty или json-sse:

Помимо JSON данные логов могут быть преобразованы в следующие форматы:

• cat — только сообщения из логов без служебных полей;
• export — бинарный формат, подходит для экспорта или резервного копирования логов;
• short — формат вывода syslog;
• short-iso — формат вывода syslog с метками времени в формате ISO 8601;
• short-monotonic — формат вывода syslog c метками монотонного времени (monotonic timestamp);
• short-precise — формат вывода syslog с метками точного времени (время событий указывается с точностью до микросекунд);
• verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).

Просмотр информации о недавних событиях

Опция -n используется для просмотра информации о недавних событиях в системе:

По умолчанию на консоль выводится информация о последних 10 событиях. С опцией -n можно указать необходимое число событий:

Просмотр логов в режиме реального времени

Сообщения из логов можно просматривать не только в виде сохранённых файлов, но и в режиме реального времени. Для этого используется опция -f:

Управление логгированием

Определение текущего объёма логов

Со временем объём логов растёт, и они занимают всё больше места на жёстком диске. Узнать объём имеющихся на текущий момент логов можно с помощью команды:

Ротация логов

Настройка ротации логов осуществляется с помощью опций −−vacuum-size и −−vacuum-time.
Первая из них устанавливает предельно допустимый размер для хранимых на диске логов (в нашем примере — 1 ГБ):

Как только объём логов превысит указанную цифру, лишние файлы будут автоматические удалены.
Аналогичным образом работает опция −−vacuum-time. Она устанавливает для логов срок хранения, по истечении которого они будут автоматически удалены:

Настройка ротации логов в конфигурационном файле

Настройки ротации логов можно также прописать в конфигурационном файле /еtc/systemd/journald.conf, который включает в числе прочих следующие параметры:

• SystemMaxUse= максимальный объём, который логи могут занимать на диске;
• SystemKeepFree= объём свободного места, которое должно оставаться на диске после сохранения логов;
• SystemMaxFileSize= объём файла лога, по достижении которого он должен быть удален с диска;
• RuntimeMaxUse= максимальный объём, который логи могут занимать в файловой системе /run;
• RuntimeKeepFree= объём свободного места, которое должно оставаться в файловой системе /run после сохранения логов;
• RuntimeMaxFileSize= объём файла лога, по достижении которого он должен быть удален из файловой системы /run.

Централизованное хранение логов

Одной из самых распространённых задач в работе системного администратора является настройка сбора логов с нескольких машин с последующим помещением в централизованное хранилище.
В systemd предусмотрены специальные компоненты для решения этой задачи: systemd-journal-remote, systemd-journal-upload и systemd-journal-gatewayd.

С помощью команды systemd-journal-remote можно принимать логи с удалённых хостов и сохранять их (на каждом их этих хостов должен быть запущен демон systemd-journal-gatewayd), например:

В результате выполнения приведённой команды логи с хоста some.host будут сохранены в директории var/log/journal/some.host/remote-some

С помощью команды systemd-journal-remote можно также складывать имеющиеся на локальной машине логи в отдельную директорию, например:

Команда systemd-journal-upload используется для загрузки логов с локальной машины в удалённое хранилище:

Как видно из приведённых примеров, «родные» утилиты systemd для поддержки централизованного логгирования просты и удобны в работе. Но они, к сожалению, пока что включены далеко не во все дистрибутивы, а только в Fedora и ArchLinux.

Пользователи других дистрибутивов пока что приходится передавать логи в syslog или rsyslog, которые затем пересылают их по сети. Ещё одно решение проблемы централизованного логгирования было предложено разработчиками утилиты journal2gelf, включённой в официальный репозиторий systemd: вывод journalсtl в формате JSON конвертируется в формат GELF, а затем передаётся приложению для сбора и анализа логов Graylog. Решение не очень удобное, но ничего лучше в текущей ситуации придумать нельзя. Остаётся только ждать, когда «родные» компоненты будут добавлены во все дистрибутивы.

Заключение

Как видно из проделанного рассмотрения, systemd journal представляет собой гибкий и удобный инструмент для сбора системных данных и данных приложений. Высокого уровня гибкости и удобства удалось добиться, во-первых, благодаря централизованному подходу к логгированию, а во-вторых — благодаря автоматической записи в логи подробных метаданных. С помощью journalctl можно просматривать логи, получая необходимую информацию для анализа работы и отладки различных системных компонентов.
Если у вас есть вопросы и дополнения — добро пожаловать в комментарии. Разговор о systemd и его компонентах будет продолжен в следующих публикациях.

Читателей, которые по тем или иным причином не могут оставлять комментарии здесь, приглашаем в наш блог.

Источник