Перезапустить syslog в linux

Обновлено: 03.07.2024

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

Во-вторых, рассматривается процесс настройки демона syslog, а также его тестирования с помощью утилиты logger .

Последняя часть главы в основном посвящена механизму ротации фалов журналов , а также содержит пояснения относительно использования команд tail -f и watch для отслеживания изменений файлов журналов .

17.1. Журналирование входов в систему

С целью облегчения процесса отслеживания входов пользователей в систему Linux может записывать необходимые данные в файлы журналов /var/log/wtmp , /var/log/btmp , /var/run/utmp и /var/log/lastlog .

17.1.1. Файл журнала /var/run/utmp (who)

Используйте утилиту who для просмотра содержимого файла /var/run/utmp. Эта утилита выводит информацию о пользователях, осуществивших вход в систему и в данный момент работающих с ней. Обратите внимание на то, что файл utmp находится в директории /var/run, а не /var/log.

17.1.2. Файл журнала /var/log/wtmp (last)

Содержимое файла журнала /var/log/wtmp обновляется силами программы login . Используйте утилиту last для просмотра содержимого файла журнала /var/run/wtmp.

Утилита last также может использоваться и для получения информации о последних перезагрузках.

17.1.3. Файл журнала /var/log/lastlog (lastlog)

Используйте утилиту lastlog для просмотра содержимого файла /var/log/lastlog.

17.1.4. Файл журнала /var/log/btmp (lastb)

Также существует утилита lastb , предназначенная для вывода содержимого файла /var/log/btmp . Содержимое этого файла обновляется программой login при вводе некорректного пароля, следовательно, он содержит информацию о неудачных попытках входа в систему. В файловых системах множества компьютеров данный файл может отсутствовать, в результате чего неудачные попытки входа в систему не будут журналироваться.

Обычно данный файл удаляют по той причине, что пользователи иногда по ошибке вводят свой пароль вместо имени учетной записи, следовательно, читаемый всеми файл является потенциальной угрозой безопасности системы. Вы можете активировать механизм журналирования неудачных попыток входа в систему, просто создав файл с упомянутым именем. В этом случае исполнение команды chmod o-r /var/log/btmp позволит повысить защищенность системы.

Информация о попытках ввода некорректных паролей при использовании утилит ssh, rlogin или su не сохраняется в файле /var/log/btmp. В нем сохраняется исключительно информация о попытках ввода некорректного пароля при работе с терминалами.

17.1.5. Журналирование входов в систему с использованием утилит su и ssh

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

17.2. Демон журналирования событий syslogd

17.2.1. О демоне syslogd

17.2.2. О демоне rsyslogd

Новый демон журналирования событий носит имя rsyslogd (reliable and extended syslogd - надежный и расширяемый syslogd) и использует файл конфигурации /etc/rsyslogd.conf . Обратная совместимость синтаксиса данного файла конфигурации сохранена.

17.2.3. Модули

Обратитесь к страницам руководств для получения дополнительной информации (после того, как вы закончите чтение данной главы).

17.2.4. Идентификаторы систем (facilities)

17.2.5. Описания приоритетов (priorities)

Ниже приведен список приоритетов в порядке возрастания. Ключевые слова warn, error и panic являются устаревшими.

17.2.6. Действия (actions)

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

17.2.7. Конфигурация

17.2.8. Перезапуск демона rsyslogd

Не забудьте перезапустить демон после модификации его файла конфигурации.

17.3. Утилита logger

Результаты тестирования демона журналирования событий с помощью утилиты logger.

17.4. Просмотр журналов событий

Вы можете использовать команду tail -f для просмотра последних строк файла журнала. Параметр -f позволяет динамически выводить строки, которые добавляются в файл журнала в реальном времени.

Также вы можете автоматически повторять вызовы утилит, размещая перед ними вызов утилиты watch . Примером может служить следующая команда:

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

17.5. Ротация журналов событий

Размер большинства файлов журналов событий неуклонно растет. Для ограничения размеров этих файлов может использоваться утилита logrotate , предназначенная для ротации, сжатия, удаления и отправки по электронной почте файлов журналов событий. Дополнительная информация об утилите logrotate может быть получена из основного файла конфигурации /etc/logrotate.conf . Отдельные файлы конфигурации могут находиться в директории /etc/logrotate.d/ .

Ниже приведено содержимое стандартного файла конфигурации logrotate.conf из состава дистрибутива Red Hat.

17.6. Практическое задание: журналирование событий

1. Выведите содержимое файла журнала /var/run/utmp с помощью специально предназначенной для этой цели утилиты (без использования утилиты cat или текстового редактора vi).

