systemd достал...

зачем их чистить?

я бы на тебя посмотрел, когда ты будешь искать, где кончается один большой дебаг и начинается второй... вместо того, чтобы просто сделать echo «» > /var/log/app.log

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

освой уже командную строку journalctl и не пори чушь

хинт: можно фильтровать логи по юниту и по времени

Да, на Bash можно даже игры писать и инструкции Амиго интерпретировать
Но это будет медленно работать и надо море говнокода, что бы работало

это размер портянки для обслуживания systemd

Другие люди как-то без таких портянок обходятся. Может, дело в тебе?

Не понял?
Ты не знал, как логи посмотреть - я подсказал
А чистить сам journald, точнее ротирует, потому что чистить не правильно
Но можно сделать rm -rf /var/log/journal

Ты не шуми так, сейчас научаться systemd пользоваться и пойдут еще ниже - ядро хейтить :-)

Можно из скрипта только вызывать, а написать хоть на ассемблере.

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

syslog. не знал?:)

хинт: можно фильтровать логи по юниту и по времени

фильтровать вобще можно грепом.%) тоже мне фича) а вот очистить по времени и по юниту нельзя:)

Ты не знал

я знал

я подсказал

спасибо, кэп!

потому что чистить не правильно

а ну да! конечно! если что-то нельзя сделать, то это потому что неправильно! мне не нужно удалять все логи, в т.ч. полезные. я привел просто пример echo «» > /var/log/app.log

Другие люди как-то без таких портянок обходятся. Может, дело в тебе?

некоторые вобще админять 3 сервера. некоторые тратят время и работают 5х8. я нет. может, дело во мне.

я тебя уверяю, что стандартный bash completion содержит такой же объем обмоток.

научаться

Научись русскому языку сначала.

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

А зачем тред создал, если знал?
Все нужные логи должны идти в хранилище логов

А что не так? Все правильно
Если что, ударение - научАться

А что не так? Все правильно

Особенно с учётом остальных слов в предложении.

Аргументы будут?

этот граммар-наци намекает на ться

Охренеть, для нормального пользования systemd нужно таскать с собой портянки на шелле.

систумд-фанбой доказывал что это все «слишком высокоуровневые функции чтоб пихать их в инит-скрипт».

Мой инит скрипт для апача:
#!/bin/sh
/usr/sbin/apachectl $1

- правда, проще systemd?

Остальное - проблемы тех долбодятлов, которые и systemd засрут костылями.

Ой, бывает
Но как это связано с systemd все не могу понять

Все нужные логи должны идти в хранилище логов

...а все настройки в хранилище настроек, реестре... удивительно, но некоторые systemd фанбои еще уверяют, что нет никакой разницы хранить в текстовом или бинарном виде. потом приводишь им пример импотенции, и они сразу сдуваются со словами: «а зачем это делать?» да потому что это делали последние 20 лет! уже сколько примеров того, что весь этот новый комбайн не может того, что делала старая система.

А зачем тред создал, если знал?

внезапно «systemd достал».

Причем тут настройки?
Представь себе, Linux больше направлен на сервера, чем на десктоп
И да, есть такая штука, etcd называется, для настроек
Достал - не пользуйся

Представь себе, Linux больше направлен на сервера, чем на десктоп

Я это тоже всегда повторяю. Линукс - да, для серверов и мобильных девайсов. А systemd?

есть такая штука, etcd

мало ли что есть. Gentoo вон есть. это же не мейнстрим. если ты начнешь подсчитывать плюсы systemd, то станет ясно, что они в последнюю очередь для серверных систем.

хейтеры хейтеров системд уже не знаю, чем аргументировать ответы

Systemd создан в первую очередь для упрощения администрирования серверов

Причем тут генту?
Ты зачем то написал про хранилище настроек, я указал тебе о etcd
Погугли etcd, узнаешь, какая полезная штука

для упрощения администрирования серверов

а напомни мне по пунктам, что стало проще?

Ты зачем то написал про хранилище настроек, я указал тебе о etcd
Погугли etcd, узнаешь, какая полезная штука

Полезная для определенного случая. Ее не включили во все дистры по умолчанию, потому что она не будет такой полезной в общем случае. Текстовые файлы выходят полезнее. Поэтому твой пример ни о чем. Точно также ты не можешь сказать «не используй systemd», потому что реально выбора нет.

Чем это зоопарк разношёрстных systemd-юнитов лучше зоопарка разношёрстных init-скриптов?

Тем что они стандартизированы хоть как-то в отличии от.

Но с тем что описал ТС я согласен полностью. Раздражает когда даже результат не выводится и приходится сразу после start еще и status вызывать.

Меньше секса с ротацией логов, много автоматизации, лучшее управление ресурсами, улучшения для кластеризации

Используй генту
Всякие Fedora, Ubuntu, SUSE и т.д. - дистрибутивы общего назначения, т.е. сервера, облака, десктоп
И там по умолчанию systemd, что бы было проще поддерживать
Ну и с systemd с SSD грузится реально быстро

