LINUX.ORG.RU

Новый релиз systemd 195

 


0

1

Lennart Poettering продолжает развивать свое творение, внося в него новые возможности. В свежевыпущенный релиз внесены следующие изменения:

  • journalctl получил новые параметры --since= и --until= для фильтрации по времени. Также теперь поддерживается фильтрация по юнитам через --unit=/-u.
  • journald теперь поддерживает ротацию и очистку журнала по времени в дополнение к уже имевшейся ротации по занимаемому месту.
  • journal теперь индексирует имеющиеся значения полей для каждого поля. Это позволяет клиенту просмотреть имеющиеся значения при фильтрации. В соответствии с этим обновлены bash completion. journalctl получил новый параметр -F для просмотра имеющихся значений, которые принимает поле в базе журнала.
  • Большее количество сообщений сервисов теперь записываются в журнал как структурированные и распознаются по идентификатору.
  • Мини-сервисы timedated, localed, которые ранее предоставляли поддержку смены времени, локали и имени хоста только из графического окружения типа GNOME, теперь имеют и минималистичные (но весьма функциональные) консольные клиенты для управления. Возможно, теперь это самый приятный способ смены настроек из командной строки, в особенности потому, что в них присутствует полный список опций и они интегрированы с bash completion.
  • Новая утилита systemd-coredumpctl для получения списка и извлечения coredump-ов из журнала.
  • Теперь дистрибутив устанавливает README-файлы в /var/log/ и /etc/rc.d/init.d, которые поясняют, куда подевались журналы и скрипты инициализации. Автор надеется, что это поможет сориентироваться зашедшему в эти, теперь пустые, каталоги.
  • В gatewayd добавлено множество возможностей таких, как режим «follow» для режима немедленной синхронизации и фильтрации.
  • gatewayd/journalctl теперь поддерживают вывод типа HTML5/JSON Server-Sent-Events.
  • Логика режима совместимости с init-скриптами SysV теперь эвристически определяет поддержку скриптом ключевого слова «reload» и только при его наличии предоставляет возможность «systemctl reload».
  • Сервисы типа oneshot не могут использовать ExecReload=.
  • При запуске пользовательского сервиса (через systemd --user) переменная окружения $MANAGERPID устанавливается в PID systemd.
  • Посылка сигнала SIGRTMIN+24 пользовательскому экземпляру systemd приводит к его немедленной остановке.
  • В browse.html теперь доступны фильтрация и просмотр детальной информации для отдельных полей.
  • «systemctl status --follow» удалено, используйте «journal -u».
  • Опции journald.conf RuntimeMinSize=, PersistentMinSize= удалены как бесполезные при настройке.

>>> Подробности



Проверено: JB ()
Последнее исправление: Silent (всего исправлений: 6)
Ответ на: комментарий от dr_dobermann

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

он не объясняет почему он делает/проектирует вещи таким образом.

10 стандартных объёмов напитка автору!!

qnikst ★★★★★
()
Ответ на: комментарий от vasily_pupkin

пока мне лень делать образ с SD можешь ли ты, посмотреть:

1). создаёт ли SD при запуске дефолтные иерархии cgroups.

2). создаёт ли SD личные иерархии для mem, cpu, blkio (вроде остальные лимиты не поддерживаются)

3). если SD не создаёт личные иерархии, то монтирует ли она общие со своим release_agent.

а то хочется, поспотреть насколько отличаются реализации, и если отличаются по подумать, что лучше.

qnikst ★★★★★
()
Ответ на: комментарий от anonymous

в арче ключи генерятся.

Как? Мы тут уже почти две страницы правильный юнит сочиняем, все никак не закончим...

