openbsd 6.5 released

ip вышел в нулевых, йопт.

syslog backend в journald вроде тоже никто добавлять не собирается.

А давай ты уже перестанешь писать глупости в топик? JOURNALD умеет релеить сообщения в сислог, поэтому в центоси у меня тексиовые логи.

Если ты хочешь раутер и свежий nginx, то openbsd тебе подойдет. У меня дома он служит шлюзом и впном с почтой.

Найди мне, пожалуйта, lsblk в openbsd.

OK, сразу после того, как ты мне любезно укажешь место, в котором я утверждаю, что данная утилита в составе OpenBSD есть. ;)

Я задал уточняющий вопрос именно для того, чтобы понять о какого рода «просмотре дисков» ты говоришь. FYI, disklabel(8) делает почти тоже и даже больше, но не глобально, а для отдельного устройства.

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

Ну... типа какие диски в системе есть :)

Чаще всего мне это интересно, когда у меня корзина дисков на 48 и мне нужно понять, все мы там сигейты определенной партии уже поменяли, или ещё чего-то осталось. Ну или посмотреть, что там по SCSI подхватилось из сети (nvmeof пока нет, но когда будет, это тоже будет интересно).

FYI, disklabel(8) делает почти тоже и даже больше, но не глобально, а для отдельного устройства.

disklabel показывает disklabel. Что не удивительно. А я просто список дисков хочу увидеть. Все осложняется тем, что у openbsd до сих пор статический /dev, поэтому наличие device node ничего не говорит о том, есть ли за ним реальный диск. У них конечно есть для этого sysctl, но блин.

А как же sysctl?

ssh2@balamut:~$ sysctl hw.disknames
hw.disknames=sd0:23b7f8d00a8db49d,sd1:1536b54003c41ac5

Upd: что-то я не увидел твоей последней реплики про sysctl, ну или она позже появилась, чем я отвечать начал. :D

Да, это замена линуксовому ls -l /dev/sd*. Но на практике мне интересен транспорт, модель, серийник, размер и WWN.

Но на практике мне интересен транспорт, модель, серийник, размер и WWN.

Прямо идея для пет-проджекта. Выгребать устройства посредством sysctl, опрашивать их посредством disklabel и выводить согласно набору ключей. :\

Прямо идея для пет-проджекта. Выгребать устройства посредством sysctl, опрашивать их посредством disklabel и выводить согласно набору ключей. :\

В OpenBSD давно напрашивается sysctl типа hw.tree.<type>.<device> с выводом в виде таблицы. Но поскольку никто в здравом уме не использует openbsd для хранения хоть чего-то важного (потому что FS теряет файлы, а блочная подсистема медленная шоппц), то и тулза особо не нужна.

Согласен, задумчивая она пц. На рабочем лэптопе Опёнок с первого дня живёт на ssd, и производительностью никогда не пугал, но и файлов я не терял ни разу.

Впрочем, мб выборка не репризентативна, всего пара хостов.

Согласен, задумчивая она пц. На рабочем лэптопе Опёнок с первого дня живёт на ssd, и производительностью никогда не пугал

Не, для досктопа и роутера у неё вполне мощностей хватает. Но вот какой-нибудь postgres поверх SSD уже вызывает проблемы из-за так и не выпиленного BKL. Подвижки есть, но в 2k19 это уже выглядит странно.

но и файлов я не терял ни разу

Месяца три назад у меня вывалился кабель из раутера. В итоге, ядро оказалось битым, а lost+found пополнился частью *.o файлов из /usr/share/relink/чего-то-там.

Месяца три назад у меня вывалился кабель из раутера. В итоге, ядро оказалось битым, а lost+found пополнился частью *.o файлов из /usr/share/relink/чего-то-там.

А, теперь понял о каких случаях повреждения fs речь, сталкивался, но без особых последствий. В основном, когда какие-нибудь злодеи отключали БП от док-станции или сам забыл включить его в розетку. :) Потом стал более сосредоточенным оброс скриптами для sensorsd. ;)

А, теперь понял о каких случаях повреждения fs речь, сталкивался, но без особых последствий. В основном, когда какие-нибудь злодеи отключали БП от док-станции или сам забыл включить его в розетку. :) Потом стал более сосредоточенным оброс скриптами для sensorsd. ;)

Ну как бы и вот. В лялехе я такого не видел с момента глупых багов в XFS, которые ногами в 80-е уходят.

Я старовер на своих Линуксах использую ext4, как-то так повелось. За исключением домашнего NAS построенного на HP MicroServer c CentOS, но и там xfs только для системы.

Я старовер на своих Линуксах использую ext4, как-то так повелось. За исключением домашнего NAS построенного на HP MicroServer c CentOS, но и там xfs только для системы.

Да я тоже, но с ext4 такого в принципе никогда не случалось. А вот XFS «радовал» вплоть до 2014-го вроде.