2. Выведите аналогичным образом содержимое файла журнала /var/log/wtmp.

3. Используйте утилиты lastlog и lastb и сделайте вывод о различии этих утилит.

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

17.7. Корректная процедура выполнения практического задания: журналирование событий

2. Выведите аналогичным образом содержимое файла журнала /var/log/wtmp.

3. Используйте утилиты lastlog и lastb и сделайте вывод о различии этих утилит.

lastlog : выводит информацию о последних входах пользователей в систему

lastb : выводит информацию о неудачных попытках входа в систему

Дистрибутивы Ubuntu 9.10 и Debian Lenny переведены на использование демона журналирования событий rsyslog.

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

В Debian/Ubuntu следует отредактировать файл /etc/default/syslog или /etc/default/rsyslog .

На клиентском компьютере:

Управление типом и подробностью журналируемой информации

Конфигурационный файл syslog.conf

Файл syslog.conf является главным конфигурационным файлом для демона syslogd. Конфигурационный файл syslog.conf представляет собой набор правил. Каждое правило есть - строка, состоящая из селектора и действия , разделенных пробелом или табуляцией. Селектор представляет собой запись в виде источник . приоритет . (источник иногда именуют - категорией) Селектор может состоять из нескольких записей источник.приоритет, разделенных символом ";" . Можно указывать несколько источников в одном селекторе (через запятую). Поле действие - устанавливает журналируемое действие для селектора.

Источник (он же категория) может быть следующим:

Обычный файл

Задается полным путем, начиная со слеша (/). Поставьте перед ним дефис (-), чтобы отменить синхронизацию файла после каждой записи. Это может привести к потере информации, но повысить производительность.

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Список пользователей

Пример несложного syslog.conf:

Как и во многих конфигурационных файлах, синтаксис следующий:

В синтаксисе конфигурационного файла можно поставить перед приоритетом знак !, чтобы показать, что действие не должно применяться, начиная с этого уровня и выше. Подобным образом, перед приоритетом можно поставить знак =, чтобы показать, что правило применяется только к этому уровню, или !=, чтобы показать, что правило применяется ко всем уровням, кроме этого. Ниже показано несколько примеров (man syslog.conf можно найти множество других примеров):

Я постарался максимально понятно работу syslogd показать на схеме:

Запуск демона syslogd

Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog, однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт - начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian).

Вот некоторые возможные параметры запуска демона syslogd:

После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.