$ pacman -Ql openssh | cut -d' ' -f2 | egrep '^/usr/lib/systemd/.*[^/]$' | xargs grep ''
/usr/lib/systemd/system/sshd.service:[Unit]
/usr/lib/systemd/system/sshd.service:Description=OpenSSH Daemon
/usr/lib/systemd/system/sshd.service:Wants=sshdgenkeys.service
/usr/lib/systemd/system/sshd.service:After=sshdgenkeys.service
/usr/lib/systemd/system/sshd.service:
/usr/lib/systemd/system/sshd.service:[Service]
/usr/lib/systemd/system/sshd.service:ExecStart=/usr/sbin/sshd -D
/usr/lib/systemd/system/sshd.service:ExecReload=/bin/kill -HUP $MAINPID
/usr/lib/systemd/system/sshd.service:KillMode=process
/usr/lib/systemd/system/sshd.service:Restart=always
/usr/lib/systemd/system/sshd.service:
/usr/lib/systemd/system/sshd.service:[Install]
/usr/lib/systemd/system/sshd.service:WantedBy=multi-user.target
/usr/lib/systemd/system/sshd.service:Also=sshdgenkeys.service
/usr/lib/systemd/system/sshd.service:
/usr/lib/systemd/system/sshd.service:# This service file runs an SSH daemon that forks for each incoming connection.
/usr/lib/systemd/system/sshd.service:# If you prefer to spawn on-demand daemons, use sshd.socket and sshd@.service.
/usr/lib/systemd/system/sshd.socket:[Unit]
/usr/lib/systemd/system/sshd.socket:Conflicts=sshd.service
/usr/lib/systemd/system/sshd.socket:Wants=sshdgenkeys.service
/usr/lib/systemd/system/sshd.socket:
/usr/lib/systemd/system/sshd.socket:[Socket]
/usr/lib/systemd/system/sshd.socket:ListenStream=22
/usr/lib/systemd/system/sshd.socket:Accept=yes
/usr/lib/systemd/system/sshd.socket:
/usr/lib/systemd/system/sshd.socket:[Install]
/usr/lib/systemd/system/sshd.socket:WantedBy=sockets.target
/usr/lib/systemd/system/sshd.socket:Also=sshdgenkeys.service
/usr/lib/systemd/system/sshd@.service:[Unit]
/usr/lib/systemd/system/sshd@.service:Description=OpenSSH Per-Connection Daemon
/usr/lib/systemd/system/sshd@.service:After=sshdgenkeys.service
/usr/lib/systemd/system/sshd@.service:
/usr/lib/systemd/system/sshd@.service:[Service]
/usr/lib/systemd/system/sshd@.service:ExecStart=-/usr/sbin/sshd -i
/usr/lib/systemd/system/sshd@.service:StandardInput=socket
/usr/lib/systemd/system/sshd@.service:StandardError=syslog
/usr/lib/systemd/system/sshdgenkeys.service:[Unit]
/usr/lib/systemd/system/sshdgenkeys.service:Description=SSH Key Generation
/usr/lib/systemd/system/sshdgenkeys.service:ConditionPathExists=|!/etc/ssh/ssh_host_key
/usr/lib/systemd/system/sshdgenkeys.service:ConditionPathExists=|!/etc/ssh/ssh_host_key.pub
/usr/lib/systemd/system/sshdgenkeys.service:ConditionPathExists=|!/etc/ssh/ssh_host_ecdsa_key
/usr/lib/systemd/system/sshdgenkeys.service:ConditionPathExists=|!/etc/ssh/ssh_host_ecdsa_key.pub
/usr/lib/systemd/system/sshdgenkeys.service:ConditionPathExists=|!/etc/ssh/ssh_host_dsa_key
/usr/lib/systemd/system/sshdgenkeys.service:ConditionPathExists=|!/etc/ssh/ssh_host_dsa_key.pub
/usr/lib/systemd/system/sshdgenkeys.service:ConditionPathExists=|!/etc/ssh/ssh_host_rsa_key
/usr/lib/systemd/system/sshdgenkeys.service:ConditionPathExists=|!/etc/ssh/ssh_host_rsa_key.pub
/usr/lib/systemd/system/sshdgenkeys.service:
/usr/lib/systemd/system/sshdgenkeys.service:[Service]
/usr/lib/systemd/system/sshdgenkeys.service:ExecStart=/usr/bin/ssh-keygen -A
/usr/lib/systemd/system/sshdgenkeys.service:Type=oneshot
/usr/lib/systemd/system/sshdgenkeys.service:RemainAfterExit=yes
/usr/lib/systemd/system/sshdgenkeys.service:
/usr/lib/systemd/system/sshdgenkeys.service:[Install]
/usr/lib/systemd/system/sshdgenkeys.service:WantedBy=multi-user.target
geekless ★★
()
Ответ на: комментарий от anonymous