Меня XFS радует до сих пор. ext4, к сожалению, почему-то тормозной.

XFS ok, но до какого-то момента без бекапа было опасно.

syslog backend в journald вроде тоже никто добавлять не собирается.
А давай ты уже перестанешь писать глупости в топик? JOURNALD умеет релеить

Ты русский язык плохо читаешь, умник? Это не то же самое. Именно, что релеить через сокет другому софту. А самостоятельно передавать не может.

Что он не может? Сохранять текстовые логи в текстовые логи? Зачем?

turtle_bazon, ssh2 XFS чуть-чуть более прогрессивная по дизайну и ее потенциал масштабироваться под многопоточностью выше. соотвественно, после того, как RH ее сделал базовой (RHEL6, кажется) она стала достойным выбором.

другое дело, что туповатый systemd (а точнее ее разработчик) вшил вызов system(fsck) в сишный код без осознания, что fsck.xfs не чинит автоматически fs. я уже не помню подробностей, но systemd+xfs просто не могли починиться после подения на RHEL7 в самом его начале.

xfs за счет заморозки состояния хорошо вяжется с lvm snapshots.

а вообще и ext4, и xfs - это уже отчасти устаревашие фс. нет гарантий от bitrot для больших помоек.

проверял вчера ночью, как там ZFS поживает, на freebsd - отсутсвует интеграция кеша новомодной фс и vm подсистемы linux/freebsd. короче, куда не кинь ограничения и недоделки.

zfs на солярис, видимо, самое мощное решение.

Что он не может?

рад, что ты спросил вместо обвинений в тупости (или это еще впереди?).

Сохранять текстовые логи в текстовые логи? Зачем?

ты знаешь, что syslog - это не текстовые логи вообще-то? syslog - это RFC 5424, протокол удаленной передачи логов? теперь смотри.

есть такая классическая ситуация... ну допустим ISP, домашние сеточки (в одной такой я работал), там линуксов штук 20-30 (на самом деле не знаю точно, сколько в других отделах), а сетевого оборудования ... черт, я уже не помню... ну пара тысяч умных свичей на город, допустим. и они все могут сливать логи по syslog в одно какое-то место. общий коллектор логов.

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

для интеграции линуксов теперь надо настраивать вот это самое проксирование логов в rsyslog. journald пока разберется со своими структурами и ring buffer всеравно создаст нагрузку на сервер. если это нагруженный сервер, где много логов, он создаст большую нагрузку. молись, чтобы при этом не надо было сохраняться вот этим самые нетекстовые логи локально, ибо journald by design более тормозной (делал минитесты. он раза в три более тормозной), чем любой писатель текстовых логов. особенно rsyslog, который уже больше десятилетия задрачивают на перфоманс в таких ситуациях.

в принципе, я не против, если ты прочитаешь вышесказанное и решишь меня обо*рать. мол, «не надо», «не будет» и прочее.

после переписки с alpha, которая как бы разрабатывает базовую систему в RedHat и которая считает, что проксирование вполне заменяет syslog бекэнд (и, очевидно, даже не представляет ситуации с ISP), вы меня можете просто пристрелить, чтоб я не мучался. мне просто не понятно, почему, реализуя крон, ntp, dhcp, systemd не реализует прямую передачу логов по syslog протоколу.

ты знаешь, что syslog - это не текстовые логи вообще-то? syslog - это RFC 5424, протокол удаленной передачи логов? теперь смотри.

Знаю. Более того — не только (и не столько) этот. Потом что legacy syslog все ещё более активно используется (в том числе той же openbsd).

есть такая классическая ситуация... ну допустим ISP, домашние сеточки (в одной такой я работал), там линуксов штук 20-30 (на самом деле не знаю точно, сколько в других отделах), а сетевого оборудования ... черт, я уже не помню... ну пара тысяч умных свичей на город, допустим. и они все могут сливать логи по syslog в одно какое-то место. общий коллектор логов.

Я так на работе делаю.

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

Никто этого и не утверждал.

для интеграции линуксов теперь надо настраивать вот это самое проксирование логов в rsyslog. journald пока разберется со своими структурами и ring buffer всеравно создаст нагрузку на сервер. если это нагруженный сервер, где много логов, он создаст большую нагрузку. молись, чтобы при этом не надо было сохраняться вот этим самые нетекстовые логи локально, ибо journald by design более тормозной (делал минитесты. он раза в три более тормозной), чем любой писатель текстовых логов. особенно rsyslog, который уже больше десятилетия задрачивают на перфоманс в таких ситуациях.

Кхм... во-первых, я знаю, какой rsyslogd быстрый (нет, не такой быстрый, как хотелось бы), потому что в начале года я чинил потери логов на нашем централизированном лог-хранилище. Во-вторых, в моей конторе мы шлем ВСЕ логи со ВСЕХ наших серверов (несколько сотен штук). И это не умные свичи, это фронты, которые фигачат 24/7. И нет, journald <-> rsyslogd даже не в top5 потребителей ресурсов.

