Ты на калькуляторе что ли иксы запускаешь?

Ваганыч, перелогинься!

Ну а это вообще круто.

systemctl-cat, systemctl-edit: cat the config file of the unit you specify, so you don't need to know the path on the system (ie: systemctl-cat apache2.service). The systemctl-edit apache2.service immediately opens the unit file to edit. After a save, the service can get reloaded automatically.

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

И?

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

«can» =\= «will be»

Понятно, что я найду где эти файлы, и поправлю, по at сделаю релоад.

Но какой кейс решает reloaded automatically Человек который до этого додумался хоть раз в жизни что-нибудь кроме localhost администрировал?

«can» =\= «will be»

Понятно, дополнительная настройка, либо ключ. А зачем? И вопрос: какое поведение по умолчанию?

Твой божественный линукс - всего лишь пускалка для оракла и прочей в меру мерзкой проприетарщины. То, что админы локалхоста дрочат на свой линукс через cli, волнует 0,00000000% вменяемых мужиков. Если на линуксе не будет запускаться оракл, то линукс будет нужен никому и 3,5 идиотам.

Но какой кейс решает reloaded automatically Человек который до этого додумался хоть раз в жизни что-нибудь кроме localhost администрировал?

Отладка .service файла?

Судя по мониторингу в это время происходит что то странное
что то странное

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

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

За несколько дней? Зачем? Смотришь за тот день, когда было «странное», нафига за все-то дни?

который кстати гораздо проще в использовании

Что? Напиши мне grep-аналог journalctl -p err --since 1:00 --until 1:30 , полюбуемся, насколько он проще.

отработает быстрее

У меня ни разу ни один запрос к journalctl больше секунды не занял. Писать регулярки в сотни раз дольше.

Busybox появился в ответ на ограниченность ресурсов встраиваемых систем. Там ему самое место. Это совсем не Unix-way и повозглашать подобный подход основным направлением развития - плохая идея. И от вязанки шелл-скриптов она не спасает. Просто эта вязанка будет забита в коде systemd, и посмотреть/пофиксать её уже так просто не получится.

Какая буква в слове LAMP означает Oracle?

:! systemctl reload service

против :w

ну да, наверно 20 символов разницы стоят дополнительного кода

ntpd слишком тяжёл. Это как BIND vs dnsmasq vs systemd-resolved: первое — полновесный рекурсивный DNS-сервер (который, в частности, может кэшировать), второе — специализированный кэширующий DNS-сервер, а третье — кэширующий NSS-модуль, который интегрируется в glibc и позволяет целиком избежать прослойки в виде второго DNS-сервера.

Соответственно, systemd-timesyncd, в отличие от ntpd, реализует лишь функциональность NTP-клиента (именно она нужна на подавляющем большинстве машин).

То есть ntpd и bind тяжелые по-твоему? А то что пхать все внутрь systemd, не делает сам systemd тяжелым? У вас проблема с логикой мусьё

пффф, я его поделками не пользуюсь а у меня все работает, «что я делаю так»?

Тебе может быть оно и не нужно. А другим нужно. Без таких разработок как systemd и pulsaudio Linux не сможет стать юзерфрендли и конкурировать с Windows, это понимает любой адекватный человек. Именно поэтому уже во все основные дистрибутивы добавили systemd, без systemd осталось только несколько маргинальных дистрибутивов.

30 минут, вывод выше.

grep -e '\ 01:[0-3]' logname

А в чем проблема то?

Без таких разработок как systemd и pulsaudio Linux не сможет стать юзерфрендли и конкурировать с Windows, это понимает любой адекватный человек.

скажу честно, я не поклоник ковыряться в скриптах sysv, и в конфиги alsa не заглядывал ни разу, но тем не менее. Работает все, что нужно. На кой ляд мне юзер-френдли штук, с которыми я не скалкиваюсь?? И зачем это рядовому хомячку? Поставил систему, и не дергайся. Тут, правда, зависит от системы... Но так праволавный Debian-stable вполне всех устроит.

ну и пример из реальной жизни.

 
~ -$ time grep -e '\ 01:[0-3]' log > result                                                                                                 limbo@chemist :(
grep --color=auto -e '\ 01:[0-3]' log > result  1,55s user 0,80s system 99% cpu 2,362 total
 ~ -$ wc -l log                                                                                                                              limbo@chemist :)
5835420 log
 ~ -$ wc -l result                                                                                                                           limbo@chemist :)
13260 result
 ~ -$ ls -lh log                                                                                                                             limbo@chemist :)
-rw-r--r-- 1 chemist chemist 775M фев  3 22:42 log

2 секунды на почти гигабайтном логе, ЧЯНТД?

grep -e '\ 01:[0-3]' logname

А в чем проблема то?

В том, что твое решение настолько убого, насколько оно вообще может быть убогим.

К примеру ты захватишь так-же секунды. 12:01:00

Ты не захватишь логи, которые пишут таймстампы.
[ 200.234] (II) XKB: reuse xkmfile /var/lib/xkb/server-7032B4551640DA4894D7FAC3A509B690128BA4B9.xkm

Ты не отфильтруешь разные дни.

К примеру ты захватишь так-же секунды. 12:01:00

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

То есть ntpd и bind тяжелые по-твоему?