Дык, все ExecStart-ы есть тут, что в них искать?

Т.е. это вот ExecStart'ы полученные в эмердженси, после того job-list?

Тогда давай уточним:

systemctl --version
grep -e Log -e DefaultStandard -e Auto /etc/systemd/system.conf
systemctl --system --full -all
systemd --test --system --unit=default.target
systemctl --no-pager show -p  OnFailure default.target
> systemctl show -p ExecStart $(systemctl --no-pager show -p OnFailure default.target | cut -f 2 -d =) --no-pager

Запасной вариант - бутнуться с systemd.confirm_spawn=yes в cmdline, если совсем будет непонятно что

vasily_pupkin ★★★★★
()
Ответ на: комментарий от qnikst
> /bin/ls -1R /sys/fs/cgroup > /tmp/lsR; ompload /tmp/lsR
Progress for '/tmp/lsR'
######################################################################## 100,0%
Omploaded '/tmp/lsR' to http://ompldr.org/vZzJjZQ
Success.
vasily_pupkin ★★★★★
()
Ответ на: комментарий от Gorthauer

Кстати сказки про монолит тоже не рассказывайте, это именно набор инструментов. Такой же как ваш sysvinit + набор костылей.

Ну вот откуда такие люди берутся? Ну с хера ли это наш sysvinit? Сам давно с него слез? Хинт — посмотри дату первого релиза systemd. Или ты гордый пользователь upstarta, что тебе sysvinit не уперся? Судя по тексту комментов, думаю, что openrc тоже не твое.

Давайте не хамить друг-другу. При обсуждении концепции, обсуждаем концепцию, а не оппонента.

dr_dobermann
()
Ответ на: комментарий от vasily_pupkin

ага, пасиб. независимое решение оказалось таким же, а можешь ещё посмотреть есть ли release agent на общих группах, это или cat /sys/fs/cgroup/cpu,cpuacct/release_agent или в /proc/mounts?

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

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

где именно написано «PID-1»? маны s6 вообще нагуглились, но именно это требование найти не могу.

проблемы не выдумываю

вы заявили, что отсутствует

4). возможность просто отдебажить, что происходит.

но доказывать не желаете. что же вы хотели?

если сильно хочется, то мне не лень собрать систему и с систем-д

если хочется — собирайте. я за вас доказывать неправоту поттеринга не собираюсь :)

З.Ы. это просто прекрасно (см. «Why have another logging mechanism?»). Типичное Совсем Другое Дело — это писал не Поттеринг, следовательно аргументация, изложенная там, может быть принята к рассмотрению.

littlechris ★★★
()
Ответ на: комментарий от dr_dobermann

Нет тут тупых обожателей sysvinit

Не, я про другое. Тут пишут будто sysvinit сотоварищи совершенен и якобы совершенно необходим Вообще Всем, и тем более — Обычным Пользователям. Если это действительно так, то логично ожидать, что существует изрядная очередь желающих поддерживать инитскрипты, если не во всех дистрах, то, как минимум, в мейнстримных. Иными словами, знамя не успеет долететь до земли, как его подхватят. Следовательно, беспокоится не о чем.

littlechris ★★★
()
Ответ на: комментарий от dr_dobermann

он не объясняет почему он делает/проектирует вещи таким образом

вероятно потому, что не обязан? мне вот тоже больше нравится кодить, чем подробно описывать rationale для business guys. сильно не нравится — форкайтесь или своё с нуля пилите, опенсорс же.

littlechris ★★★
()
Ответ на: комментарий от littlechris

вы заявили, что отсутствует

Я заявил, что у меня отсутствуют примеры возникших у меня проблем. А наличие проблем есть, тут далеко ходить ненадо и достаточно почитать хотя бы этот тред, а ещё можно на арчерассылку зайти и арчефорум почитать, да и федорорассылки.

Типичное Совсем Другое Дело — это писал не Поттеринг, следовательно аргументация, изложенная там, может быть принята к рассмотрению.