На bitrot пофиг, за это отвечает рейд.

ну вот видишь как, ты отлично знаешь, о чем речь.

И нет, journald <-> rsyslogd даже не в top5 потребителей ресурсов.

просто мощное железо прикрывает плохой дизайн. ничего из твоего ответа не отменяет факта, что нативный syslog в journald нужен.

во-вторых, очевидно, у вас journald не пишет логи локально. то есть логи локально вы вообще не храните. а если девелоперам надо смотреть логи и у них нет доступа до коллектора? хватает ring buffer?

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

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

ок, fair enough. НО он, мл*, всеравно в три раза быстрее, чем структурированные логи journald! если бы ты начала писать эти самые структурированные логи, то он бы и проксировал с потерями в три раза выше!

journald <-> rsyslogd даже не в top5

все бы хорошо, если бы у меня у самого journald как-то не взлетел в топ ни с того, ни с сего. а интернет не был бы завален вот такими вот постами:

https://askubuntu.com/questions/1010078/17-10-100-cpu-load-almost-all-the-time

p.s.

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

и последнее. вы ведь в вашем коллекторе логи не храните в journald? вы структурируете их чем-то другим?

Железо не такое уж и мощное, а локально логи пишет тот же rsyslog, проосто время жизни другое.

И нет, journald <-> rsyslogd даже не в top5 потребителей ресурсов.

чуть не забыл. основная масса логов точно генерируется через native journald api? или все-таки у вас nginxы, которые используют syslog интерфейс? тогда логи поступают сразу в rsyslog и уже оттуда забираются journald. тогда да, нагрузки на него почти нет. я проверял.

кстати я думаю не выложить ли эти тестики для обсуждения отдельной темой.

а локально логи пишет тот же rsyslog, проосто время жизни другое.

ну и славно!) сам ответил на свой вопрос:

Сохранять текстовые логи в текстовые логи? Зачем?

Я бы спросил, нафига тогда journald. Чтобы избавиться от grep что ли...

А какой рейд?

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

да не суть. ты мне лучше вот на это ответь:

openbsd 6.5 released (комментарий)

ты уверен, что у вас логи именно проксируются через journald (отправлены нативно), а не выгребаются жорналд уже после, асинхронно, в то время, как rsyslog их там отправляет?

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

Nginx'ы пишут в /dev/log, который выгребается journald и релеится в rsyslogd.

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

«Его вообще можно было бы убрать, но это рхел.»

Nginx'ы пишут в /dev/log, который выгребается journald и релеится в rsyslogd.

/dev/log создается rsyslogd. это его native interface. systemd использует вместо него какой-то свой сокет в системе. можно сказать, что у вас наоборот rsyslog служит релеем для journald, который вам вообще не нужен, но удалить нельзя.

/dev/log создается rsyslogd. это его native interface. systemd использует вместо него какой-то свой сокет в системе. можно сказать, что у вас наоборот rsyslog служит релеем для journald, который вам вообще не нужен, но удалить нельзя.

Не совсем, /dev/log создается модулем imuxsock, вроде так он называется. Но в RHEL этот файл создается самим journald.

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

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

Ну вот смотри:

# sleep 5s && logger 'journald sucks :('
# strace -yfp $(pgrep journal) -s 200 -e trace=recvmsg
recvmsg(5<socket:[17443]>, {msg_name(0)=0x7ffcb4347f10, msg_iov(1)=[{"<13>Apr 28 10:48:20 root: journald sucks :(", 24575}], msg_controllen=64, [{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */}, {cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=32078, uid=0, gid=0}}], msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 49
# lsof | grep '17443'
systemd       1             root   29u     unix 0xffffa056fdb53400       0t0      17443 /dev/log
systemd-j  4880             root    5u     unix 0xffffa056fdb53400       0t0      17443 /dev/log

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

Я посмотрю, конечно, но он вроде дефолтный.

там по умолчанию ForwardToSyslog=no т.е. он через себя логи не прокачивает.

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

а по поводу стрейс - ну просто зацепился за девайс и слушает. не так важно, кто его создал, но факт в том, что логи туда попадают в формате syslog, а потом забираются и rsyslog, и journald.

Пажжи, пажжи, пажжи. Сокеты так не работают. Один создает, второй коннектится. Коннектов может быть много, но они все изолированны друг от друга. Один пир не может послать другому пиру сообщение, иначе dbus был бы не нужен.

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

Опять же нет, потому что journald там на epoll'е висит.

Я вот хочу ZOL посмотреть. Пока руки не дошли. Пока пользуюсь XFS. На Debian. Иногда, где уже ext4 установлена и что-то очень лениво всё переделывать, пользуется. Но с xfs заметны какие-то подтормаживания и прочая ерунда. Особенно под нагрузкой.

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