Безусловно, особенно в настройке. На десктопе это не ощущается — ntp включается галкой в любимом DE, а дистростроители для bind'а уже написали конфиг на наиболее популярный вариант — простого кеширующего dns-сервера, так что обычному домашнему юзверю достаточно просто его поставить и усё будет работать без настройки. Да и когда у тебя десятки контейнеров, там уже ntp+bind в каждом и не такими уж лёгкими покажутся, при том, что контейнеру нужен от силы 0.1% от их возможностей.

А то что пхать все внутрь systemd, не делает сам systemd тяжелым?

Наркоман, что ли? Это отдельные демоны, запускать которые никто не заставляет. По твоей логике так и от добавления pinky в coreutils последние потяжелели.

ну да, наверно 20 символов разницы стоят дополнительного кода

Там дополнительного кода - примерно те-же 20 символов. И один ключик. Почему-бы и не добавить?

То есть ntpd и bind тяжелые по-твоему? А то что пхать все внутрь systemd, не делает сам systemd тяжелым? У вас проблема с логикой мусьё

Ну, во первых, оно отключаемое. Во вторых - итоговый «вес» системы будет меньше, чем с использованием ntpd и bind

Напиши мне grep-аналог journalctl -p err --since 1:00 --until 1:30

grepjournal -p err --since 1:00 --until 1:30

Такие дела. Другое дело, что при желании ковырять логи можно и отдельными утилитами, в отличии от.

Это не выведет сообщения только за сегодня и только с уровнем Error. Старайся дальше.

grepjournal
bash: grepjournal: команда не найдена

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

journalctl --no-pager | cat | grep | sed | awk | perl | tr | brainfuck

Это достаточно простой сценарий, в реале бывают вещи гораздо тяжелее.

Дневной лог 3,5 гигабайт пока не пожат нужно посчитать статистику запросов по роутам в запросах в промежутке от 12 часов дня до 14 часов дня результат скинуть в базу чтоб можно было видеть график.

1 раз сделать одноразово по тем логам что есть (3 года) 2 задачу в крон ночью по расписанию по логу за прошедший день.

Вопрос: как я это смогу сделать на journalctl?

Результат типа:

10 мая 2014
/about 200
/blog/vasia 400
/blog/vasia/nes 500

11 мая 2014

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

metawishmaster> пффф, я его поделками не пользуюсь а у меня все работает, «что я делаю так»?

У тебя не работают современные возможности ОС, которые представлены только разработками Леннарта Поттеринга.

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

пффф, я его поделками не пользуюсь а у меня все работает, «что я делаю так»?

Ну, я тобой не пользуюсь. Давай тебя уничтожим как бесполезную поделку?

У тебя не работают современные возможности ОС, которые представлены только разработками Леннарта Поттеринга.

ай-яй-яй... срочно ижу курить и посыпать голову пеплом %))

а «по-теме», ИМХО, Леннарту женщину нужно. Же-н-нщи-ну.

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

Смысл? Поправить регулярку под конкретно твои требования дело 10 секунд.

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

А на тему journalctl --no-pager | grep и тд

[root@limbo chemist]# time journalctl -p err --no-pager > /dev/null

real	12m39.839s
user	8m34.543s
sys	4m1.467s

лог всего 2 гигабайта

vs

~ -$ time grep -e '\ 01:[0-3]' log > result                                                                                                 limbo@chemist :(
grep --color=auto -e '\ 01:[0-3]' log > result  1,55s user 0,80s system 99% cpu 2,362 total

Ну вы реально разницу в 12 минут не наблюдаете?

Если ты любитель подрочить на Оракл, то это твои личные проблемы. Можешь продолжать страдать и писать слёзные письма Ораклу. Истина не изменится — вы, ты и Оракл, не нужны.

ты логикой сейчас напоминаешь пана Яценюка %)

xorg

wayland же, какое отношение xorg имеет к редхату и поцтерингоподелиям?

ты логикой сейчас напоминаешь пана Яценюка %)

https://ru.wikipedia.org/wiki/Гипербола_(риторика)

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

Демон использует библиотеку. Что в этом непонятного?

Это дело надо отметить.

ух круто, сколько тут фич

Спорно, варианты разные.

Иногда проще предварительно обрабатывать данные и результат складывать в таблицу.

Хотя имел удовольствие работы с mysql с сырыми логами. Размер годовой базы терабайта на 3. суммарно база была лет за 6.

Удовольствия было масса.

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

Демон использует библиотеку. Что в этом непонятного?

Так это тебе было что-то непонятно.

>> Если у тебя за день лог отжирает по 3.5гб,

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

Проверено 4 годами работы в одной конторе с такими водящими.

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

«Я мзду не беру, мне за державу обидно»(c) :)

Это же против философии Юникса. Загадят систему, превратят ее в ванильное гавно для хомячков с одним единственным исполняемым файлом - systemd.

Загадят систему

Уже.

Нет, правильно так: «потому что». Остальное вариативно.

Код, который есть, потенциально опасен, даже если ты думаешь, что он «выключен».

>> Ну, понятное дело, сырые данные смысла хранить вообще нет.

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

Загадят систему

Уже.

я пока вцепился в wheezy но уже начинаю всерьез подумывать о Gentoo... ну или о форке debian'а w/o systemd

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

Не, если вопрос стоит так, то вариантов нет, не спорю.
Это как сравнение bind и resolved, разные весовые категории задач.