окей, давайте рассмотрим, мне даже интересно. Желательно по пунктам, т.к. journald попадает под все пункты того, чем плох syslogd, и не решает ни одну из проблем, о чем я писал вначале треда. В целом why have another logging mechanism описывает почему иерархическое лучше чем, syslog и как это работает. Плюс там описано как свести один из типов к другому, эти два типа логирования могут существовать как параллельно, так и отдельно друг от друга, ну и там можно легко менять логгер с их на любой другой. (Ну и я считаю, что переизобретение логгера это очень дурацкая идея в s6, и единственное оправдание им это то, то она полностью отключаема и заменима). А ну да там ещё есть наезды на конкретные реализации syslog, часть из которых не совсем верна, но автор хотя бы пишет почему он считает это не верным, а как строится дизайн другого решения.

qnikst ★★★★★
()
Ответ на: комментарий от littlechris

ну, я поставил пакет openssh и оно себе крутится под неправильным юнитом с socket activation

Админ локалхоста? Тред не читай @ своё мнение выражай.

взять другой инитскрипт, preg_replaceом заменить путь к
preg_replace

Так, сначала DOS, теперь PHP, значит? Полный набор джентельмена.

Чтобы написать инитскрипт, с нуля нужно раскурить гораздо больше информации

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

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

ну и да, батники не поддаются статическому анализу.

Да ты, я вижу, с козырей зашел! Ну расскажи тогда, чего уж таить, как ты статически анализируешь systemd и почему у него, такого поддающегося, то утечки, то сегфолты?

> ulimit-ы в initscript-ах тоже всегда были из коробки
и кто ими пользовался?

Я пользовался и пользуюсь. Если у тебя нет соответствующей квалификации --- это не оправдание.

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

Похапешников, пишущих инитскрипты для «релиза в продакшн» допускают только ССЗБ.

anonymous
()
Ответ на: комментарий от vasily_pupkin

Понятия не имею. Если по тех требованиям его там быть не должно, почему он там должен быть?

Вот и я о том же! Можно ли бебиситтера выпилить из системД? Почему бы не сделать систему запуска, которая формирует таблицу запущенных процессов и по окончании их старта передать супервизору эту таблицу? Причем отражать в таблице только те процессы, которые в конфигурации прописаны как подлежащие наблюдению? Причем если таблица вышла нулевая, то супервизор тут же закончил бы свою работу и не жрал ресурсы.

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

Ну убог дизайн у SD, неужели не видно? При этом я согласен с Поттерингом, что менять (не заменять) систему запуска для десктопа нужно. Винда, сцука, быстрее стартует на том же железе (правда только новая, то есть с коротким реестром), просто потому, что у нее есть отложенный старт сервисов. Ну нахрена в систему запуска тащить удев и писать собственный журнал, я не понимаю.

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

dr_dobermann
()
Ответ на: комментарий от dr_dobermann

Вот и я о том же! Можно ли бебиситтера выпилить из системД?

Зачем делать из systemd то, для чего он не предназначен? Почему бы не взять более подходящий инструмент для решения задачи?

Остальное комментировать нет желания. Уже все было написано много раз

vasily_pupkin ★★★★★
()
Ответ на: комментарий от qnikst

давайте рассмотрим

лично меня главным образом позабавило «there is no choice here: logging and log rotation management must be done by the same tool». хорошо перекликается с содержанием новости :)

journald попадает под все пункты того, чем плох syslogd

вы о пунктах по ссылке на ман?

littlechris ★★★
()
Ответ на: комментарий от littlechris

лично меня главным образом позабавило «there is no choice here: logging and log rotation management must be done by the same tool». хорошо перекликается с содержанием новости :)

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

journald попадает под все пункты того, чем плох syslogd

я о пунктах по ссылке на обсуждаемую статью. (syslogd is a complex process that runs as root^{priveledged user}; syslog requires a syslogd service, and fails otherwise; syslogd logs to files... (вот лично я бы поспорил с этим утверждением); syslog makes you send all your logs to the same place).

qnikst ★★★★★
()
Ответ на: комментарий от anonymous

теперь PHP

ха, и правда в pcre.h оно по другому называется. Ну и что теперь?

оставь это мейнтейнерам дистрибутива

А это идея. Значит, для скриптов в debian — нанять одних maintainerов, для RH (условно, там upstart и никого нанимать не нужно) — других, для gentoo — третьих, для freebsd — четвёртых и так далее.