С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`

можно послать демону syslogd один из следующих сигналов: SIGHUP - перезапуск демона; SIGTERM - завершение работы; SIGUSR1 - включить/выключить режим отладки.

Вообще-то в системе запускаются два демона протоколирования - syslogd и klogd. Оба демона входят в состав пакета sysklogd.

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate, которая обычно выполняется демоном cron. О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.

Для определения порядка ротации и архивирования журналов используется конфигурационный файл /etc/logrotate.conf. Для разных журналов можно задать разную периодичность, например, ежедневно, еженедельно или ежемесячно, кроме того, можно регулировать количество накапливаемых поколений, а также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. Ниже показан пример файла /etc/logrotate.conf:

Глобальные опции размещаются в начале файла logrotate.conf. Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.

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

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

В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.

Параметры, задаваемые в конфигурационном файле logrotate.conf:

Изучение и мониторинг журналов

Далее в файле протокола можно обнаружить версию ядра, параметры его запуска, информацию о типе процессора и объеме ОЗУ:

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

Кроме файлов-журналов, указанных в /etc/syslog.conf, существуют так же и другие файлы, например файл /var/log/dmesg, который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы /var/log/lastlog, /var/log/wtmp, /var/log/btmp, имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах пользователей в систему и о всех неудачных входах пользователей в систему соответственно. Так же в каталоге /var/log/ могут находится лог-файлы таких демонов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журналам syslogd.

Подведем небольшой итог:

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

Приветствую, читатель моего блога. Давненько я не писал статей. Много жизненных перемен. Сегодняшняя статья будет посвящена syslog, а точнее rsyslog, который активным образом внедряется вместо старенького syslogd (он же sysklogd) в последних версиях дистрибутивов (например, Suse, Debian, RedHat и др.). Базовое описание работоспособности syslog и logrotate я приводил в соответствующей статье. Поэтому перед прочтением нижеописанного я очень советую прочитать статью о syslog и logrotate. На текущий момент для меня стоит задача собирать системные журналы syslog с сетевого оборудования в количестве

100 хостов с последующим увеличением их количества. Реализацией данного функционала я и постараюсь заняться в данной статье, предварительно описав структуру конфига и принцип работы rsyslog. Все это дело будет описано на базе Debian 6, в других дистрибутивах, при наличии опыта, с минимумом движений напильником, думаю что тоже не составит большого труда настроить. Итак, начнем.

Введение rsyslog

Установка rsyslogd

Установка rsyslog (если по какой-то причине он не установлен по умолчанию) сводится к одной команде:

Если, конечно, нет желания устанавливать из исходников. Тогда необходимо прочитать install manual . После установки в Debian, мы будем иметь следующее размещение файлов (показаны наиболее важные):

Как видно, все элементарно. rsyslog состоит из бинарника и файла конфигурации. Кроме указанных файлов, rsyslog так же использует:

rsyslog настройка

Модули (Modules)
Конфигурационные директивы (не знаю, как перевести более доступно) (Configuration Directives)
Шаблоны (template)
Правила сортировки (Rule line)

Давайте разберем каждый раздел.

Модули (Modules) rsyslog

Rsyslog имеет модульную архитектуру. Это позволяет удобно расширять функциональность. Модули подразделяются на группы, например некоторые из них:

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

Конфигурационные директивы (Configuration Directives)

Конфигурационные директивы иногда называют глобальными директивами, они задают общие параметры работы демона rsyslogd. Директива имеет формат $Директива параметр

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

Шаблоны (Templates) rsyslog

Cинтаксис template

В целом, структуру шаблона можно представить в следующем виде синтаксисе:

Применение переменных в шаблонах rsyslog

Давайте разгребем структуру значений, указываемых в %процентах%.

Как видно, некоторые свойства начинаются с знака доллара - они считаются локальными\системными.

Значения начало_строки : конец_строки - мозговыносящие. Победить их можно где-то тут . Кратко - они используются для регулярных выражений.

Далее - опции. Опции позволяют модифицировать переменную в границе от знака процента до знака процента. Можно применять одновременно несколько опций, через запятую. Если указать несколько противоречащих (например uppercase, lowercase), то будет применена последняя указанная (lowercase). Вот некоторые опции:

uppercase - преобразование к верхнему регистру
lowercase - преобразование к нижнему регистру
date-mysql - преобразовать в формат даты MySQL
space-cc - заменить управляющие символы пробелами
drop-cc - удалить управляющие символы
и еще куча

fieldname - данное поле доступно с версии 6.3.9+ и имеет очень специфичный характер. Можно ее забыть.

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

Шаблоны, которые хардово запрограммированы в rsyslog (но которые можно изменить директивой $ActionFileDefaultTemplate):

RSYSLOG_SyslogProtocol23Format - формат, определённый в проекте стандарта IETF ietf-syslog-protocol-23, соответствует шаблону:

RSYSLOG_FileFormat - традиционный формат журнала, с добавлением долей секунды и зоны, соответствует шаблону:

RSYSLOG_TraditionalFileFormat - традиционный формат журнала для записи в файл, соответствует следующему шаблону:

RSYSLOG_ForwardFormat - традиционный формат журнала для передачи с добавлением долей секунды и зоны, соответствует шаблону:

RSYSLOG_TraditionalForwardFormat - традиционный формат журнала для передачи на удалённый сервер

Правила сортировки rsyslog (Rule line)

Фильтрация RainerScript (RainerScript-based filters)

Как я уже сказал, RainerScript - это классический язык на основе if then else. В rsyslog RainerScript поддерживает вложенность условий, арифметические, логические и строковые операции. В целом, синтаксис следующий:

логические выражения (and, or, not), а так же группировку данных выражений в виде: not условие0 and (условие1 and условие2).
переменные (properties) - переменные указываются в виде $имя_переменной (например $hostname или $msg)
операции сравнения (== - равно, != - не равно, > - больше, < - меньше, <= - меньше или равно, >= - больше или равно, (!)contains - (не)содержит, (!)startswith - (не)начинается с)
комментарии /* комментарии */ (сомнительный пункт . нужно ли его экранировать как в bash . )

Описание языка есть на сайте . Маленький пример фильтра на основе RainerScript:

if $syslogfacility-text == 'local7' and $msg startswith 'CISCO' and ($msg contains 'warn' or $msg contains 'emer') then /var/log/cisco-alarm

Давайте рассмотрим данный вид фильтрации.

: переменная , [!] операция_сравнения , " искомое_значение " действие

contains - проверяет соответствие искомое_значение с любой частью строки в переменная
isequal - проверяет, совпадает (целиком) ли искомое_значение с переменной
isempty - проверяет, является ли переменная пустой (доступна с 6.6.2)
startswith - проверяет, начинается ли переменная с искомое_значение
regex или ereregex - сравнивает содержимое переменной, заданному в искомое_значение регулярному выражению в соответствии с regular и Extended Regular Expression соответственно

Например: :msg, contains, "syslog" будет искать слово syslog в теле.

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

Действия (actions)

Действия rsyslog полностью совместимы с действиями syslog. Так же, стоит учитывать, что в действии rsyslog, кроме стандартный значений syslog, добавились дополнительные (выделены цветом ):

rsyslog в картинках

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

Вот, собственно и вся схема.

Централизованный сервер rsyslog в Debian

После задания указанных параметров, необходимо перезапустить\перечитать конфигурационный файл (service rsyslog restart). При этом, netstat нам должен показать, что сислог стал слушать соответствующий порт:

Настройка клиентов syslog

Linux (rsyslog)

Cisco

VMware ESXi

Для старенького гипервизора:

В /etc/syslog.conf необходимо добавить следующее:

В последних версиях гипервизора все делается через гуишного клиента. В настройках гипервизора Advansed -> Syslog -> remote указать адрес rsyslog сервера.

Хранение журнала rsyslog в СУБД MySQL

В Debian настройка хранения в базе данных мега простая (почти как в вендовозе ) ). В целом, достаточно установить пакет rsyslog-mysql. При этом, установщик кладет модуль ommysql.so в каталог /usr/lib/rsysloul/spang/ и запускает мастер настройки, который запрашивает пароль администратора MySQL, создает отдельного пользователя и просит указать для него пароль. Создает соответствующую базу из скрипта /usr/share/dbconfig-common/data/rsyslog-mysql/install/mysql. Получившиеся настройки кладет в /etc/rsyslog.d/mysql.conf. Конфиг получается из 2х строчек::

Веб интерфейс для rsyslog

В текущем каталоге появится каталог loganalyzer-3.5.6, который содержит некоторую информацию, достойную прочтения:

Видим, для чего мы давали права 666, нажимаем Next

Здесь выбираем желаемые настройки. Отдельного внимания требует параметр Enable User Database. Если выбрать его, то будет создана отдельная база для хранения настроек Веб-интерфейса. Так же, будет доступна возможность создавать пользователей и группы. Жмем next.

Это все. Ниже пару скриншотов того, что получилось:

Есть маленькое дополнение - веб сервер не имеет доступа к обычным файлам в каталоге /var/log/. Поэтому, журнал может не отображаться. Чтобы решить данную проблему, необходимо добавить пользователя www-data в группу adm:

Кроме Loganalyzer существует так же - Logzilla, обладающая тем же функционалом. Ее тоже стоит попробовать установить, если есть желание.

Некоторые типсы и триксы для rsyslog

Для того чтобы разрешить в нетфильтре прохождение udp пакетов, необходимо использовать команду:

Некоторые примеры правил с комментариями:

Траблешуттинг

Для диагностики работы syslog отлично помогает tcpdump, пример команды для мониторинга:

Ну и, конечно же сам /var/log/syslog.

Что еще почитать

Резюме

Статья получилась мега большая. В перспективе, наверно разделю ее на 2 более подробные. В целом, думаю, что прочитав материал - удастся получить достаточный объем базового понимания принципов работы rsyslog, чтобы реализовать своё более сложное и интересное решение. До новых статей!

Linux Syslog configuration

One of the most important daemons on Unix or Linux based system is syslogd ! It logs many crucial system events by default. Logs written by syslogd are commonly referred to as Syslog. Syslogs are first logs when you want to trace issues with your system. They are the lifeline of sysadmins 🙂

In this article, we will see configuration files for syslogd , different configs and how to apply them. Before we begin to go through the below files which we will be using throughout this article frequently.

/etc/syslog.conf : syslogd configuration file
/var/log/messages : Syslog file

Syslog uses port TCP 514 for communication.

syslogd daemon

This daemon starts with systems and runs in the background all the time, capturing system events and logging them in Syslog. It can be started, stop, restart like other services operations in Linux. You need to check which Syslog version (three projects as stated above) is running ( ps -ef |grep syslog ) and accordingly, use the daemon name.

After making any changes in the configuration file you need to restart syslogd in order to take these new changes in effect.

syslog configuration file

As stated above /etc/syslog.conf is a configuration file where you can define when, where, which event to be logged by Syslog daemon. There name changes as per your Syslog version

/etc/syslog.conf for syslog
/etc/syslog-ng.conf for syslog-ng
/etc/rsyslog.conf for rsyslog

The typical config file looks like below :

Here, on the left side column shows services for which you want logs to be logged along with their priority (succeeded by . after service name) and on the right side are actions normally destinations where logs should be written by the daemon.

Services values and priorities :

local7: boot messages
kern: Kernel messages
auth: Security events
authpriv : Access control related messages
mail, cron: mail and cron related events

Service priorities :

debug
info
notice
warning
err
crit
alert
emerg
* means all level of messages to be logged
none means no messages to be logged

All the above priorities are given in ascending level of urgency.

Actions/destination :

Those mostly log files or remote Syslog server to which logs get sent. The remote server can be specified by IP or hostname preceded by @ sign.

Syslog

All logs by syslogd are written its Syslog file /var/log/messages . Typical Syslog file looks like :

Here file can be read in below parts from left to right :

Testing Syslog logging

To test if the daemon is logging messages in Syslog or not, you can use logger command. With this command, you can specify numerous options like a priority, service, etc. But even without any argument, you can supply a string to write in Syslog and it will do the job for you.

У меня на VPS auth.log, daemon.log, messages, dmesg, syslog, boot, debug, mail.log пустые. Помогите найти причину, почему не пишутся эти логи.

ps aux | grep systemd

Я не силён в линуксе, поэтому прошу, отвечайте как новичку, пожалуйста

какой дистр. установлен?

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

Ubuntu Linux 12.04.2

command not found

Я не силён в линуксе, поэтому прошу, отвечайте как новичку, пожалуйста

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

Webmin давно установлен. Тыкался уже везде, ничего не прояснилось. С помощью этого форума много задач решил, вот и сейчас есть надежда на помощь. Кстати, техподдержка должна помочь? Или это в их обязанности не входит?

Задай вопрос поддержке, думаю не побьют.

ага. Предлагают несколько вариантов: google, перезагрузка, переустановка, найми сисадмина. Другая помощь, говорят, в их обязанности не входит. У всех такая техподдержка, или моя отстой?

ну ладно, стоило попытаться )
на всякий случай, что говорит ls -la /var/log ?
и попробуй sudo apt-get install --reinstall rsyslog

Deleted ( 18.08.17 18:12:17 )
Последнее исправление: Deleted 18.08.17 18:14:28 (всего исправлений: 1)

Предлагают несколько вариантов: google, перезагрузка, переустановка, найми сисадмина

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

rsyslog у меня нет. Может, что-то другое отвечает за логирование? Или rsyslog должен быть обязательно.

Спасибо. Я так же подумал :)

поставь rsyslog и ещё logrotate на всякий.

Deleted ( 18.08.17 18:33:35 )
Последнее исправление: Deleted 18.08.17 18:34:32 (всего исправлений: 1)

Так. Значит установить rsyslog. А обновление дистрибутива мои настройки не собъёт? Или все программы заново ставить и настраивать?

Не должно ничего поломаться. Возможно придётся перезапустить виртуалку, чтоб логи начали вестись.

установил: sudo apt-get install rsyslog -y.

Вылезла ошибка после установки:

Заново залогинился. auth.log пустой. И вначале указанные логи тоже пусты. Какие-то настройки с rsyslog надо делать?

что-то поломалось в апте, похоже.
df -h что говорит ?

apt-get update && apt-get install -f
может быть попробовать все пакеты привести в актуальное состояние
apt-get upgrade

Лол. Вот как раз с systemd проблем бы не было.

Это похоже хвалёный upstart/sysVinit рассыпался.

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

Ошибки появляются. Уже голова трещит. Может я раньше где-то накосячил. Короче, пришлось переустановить систему(Ubuntu 16.04). Сейчас с логами порядок. Всем спасибо

Видимо потому что срок поддержки этого дистрибутива был окончен (12.04 всё-таки вышла давно):

Тебе нужно было просто немного отредактировать файл /etc/apt/sources.list, как сказано здесь:

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

Добрый день. Я пытался найти способ связаться с вами на данном форуме но не нашел в профиле возможностей для связи поэтому пожалуйста не ругайтесь что пишу здесь. Я из ТМ и у меня такая же проблема как и у вас насчет блокировок и ограничения по скорости. Я думаю что знаю метод обхода и да он чисто китайский, как сокс прокси и он мне давал скорость большую + сейчас я через него сижу но скорости несколько дней уже как не дает не пойму в чем причина. Я мог бы озвучить название клиента который реально даже для андроид есть но в целях приватности лучше в личку. Напишите мне в телеграм AlexSparda, чтобы обсудить данный вопрос. Я сам все это знаю и даже пришел к этом чуть раньше чем вы в 2015 году, но может у вас есть еще скорость?

Читайте также: