Tapi yakinkan dulu, karena konsekuensi mengubah konfigurasi storage #systemd #journald ke volatile adalah log tidak akan tersedia setelah reboot ketika terjadi crash.

Sesuaikan dengan kebutuhan masing-masing ya.

Pengalaman menjalankan banyak #VM ataupun #container (nested di vm ataupun langsung di baremetal) dalam satu baremetal, biasanya bukan kejedot sama kapasitas prosesor.

Mungkin kejedot oleh kapasitas RAM, tapi RAM mudah ditambah (walau sekarang harga RAM lagi edan).

Tp seringkali kejedot #iorate, apalagi jika storage nya backed by #hdd.

Salah satu trik mengurangi io-rate adalah dengan mengubah konfigurasi storage #systemd #journald ke "volatile".

I want a log viewer* which can summarise log lines so I can group the similar ones. Either like take the entropy of each into account and either redact that out or otherwise pattern match them.

Example of some lines which my crude: remove the time, sort | uniq -c | sort -nr | head will still see as unique.
```
time="2025-08-09T20:54:16Z" level=info msg="COMPACT compacted from 264962072 to 264962627 in 1 transactions over 22ms"
time="2025-08-09T20:59:16Z" level=info msg="COMPACT compacted from 264962627 to 264963177 in 1 transactions over 57ms"
```

For each format it is possible to come up with a rule to "group" things, I guess that's basically what people use LogStash for. However I don't care to maintain such things for whatever software I install on my system.

Know of such a tool? Am I barking up the wrong tree?

*linux, cli, maybe journald support as these are system logs

#linux #journald

Oh adding these TTY options into the sddm.service didn't work because it the parent process blocks the sddm-helper child process. It does not appear to be within that services cgroup.

I think, it lives too short to actually have a closer look at it. All I can tell is when it fails to access the tty it writes an error into #journald, but in a way that it doesn't show up when filtering for the sddm.service unit specifically the other sddm-helper processes do...

Сбор событий Linux: есть цель – ищем путь

Приветствую всех, кто заглянул на огонек! Меня зовут Роман, и я занимаюсь исследованием безопасности Linux (и всякого другого, связанного с ним) в экспертном центре безопасности в Positive Technologies. Мне периодически приходится сталкиваться с вопросами клиентов или коллег из смежных отделов по поводу оптимизации работы различных компонентов журналирования внутри Linux. Поэтому в какой-то момент возникла идея обрисовать как минимум для самого себя целостную картину их взаимодействия и влияния друг на друга. Результатом работы стала довольно компактная схема, которая помогает оперативнее и эффективнее отвечать на возникающие вопросы для решения проблем. В статье я постараюсь вкратце описать каждый ее блок. Не ручаюсь за то, что будут затронуты все тонкости, известные лишь узкому кругу специалистов. Но на большую часть вопросов я отвечу.

https://habr.com/ru/companies/pt/articles/925894/

#linux #siem #auditd #syslog #journald #администрирование_linuxсистем

Не знал что так можно:

sudo systemctl start systemd-journal-gatewayd.{socket,service}

curl -s http://127.0.0.1:19531/entries

curl -s "http://127.0.0.1:19531/entries?UNIT=sshd.service"

curl -s -H "Accept: application/json" "http://127.0.0.1:19531/entries?UNIT=sshd.service"

А ещё там есть вебморда по пути /browse.

#systemd #http #web #logs #journald

UPD: работает шустрее чем Filebeat, FluentBit, FluentD и syslog-ng и не грузит систему излишне, вопрос только чем пушить, но это вопрос решаемый.

lazyjournal — ленивый интерфейс для поиска и анализа логов

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

https://habr.com/ru/articles/899750/

#сезон_open_source #golang #tui #journalctl #journald #auditd #docker #логи #мониторинг

LXC теряли память и падали. И при чем же здесь tmpfs и journald?

Старый добрый Proxmox с его контейнерами и виртуалками - по-прежнему рабочая лошадка многих компаний. И если нарезать много-много мелких контейнеров, то может случиться, что память куда-то девается со временем, а контейнеры падают в OOM без очевидной причины. Причем не все. Причем иногда. И зачастую проще перезапустить и ехать дальше чем разбираться. А причина есть, и она оказалось довольно проста.

https://habr.com/ru/articles/883562/

#proxmox #lxc #tmpfs #journald #oom #oom_killer #systemd

Простой и универсальный способ чтения логов в терминале

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

https://habr.com/ru/articles/872536/

#логи #логирование #мониторинг #journald #journalctl #docker #podman

TIL - from journalctl(1):

> It is also possible to filter the entries by specifying an absolute file path as an argument. [...] If a file path refers to a device node, "_KERNEL_DEVICE=" matches for the kernel name of the device and for each of its ancestor devices is added to the query.

Try `sudo journalctl /dev/input/mouse0`, pretty cool!

#systemd #journald #journalctl #linux

If I have several servers sending their logs to a central server with systemd-journal-upload, what options are there to forward a copy also to a third-party service that only accepts syslog? Should I just have a service on the central server run "journalctl -f -m" and have its output go to syslog? Would like to keep things simple. #systemd #journald

I used to hate the switch to journald, but, when you actually make use of its controls, it can be easier than massaging the wholly text-based files that (r)syslog spits out. This morning, I was adding DNS records to make it easier for me to relay my MTA's messages through AWS's SES. Didn't want to find that mail had stopped working because of a botch in the formatting of content I'd added to my zone files, so:

journalctl --no-pager --since "2024-09-11 15:20:30" -u named _PID=5080

@shuLhan @cazabon Well, based on my experiences with #journald as a #syslog_ng guy, my expectation is that around 5-10 years of security nightmares are about to come with #run0:

https://www.syslog-ng.com/community/b/blog/posts/systemd-journald-vs-syslog-ng

Yes, a decade later after journald arrived, I have no problem recommending it. But the first 7-8 years were catastrophic both for users and developers.

Библия systemD: как управлять системой

Что бы кто не говорил, systemD остается стандартом систем инициализацией в линуксе. И с 100% вероятностью все сервера будут с systemD. И поэтому знать как работать с данной системой инициализации должен знать каждый сисадмин и просто программист. В этой статье мы разберем создание сервисов и юнитов, как облегчить работу при помощи systemd, отслеживать состояние системы и управлять системой.

https://habr.com/ru/articles/817701/

#linux #ядро #systemd #systemctl #journald #journalctl #администрирование_linuxсистем #администрирование #система_инициализации #pid_1 #sysvinit #runit #dinit

PLEASE - Dont invent your own #logging scheme or log to random files ANYWHERE in the filesystem.

There is a #Unix service called #syslog and THAT is the destination for your logging. It even got a LOT better with #journald so stop logging in random places in the filesystem.

Today - #Mosquitto filling up the disk because clients having the same name.

And when configuring "syslog" as per documentation your get this:

"mosquitto[2646497]: 1717052051: Error: Unable to open log file syslog for writing."

@hagedose68 Well done! Especially #journald is tricky sometimes.

I have successfully debugged a configuration issue on all of our #RHEL8 #Linux servers involving #rsyslog and #journald, and now I feel I've done enough for the day.

apt-get remove rsyslog #journald