Мнимое отсутствие необходимости знать и понимать процесс загрузки

я не говорил, что эта необходимость отсутствует. забавно, что знать и понимать процесс загрузки sysvinit «необходимо», а systemd — якобы нет. из-за тёплых ламповых батников, не иначе.

как ты статически анализируешь systemd

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

Я пользовался и пользуюсь

так а где они используются в мейнстриме? ну и cgroups > ulimit (взять хотя бы IO rate limiting).

охапешников, пишущих инитскрипты для «релиза в продакшн» допускают только ССЗБ.

кому писать скрипт запуска софтины, если не разработчику? кто знает подробности её функционирования лучше разработчика?

littlechris ★★★
()
Ответ на: комментарий от littlechris

А это идея. Значит, для скриптов в debian — нанять одних maintainerов, для RH (условно, там upstart и никого нанимать не нужно) — других, для gentoo — третьих, для freebsd — четвёртых и так далее.

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

я не говорил, что эта необходимость отсутствует. забавно, что знать и понимать процесс загрузки sysvinit «необходимо», а systemd — якобы нет. из-за тёплых ламповых батников, не иначе.

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

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

а в инитскриптах прям так нельзя? а опция --dry-run для красоты приделана. Да и декларативные инитскрипты я тут приводил :).

Ну и это не так и важно, но если честно, меня немного напрягало читать выложенные здесь юниты и пытаться понять, исключающее ли или в *Condition=«|!fileExists» и что он сделает если там симлинк, а если сокет?.. вот честно if [ -e filename -a foo -o bar ] ; then мне легче прочитать, даже без чтения документации. Естественно если осилить всю системд-шную документацию таких вопросов не возникнет.

кому писать скрипт запуска софтины, если не разработчику? кто знает подробности её функционирования лучше разработчика?

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Вместо того, чтобы вырывать из контекста строки совпадающие с защищаемой вами точкой зрения

вырванные из контекста строки На Самом Деле значат совершенно противоположное?

я о пунктах по ссылке на обсуждаемую статью

ага, отлично.

is a complex process that runs as root

есть такое. но не вижу препятствий к исправлению.

syslog() requires a journald service, and fails otherwise (так правильно будет?)

ЕМНИП, как раз не fails. но надо проверить.

logs to files
makes you send all your logs to the same place

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

littlechris ★★★
()
Ответ на: комментарий от qnikst

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

К сожалению в «продакшене» дебиан редко соседствует с гентой. Не надо о больном, вобщем

vasily_pupkin ★★★★★
()
Ответ на: комментарий от littlechris

[is a complex process that runs as root] есть такое. но не вижу препятствий к исправлению.

хитрая настройка политик? наименьшее общее кратное прав? понижение уровня доступа до targets? Хотя если journald использует свою db, то формально он может жить полностью под своим юзером и перекинуть проблему доступов на юзера и запускалку в sd.

ЕМНИП, как раз не fails. но надо проверить.

проверь, заодно интересно а). логи будут улетать в /dev/null, б). если journald падает для одного сервиса, что происходит с логами других.

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

блин, написал бы он same bus, не было бы столько разночтений. Автор видит проблему syslog в том, что все сообщения приходят к одному консьюмеру (пусть и многопоточному) и дальше объясняет почему это плохо.

Основная идея автора: то, что любой logd сервис это сложный процесс, который требует повышенных (относительно) привелегий и может являться точкой отказа в сложной системе, самое инетересно, что это by design у logd-сервисов и более того это основная идея их существования, и у неё наверняка есть обоснования и причины когда это круто. Соотв это никак не может быть изменено.

В противовес приводится иерархическое логирование, когда к stderr процесса прицепляется очень маленькая программа, которая умеет работать с логом или скприт, в качестве своего решения они привели свой s6-log, который умеет логировать, логротейтить и жать. При этом там логгер может быть прозрачно заменён на любой, напр они приводят в пример скрипт, который перенаправляет все логи на другой комп. Бонусы - программы/скрипты простые как полено, требуют минимума прав, выполняются в одной группе задач с программой (управление ресурсами и командами). Вполне обоснованная точка зрения.

Ну и объяснение как из иерархического сделать syslog и из syslog сделать иерархическое.