systemctl stop/start httpd.service - не выдает ничего. не понятно, была реальная остановка сервиса или он уже был выключен или запущен!:(

Раздражает когда даже результат не выводится и приходится сразу после start еще и status вызывать.

ЧЯДНТ?

root@redmine:/etc/apache2# systemctl stop apache2.service 
root@redmine:/etc/apache2# systemctl start apache2.service 
root@redmine:/etc/apache2# systemctl restart apache2.service 

root@redmine:/etc/apache2# mv apache2.conf apache2.conf.moved
root@redmine:/etc/apache2# systemctl restart apache2.service 
Job for apache2.service failed because the control process exited with error code. See "systemctl status apache2.service" and "journalctl -xe" for details.
root@redmine:/etc/apache2# systemctl start apache2.service
Job for apache2.service failed because the control process exited with error code. See "systemctl status apache2.service" and "journalctl -xe" for details.

root@redmine:/etc/apache2# mv apache2.conf.moved apache2.conf
root@redmine:/etc/apache2# systemctl start apache2.service
root@redmine:/etc/apache2#

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

Ещё с десяток сервисов могу «уронить». Только смысл портянку в комментарий пихать? Оно работает.

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

Что ты тут делаешь? Ставь Windows. Unix way — отсутствие вывода в stdout, если команда отработала корректно.

Ты сказал запустить сервис? Компьютер его запустил. Что ещё тебе нужно?

Unix way — отсутствие вывода в stdout, если команда отработала корректно.

OpenRC(разве он не unixway?) насколько помню сообщал ок или фэйл. Вот хотелось бы похожего поведения. Это адекватное\ожидаемое поведение.

ЧЯДНТ?

читать полностью не читаешь.

OpenRC не умеет перезапускать сервис, емнип. Даже если rc-service и делает что-то, кроме

/etc/init.d/<service> star

И да, то что он срёт в консоль своё «OK» - это не unix way.

1. Меньше секса с ротацией логов

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

2. много автоматизации

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

3. лучшее управление ресурсами

дада, cgroups. только зашли в реализации так далеко, что теперь придется переделывать tmux и screen. а удаление хвостов по окончании сессии говорит о заточке под десктопы.

4. улучшения для кластеризации

?

Ты про это?

Зачем это длинное поле Support? Какой в нем смысл? Что, рыжий парень готов решать мои проблемы? Нет, не готов. Больше сообщений о статусе самого systemd, чем о работе апача... «Starting The Apache HTTP Server...» - единственная строчка по теме. Хоть бы статус в итоге написали, что сервис стартовал в итоге.

Научись уже journalctl -q

systemd достал... (комментарий)

По дате и времени.

$ journalctl | grep apache

Aug 31 20:37:33 redmine apache2[30997]:  * Stopping Apache httpd web server apache2
Aug 31 20:37:35 redmine apache2[31025]:  * Starting Apache httpd web server apache2
Aug 31 20:37:47 redmine apache2[31177]:  * Stopping Apache httpd web server apache2
Aug 31 20:37:48 redmine apache2[31206]:  * Starting Apache httpd web server apache2
Aug 31 20:39:18 redmine apache2[31386]:  * Stopping Apache httpd web server apache2
Aug 31 20:39:19 redmine apache2[31415]:  * Starting Apache httpd web server apache2
Aug 31 20:39:39 redmine apache2[31558]:  * Stopping Apache httpd web server apache2
Aug 31 20:39:39 redmine apache2[31558]:  * The apache2 configtest failed, so we are trying to kill it manually. This is almost certainly suboptimal, so please make sure your system is working as you'd expect now!
Aug 31 20:39:39 redmine apache2[31585]:  * Starting Apache httpd web server apache2
Aug 31 20:39:39 redmine apache2[31585]:  * The apache2 configtest failed.
Aug 31 20:39:39 redmine apache2[31585]: Output of config test was:
Aug 31 20:39:39 redmine apache2[31585]: apache2: Could not open configuration file /etc/apache2/apache2.conf: No such file or directory
Aug 31 20:39:39 redmine apache2[31585]: Action 'configtest' failed.
Aug 31 20:39:39 redmine apache2[31585]: The Apache error log may have more information.
Aug 31 20:39:39 redmine systemd[1]: apache2.service: Control process exited, code=exited status=1
Aug 31 20:39:39 redmine systemd[1]: apache2.service: Unit entered failed state.
Aug 31 20:39:39 redmine systemd[1]: apache2.service: Failed with result 'exit-code'.
Aug 31 20:39:53 redmine apache2[31613]:  * Starting Apache httpd web server apache2
Aug 31 20:40:41 redmine apache2[31820]:  * Stopping Apache httpd web server apache2
Aug 31 20:40:46 redmine apache2[31853]:  * Starting Apache httpd web server apache2
Aug 31 20:40:52 redmine apache2[31989]:  * Stopping Apache httpd web server apache2
Aug 31 20:40:53 redmine apache2[32018]:  * Starting Apache httpd web server apache2
Aug 31 20:41:08 redmine apache2[32162]:  * Stopping Apache httpd web server apache2

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

Если systemctl start %service% успешно запустил этот %service%, то (как и с другими командами) ты увидишь приглашение твоего шелла. Если что-то пошло не так, то тебе покажут сообщение об ошибке.
Посмотреть когда упал\поднялся сервис в логах можно.

Или cp, mv, cd и т.п. должны отвечать «copied OK», «moved OK», «directory changed OK»?

cp, mv и cd могут работать c -v и --interactive. есть гибкость. с systemd нет гибкости.

sc restart nginx.service

сколько раз был остановлен nginx? 0 или 1? была остановка сервиса или нет? а! надо journal смотреть!

Посмотреть когда упал\поднялся сервис в логах можно.

ок, сравни

Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
# echo '-x покажет как раз тот блоат, на который я жалуюсь в топике!'
# jo -u nginx -n 10
-- Logs begin at Mon 2016-05-09 08:23:29 EDT, end at Thu 2016-09-01 03:42:03 EDT. --
Aug 29 07:39:32 somehost systemd[1]: Stopping The nginx HTTP and reverse proxy server...
Aug 29 07:39:32 somehost systemd[1]: Stopped The nginx HTTP and reverse proxy server.
Sep 01 03:35:12 somehost systemd[1]: Stopped The nginx HTTP and reverse proxy server.
Sep 01 03:35:17 somehost systemd[1]: Starting The nginx HTTP and reverse proxy server...
Sep 01 03:35:17 somehost nginx[20667]: nginx: [emerg] unknown directive "server" in /etc/nginx/nginx.conf:15
Sep 01 03:35:17 somehost nginx[20667]: nginx: configuration file /etc/nginx/nginx.conf test failed
Sep 01 03:35:17 somehost systemd[1]: nginx.service: control process exited, code=exited status=1
Sep 01 03:35:17 somehost systemd[1]: Failed to start The nginx HTTP and reverse proxy server.
Sep 01 03:35:17 somehost systemd[1]: Unit nginx.service entered failed state.
Sep 01 03:35:17 somehost systemd[1]: nginx.service failed.

и традиционный вариант:

/etc/init.d/nginx restart
nginx: [emerg] unknown directive "sd" in /etc/nginx/nginx.conf:29
nginx: configuration file /etc/nginx/nginx.conf test failed

в каком случае быстрее находим ошибку?

По дате и времени.

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

...и засовывание функционала этих традиционных утилит в journalctl в виде ключей (-n, -f...) ситуацию маскирует, но не меняет.

даже по твоему сообщению видно,

Это потому что мне лень запомнить man journalctl

засовывание функционала этих традиционных утилит в journalctl ситуацию маскирует, но не меняет.

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

в каком случае быстрее находим ошибку?

На кой в нормальной ситуации я буду руками лог смотреть? В крайнем случае система мониторинга от journalctl в json данные возьмёт и мне наглядно покажет.

Это потому что мне лень запомнить man journalctl

То есть человек, который не осилил man, предлагает мне выше «научиться»?:) ну-ну.

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