qnikst ★★★★★
()
Ответ на: комментарий от vasily_pupkin

К сожалению в «продакшене» дебиан редко соседствует с гентой. Не надо о больном, вобщем

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

не считая некоторых мелочей

именно. и неизвестно каких. неуютненько.

если потратить ещё 5 минут

ок, пусть так. хотя вот лично я ни с openrc, ни с runscript не знаком и сомневаюсь, что у меня эта задача займёт по 5 минут.

в инитскриптах прям так нельзя

как, не запуская инитскрипт (из дебиана, допустим), выяснить, что он проверяет, является ли файл /sbin/sshd выполняемым?

декларативные инитскрипты я тут приводил

дада. как определить, который бинарник принадлежит демону — start-stop-daemon или /sbin/sshd?

меня немного напрягало читать выложенные здесь юниты и пытаться понять, исключающее ли или в *Condition=«|!fileExists» и что он сделает если там симлинк, а если сокет

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

Естественно если осилить всю системд-шную документацию таких вопросов не возникнет.

это нечестно, что ли?

как-то практика показала, что разработчики частенько фигово с этим справляются

ну ещё бы. информации вагон и она фрагментирована. полгода тому назад знакомому надо было засунуть демона в автостарт. он полдня рисовал инитскрипт, потом плюнул, за 15 минут набросал конфиг для upstart, оно завелось и он про него забыл. Нет чтобы нанять maintainerа, как тут выше предлагали.

littlechris ★★★
()
Ответ на: комментарий от littlechris

Тут пишут будто sysvinit сотоварищи совершенен и якобы совершенно необходим Вообще Всем, и тем более — Обычным Пользователям

Обычным пользователям абсолютно без разницы. На серверах systemd громоздок и избыточен. Выводы очевидны.

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

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

geekless ★★
()
Ответ на: комментарий от littlechris

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

Binary ★★★★★
()
Ответ на: комментарий от littlechris

и неизвестно каких.

известно - команды depend. Но и без неё всё заработает.

ок, пусть так. хотя вот лично я ни с openrc, ни с runscript не знаком и сомневаюсь, что у меня эта задача займёт по 5 мину

а зачем это делать если всё и так уже работает. Это исключительно возможности сделать всё лучше и удобнее, когда других задач нет (лучше ж чем на лоре троллить). Да и единожды узнав, всё будет делаться сильно меньше, чем за 5 минут :)

дада. как определить, который бинарник принадлежит демону — start-stop-daemon или /sbin/sshd?

как узнать, что такое RemainAfterExit=yes?

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

ты про systemd?

это нечестно, что ли?

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

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

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Логгер поцтеринга такой сложный в первую очередь потому, что генерирует кучу метаинформации. То что генерирует эту метаинформацию должно её как-то передать тому, что её будет записывать. Наверное стоит обвинить поттеринга в том, что он действительно не запихал необходимые куски из journald в systemd (как все этого ожидают), для того, что бы с чистой совестью валить legacy лог через стандартный интерфейс без посредников. Вообше это единственный вариант «как могло бы быть лучше» который я представляю, для данной ситуации и данной концепции.

journald не может работать не от рута, из-за того, что выполняет логику ротации. Но если бы мог — разница все равно не была бы велика. Это дешевле разрулить SELinux/Apparmor правилами, чем разбивать службу на куски

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от geekless

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

littlechris ★★★
()
Ответ на: комментарий от littlechris

Ну если тебе надо сходить на курсы, чтобы осилить bash, кто ж тебе злобный буратина?

geekless ★★
()
Ответ на: комментарий от qnikst

известно - команды depend

где это написано?

зачем это делать если всё и так уже работает

я пилю проприетарный сервис и кастомеры просят инитскрипт для генты.

как узнать, что такое RemainAfterExit=yes?

man то ли systemd.exec, то ли systemd.unit. АПВОВНВ?

вы видели 5 комментарий?

а всего их 6. вы видели шестой комментарий?

littlechris ★★★
()
Ответ на: комментарий от qnikst

ты про systemd?

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

инитскрипты это сложно непонятно

в инитскриптах больше информации и нет способа сказать «а, это шаблонный код, я знаю, что он делает» => они сложнее.