то есть, когда хостов много, нужно больше печатать и journalctl помогает сэкономить время и силы?)

На кой в нормальной ситуации я буду руками лог смотреть?

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

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

Что конкретно за система? Сколько раз в минуту она «забирает» логи с хоста?

То есть человек, который не осилил man, предлагает мне выше «научиться»?:) ну-ну.

Не помню все параметры наизусть, так и не ною из-за этого. Будет мешать жизни — гляну ман. 2-3 раза гляну — запомню, а кто-то всё ещё ныть будет.

то есть, когда хостов много, нужно больше печатать и journalctl помогает сэкономить время и силы?)

Когда хостов много, настраивают оркестрацию и мониторинг.

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

Когда %что-то% настраивают, пользуются journalctl -leu %что-то% и смотрят лог конкретного сервиса, а не жалуются, что вместо команд a, b и c нужно запомнить несколько параметров у d

Что конкретно за система? Сколько раз в минуту она «забирает» логи с хоста?

Это как-то повлияет на работу journalctl? Какая угодно: хоть Zabbix, хоть самописные костыли.
Один фиг *.log тебе\автору мониторинга парсить придётся, а journalctl данные сразу в удобном для обработки формате предоставит.

Не помню все параметры наизусть

ну так и не умничай:)

Когда хостов много, настраивают оркестрацию и мониторинг.

а тогда какая связь с параметрами -n/-f journalctl, если набираешь всеравно один раз для оркестрации? выгоды-то нет:)

пользуются journalctl -leu %что-то% и смотрят лог конкретного сервиса

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

Это как-то повлияет на работу journalctl? Какая угодно: хоть Zabbix, хоть самописные костыли.

Нет, но я думал, ты знаешь что-то, чего не знаю я.:) Система мониторинга (тем более с костылями) вообще не заменяет систему хранения и обработки логов, если ты не в курсе.:) Уже тот факт, что ты их путаешь, о многом говорит.:) Многостраничные портянки с дебагом ты тоже в заббиксе смотреть будешь что ли?:) Нет, пойдешь и как миленький будет запускать ручками journalctl, читать маны и думать, как удобно работать с многомегабайтным файлом, где уже несколько огромных портянок. Потом плюнешь и найдешь самый неудачный способ отфильтровать логи, вместо простого echo «» > /var/log/app.log