у вашего знакомого такая квалификация

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

littlechris ★★★
()
Ответ на: комментарий от qnikst

инитскрипты это сложно непонятно

…нет способа сказать «а, это шаблонный код, я знаю, что он делает» без наличия опыта…

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

littlechris ★★★
()
Ответ на: комментарий от littlechris

в инитскриптах больше информации и нет способа сказать

Да-да. /etc/init.d/functions - это ваще не способ. Изобрести идиотский коцаный DSL - это, да, это шок.

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от littlechris

Это не сложно. И не непонятно. Это противно. "- Блюэ! - Аккуратней, это Мерседес! - Нет, меня просто так зовут!"

AlexM ★★★★★
()
Ответ на: комментарий от vasily_pupkin

journald не может работать не от рута, из-за того, что выполняет логику ротации.

Ящетаю, это прекрасно! И как решение, и как адвокаси.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

Единственный плюс такого DSLя - это то, что такой конфиг можно накликать при наличии специально заточенной для этого тулзени. Здравствуй, администрирование ленугза мышкой! Мы все так по тебе соскучились!

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от littlechris

где это написано?

ммм.. не знаю :)

я пилю проприетарный сервис и кастомеры просят инитскрипт для генты.

за деньги кастомеров и осилить на примерах можно, или почитать runscript.sh.in там всего строк 324 строки. Тот скрипт, что приводил я, я осилил за 10-15 минут без использования документации, заодно случайно напоролся на баг исправленный в последующих версиях, большая часть времени была потрачена на него.

А подробной документацией можно будет заняться позже, как с цгруппами разберусь.

АПВОВНВ?

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

а всего их 6. вы видели шестой комментарий?

окай.. но такая магия с демонизацией это хм.. слегка страшно.

qnikst ★★★★★
()
Ответ на: комментарий от AlexM

/etc/init.d/functions - это ваще не способ

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

вот простой и понятный https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/..., который использует lsb-functions. а вот сложный и непонятный https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/...

littlechris ★★★
()
Ответ на: комментарий от littlechris

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

я про квалификацию в программировании, неважно каком.

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

если честно ему достаточно было добавить одну строку в inittab с чем-то вроде:

x:5:respawn:cd /home/ubuntu/myapp && sudo thin start -e procution -p80 > /home/ubuntu/myapp/thin.log 2 >&1
qnikst ★★★★★
()
Ответ на: комментарий от littlechris

да и опять же еретикам из openrc его не хватает.

решение еретиков из openrc в этом и заключается runscript это расширение POSIX shell модными^Wчасто упортебимыми функциями, плюс пара парсеров и start-stop-daemon, надо как-нибудь позже написать толковое введение, плюс объединение всей этой радости через env.

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от littlechris

Ну, вообще, даже короткого взгляда оказывается достаточно, чтобы понять, что сравниваются разные по функционалу вещи. Если из init'овского скрипта выкинуть все навороты, то останется, ну, немногим больше, чем в апстартовом варианте. Нужны ли эти навороты, или нет, я судить не берусь, у меня сислог запускается заметно проще ;)

А вот как Вы будете тестировать в unit-файле, а не запускаемся ли мы под GNU/kFreeBSD - вот в чём вопрос ;)

AlexM ★★★★★
()
Ответ на: комментарий от qnikst

ммм.. не знаю :)

а откуда мне тогда знать? :)

осилить на примерах можно

э нет, мне доки подавай. или сорцы.

заодно случайно напоролся на баг

А вот кстати. Скопипастил, значит, Тревис себе 2Кб первого попавшегося инитскрипта, которых рядом тучи. Как тут неявно утверждается, «просто» поправил релевантные строки и оно заработало. Затем в исходном инитскрипте находят багу, перекочевавшую в производный (например, нууу… лишний пробел в $PIDFILE= и вместо вытирания пидфайла вытирается /var). Прилетает срочни апдейт того пакета. Исходный инитскрипт исправлен, производный — нет. Более того, Тревис даже не подозревает, что у него в скрипте баг.

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

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

littlechris ★★★
()
Ответ на: комментарий от littlechris

э нет, мне доки подавай. или сорцы.

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

А вот кстати.

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

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

не распарсил смысла.

qnikst ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.