Re: systemd-networkd

[artiom]

Нет, проблема не во мне.
Я отключил это - всё заработало.
Проблема в тех, кто это производит и тех дураках, кто их поддерживает.

08.08.2019 06:36, Igor Savluk пишет:



On 24/07/2019 14.03, Н. Артём wrote:

Есть система, которая имеет SSH сервер в initramfs (dropbear).
Интерфейсы связаны через бондинг в bond0, на котором этот сервер 
работает.

Роутер выдаёт бондинг интерфейсу через DHCP фиксированный IP по MAC.

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

которая настраивает бондинг и поднимает OpenSSH.
MAC bond0 не изменяется, IP выдаётся тот же.

Когда был Stretch, не было проблем, всё работало.
Обновил на Buster - всё сломалось.

Выяснилось, что недавно пришедший на замену работающей подсистеме, 
networkd-systemd всё ломает.
Если я не опускаю бондинг, его расхреначивает, и он требует IP для 
каждого адаптера.
Когда я устанавливаю MAC вручную в его настройках (в двух местах - 
настройках устройства bond0 и в настройках подключения),

он всё-равно устанавливает MAC на свой, и только потом на мной указанный.

В результате, роутер выдаёт другой IP (к тому моменту, ещё не истёк 
срок действия предыдущего).


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



Отсюда вопросы (реально не в курсе, так что может не в тему):

- Что я делаю не так?
- Зачем поменяли работающее на это?
- Повинен в этом Леннар или это последователи?
- Что их не устраивало в resolv.conf?
- Стоит ли намекнуть маинтайнерам дистрибутива на то, что это какая-то 
сильно непрозрачная, кривая и неочевидная в настройке херня?


Проблема только в тебе и твоих руках.

Re: systemd inittab

[Victor Wagner]

В Mon, 5 Aug 2019 05:06:38 +0300
sergio  пишет:

> On 23/05/2019 10:26, Victor Wagner wrote:
> 
> > Может поискать что другое для управления kvm-виртуалками.
> > Я после некоторой возни с libvirt плюнул и вообще свой скрипт на
> > питоне написал.   
> 
> Я выяснил! Оказывается мэинтейнер libvirt, прикрываясь проблемами
> секьюрити systemd, решил, что самое безопасное это добавить
> policykit-1 в зависимости libvirt. Пять лет назад.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768376#20
> 
> Ну и все кому нужно без systemd просто пересобрали пакет с
> исправленным debian/control.

На мой взгляд, зависимость от policykit - это не самая большая проблема
libvirt.

Самых больших проблем там три

1. Наличие libvirtd - отдельного процесса, который постоянно запущен,
даже если ни одной виртуалки или контейнера нет.

2. То что это  библиотека.

3. ХML-ные конфиги.

-- 
   Victor Wagner 

Re: systemd inittab

[sergio]

On 23/05/2019 10:26, Victor Wagner wrote:

> Может поискать что другое для управления kvm-виртуалками.
> Я после некоторой возни с libvirt плюнул и вообще свой скрипт на питоне
> написал. 

Я выяснил! Оказывается мэинтейнер libvirt, прикрываясь проблемами
секьюрити systemd, решил, что самое безопасное это добавить policykit-1
в зависимости libvirt. Пять лет назад.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768376#20

Ну и все кому нужно без systemd просто пересобрали пакет с исправленным
debian/control.


Мне вот интересно, а в дебиане есть какой-нить арбитраж или мэинтейнер
прав и я ничего не смыслю в этой безопасности?


-- 
sergio.

Re: systemd-networkd

[artiom]

Более того, формально opensource продукты, такие как мозилла тоже
в общем-то нарушают свободу N1. Потому что дизайн там такой запутанный
что на выяснение того как там что устроено и "change it so it does
computing as you wish" уйдут годы. А за эти годы оно будет три раза
переделано. Поэтому если ты не имеешь возможности тратить на работу над
конкретным продуктом значительную часть своего времени, ты не сможешь
"change it so it does your computing as you wish."


Конкретно насчёт этого, вы не правы. Тот же Столлман достаточно серьёзно 
относится к терминологии.

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

Re: systemd-networkd

[artiom]

> Правильно думаете. Я имею слишком большой опыт  программирования на
> этому уродце, чтобы заниматься этим в конце второго десятилетия XXI
> века, когда есть Go и Rust.

Go - это для микросервисов, да и то, где не требуется особая 
предсказуемость, как и любой язык с коллектором.
Ну и сам по себе: начали за здравие, кончили за упокой, когда туда 
набежали пионеры и стали засовывать директивы в комментарии, а систему 
его сборки объединять с Git, параллельно напиливая костыли, типа вендоринга.

Rust, увы, не взлетел, и похоже, что сейчас уже не предполагается.


> А код на C++ который существует ну слова доброго не стоит (ну скажем
> мозилла или qt).

Mozilla я не копал, а Qt вполне приятная библиотека, подозреваю, чем она 
вас не устроила, однако в целом, достаточно неплоха.



> Опять же код на столь безумно устаревших языках интересен только если у
> нас есть огромная старая codebase (ну скажем mozilla или qt). А эта
> codebase все равно была написана по стандартам конца прошлого века.
> Так что продолжать в том же духе не столь уже сложно

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


> Потому  что мы в debian-russian. Были бы во freebsd-russian или
> macos-russian, шла бы речь про clang. Ну и понятно на какой платформе
> шла бы речь про MSVC.
>

Ну мы - да, а софт - нет: это более обоснованно, чем поддерживать всю 
линейку _одного_ компилятора.



> Вот совместимость с линейкой компиляторов очень способствует "чтобы оно
> не падало в местах, где...". Разные компиляторы вылавливают в качестве
> Warning-ов разные огрехи. И если все их гонять с -Werror и аналогами...

Ну многие так делают, это неплохо.
Только не с линейкой компиляторов.
Именно с разными компиляторами: достаточно новыми версиями, как правило.


> Очень полезно для этой цели также тестироваться на разных процессорах.
> Вот, скажем если в тестовой ферме есть спарк, ни один не выровненный
> доступ к памяти не уйдет.
>

Это уже вопрос наличия ресурсов.


> Так борьба с systemd тоже требует времени. Вопрос в том, на что
> потратить время - на борьбу с поделиями поттерингов или на создание
> альтернативы им.
>

В том и дело, что я не борюсь: стараюсь обходить стороной, пока работает.
Если уж совсем что-то невменяемое, как в этот раз - отключаю.
Благо, предыдущий вариант ещё не сломали.


> Собственно проблема devuan как раз в том, что люди предпочитают бухтеть
> про то, какой плохой поттеринг, вместо того чтобы засучить рукава и
> сделать свое.

Зачем? Уже много делали. "Выбрали" творение поттеринга, потому что RH.


> Столлман 35 лет назад не бухтел про то какая плохая
> Symbolics, а писал патчи для LMI.
>

Столлман живёт в США, и он мог себе позволить бросить престижный и 
дорогой ВУЗ, не опасаясь того, что ему будет негде жить и нечего есть.

Конечно, жертвенность - это вопрос приоритетов и силы духа.
Но далеко не всем требуется переписать ОС: разные приоритеты и желания, 
но это не отменяет того, что хочется нормально работающую систему, а не 
компиляцию поделок.



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

Очевидно. Потому что, свою проблему мне надо решить в первую очередь. И, 
желательно, с минимумом затрат, так что, "для всех", - это когда припрёт.

Хотите мне сказать, что это плохо? :-/
Так и вы не святой, чтобы праведно судить: делаете то, за что вам платят 
заказчики.



> Объективная причина тут одна - люди не хотят в этом участвовать.
> Вы не хотите, я не хочу (разок сунулся, остался неуслышанным и плюнул,
> все равно мне дистрибутивы с systemd поддерживать, так что знать его
> придется).
>

Ну так о чём говорить? А поттеринг сунулся - не услышали, сунулся - 
послали, сунулся - отгородились.

Но он делал это снова и снова, пока не пробился.


>> Ну и прекращение их выхода для старых версий библиотек (та же OpenSSL
>> в конце года выкидывает какую-то версию) и прекращение официальной
>> разработки и поддержки старых диалектов, типа Python 2, на котором в
>> Devuan много что есть, тоже не стимулирует к переходу.
>
> Подавляющее боьшинство крупных корпоративных заказчиков использует
> системы на базе RHEL 6 и 7. Которые обе гораздо старее Devuan. Так что не
> беспокойтесь по поводу прекращения поддержки софта менее чем
> десятилетней давности.

Да как факт в openssl (по-моему, 1.12.x) больше патчей не будет.
Это риск по SDL.
Его заставляют менять, следовательно, придётся обновлять то, что в 
образах, а с учётом завязок других компонентов, надо обновлять саму ОС.



25.07.2019 10:12, Victor Wagner пишет:

On Thu, 25 Jul 2019 09:04:21 +0300
artiom  wrote:


  > Прописывать адрес статически.

А, ну да, в IPv6 у каждого диапазон же.
Можно, конечно, особенно внутри сети.
Но сейчас всё настроено с IPv4 и автоматической выдачей адресов, не
хочется 

Re: systemd-networkd

[Eugene Berdnikov]

On Thu, Jul 25, 2019 at 01:00:18PM +0300, Victor Wagner wrote:
> On Thu, 25 Jul 2019 11:58:01 +0300
> Eugene Berdnikov  wrote:
> 
> > > доступа к которым с этим китайцем придется судиться.
> > > в) оно все нихрена не документировано.  
> > 
> >  Железка и драйвера нас не интересуют. А вот базовая платформа общая.
> 
> Как не интересует? Нас интересует изменить поведение железки так, чтобы
> она делала то, что надо нам. Свобода N1 по Столлману.

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

> Кстати, в огромном количестве случаев "чтобы она работала как нам надо"
> будет "поправить дурацкий глюк в драйвере WiFi" или что-то подобное,
> так что без драйверов никак.

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

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

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

 Да это тоже маниловщина. Открывашь, скажем, кусок, относящийся к изернету
 в более-менее структурированной линуксовой сети, а там -- бац! Kакие-то
 skb, локи, rcu и хрен знает что внутри привычного, вроде бы, языка Си...

 Выдыхашь, снимаешь с полки книжку по теории поля, чтобы понять, что там
 за хиггса такого на БАКе поймали, о котором трындят по ящику. А там, блин,
 вакуум, лагранжиан, группы, пропагаторы... Хотя их всех просто складывают
 да умножают, интегралы какие-то берут. Вроде бы всё в школе учили. :)

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

> Вопрос в том, что Столлман в свое время осознавал образовательную
> ценность текстов программ. Поттеринги и де Иказы  - нет. Они пишут 
> не для того, чтобы их тексты читали, а чтобы это работало как
> магический артефакт, который может модифицировать только его создатель.

 Да им просто не до документации... Это плохо, но не нужно искать здесь
 сознательное вредительство. Настоящее вредительство это "документация"
 от Майкрософт, у которого, наверное, есть целый штат сотрудников,
 задачей которых является так переделать технический текст, чтобы читающий
 (даже если у него 20-летний стаж в предметной области) почувствовал себя
 полным идиотом.
-- 
 Eugene Berdnikov

Re: systemd-networkd

[Victor Wagner]

On Thu, 25 Jul 2019 11:58:01 +0300
Eugene Berdnikov  wrote:

> > доступа к которым с этим китайцем придется судиться.
> > в) оно все нихрена не документировано.  
> 
>  Железка и драйвера нас не интересуют. А вот базовая платформа общая.

Как не интересует? Нас интересует изменить поведение железки так, чтобы
она делала то, что надо нам. Свобода N1 по Столлману.

Как правило, это подразумевает "собрать образ
прошивки, включающий все - и ядро, и драйвера и весь софт, включая
модифицированный нами". Производители железяк почему-то очень любят
оперировать образами прошивок. Как вспомню сколько пришлось Nokia пинать
всем сообществом, чтобы они в N800 и иже с ним сделали обновление
ядра через пакетный менеджер. И это Nokia, а не китайцы.

Кстати, в огромном количестве случаев "чтобы она работала как нам надо"
будет "поправить дурацкий глюк в драйвере WiFi" или что-то подобное,
так что без драйверов никак.

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

Ну или "попатчить CVE которое в mainline попатчили 3 версии ядра назад,
а у этих китайцев ядро 5 версий назад и сами они апдейтить его не
собраются"

>  Вам Столман не объяснил, в чём разница между свободным и бесплатным?

Мне-то как раз объяснил. Это вы тут пытаетесь нагло врать и утверждать
что несовободное свободно.

Свобода - это когда я (квалифицированный програмист, обремененный
семьей) могу в свободное время от своих других дел, заодно разобраться и
с этим. У меня на это хватит времени и сил. Поэтому Столлман
существенно важной частью концепции Свободного ПО всегда полагал Toolbox
Philosophy, которая сводит время на разбирательство к приемлемому.

Поэтому монолитные продукты, такие как Firefox, systemd, libreoffice
не могут считаться свободным ПО, по какой бы они лицензии не
распространялись.

>  А думать, что "свобода" это когда можно без подготовки и образования
>  сесть и сходу поправить что-то в коде гигантского проекта, вроде

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

Поэтому об отсутствии подготовки и образования речь не идет.

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

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

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

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

-- 

Re: systemd-networkd

[Eugene Berdnikov]

On Thu, Jul 25, 2019 at 10:25:46AM +0300, Victor Wagner wrote:
> On Thu, 25 Jul 2019 09:47:34 +0300
> Eugene Berdnikov  wrote:
> 
> > On Thu, Jul 25, 2019 at 12:54:43AM +0300, Victor Wagner wrote:
> > > Здесь все не так. И война за свободу ПО, которую начал Столлман в
> > > середине 80-х - проиграна.  
> > 
> >  Выиграна. Какую коробочку с WiFi или 4G ни возьми с полки, везде
> >  внутри линукс, а из лога, если он показывается, торчат busybox,
> >  dnsmasq и прочие ужасы... :) И каждый новый китаец, пришедший на
> > рынок со своей новой коробочкой, пихает в неё тот же линукс. Потому
> 
> Проиграна. Попробуйте в этом busybox-е что-нибудь изменить.
> Выяснится что
> а) не так-то просто выяснить как и чем это вообще можно собрать

 Нужна некоторая квалификация. Абыдна, да? :)

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

 Железка и драйвера нас не интересуют. А вот базовая платформа общая.
 О ней и речь. И о том, что китаец без этой платформы свои железки продать
 уже не может, т.к. конкуренты вокруг с линуксами и экономически давят.

> Более того, формально opensource продукты, такие как мозилла тоже
> в общем-то нарушают свободу N1. Потому что дизайн там такой запутанный
> что на выяснение того как там что устроено и "change it so it does
> computing as you wish" уйдут годы. А за эти годы оно будет три раза
> переделано. Поэтому если ты не имеешь возможности тратить на работу над
> конкретным продуктом значительную часть своего времени, ты не сможешь 
> "change it so it does your computing as you wish."

 Вам Столман не объяснил, в чём разница между свободным и бесплатным?
 Жаль. Если нет времени разбираться в продукте, заплатите тому, кто сядет
 и разберётся. Продукт можете ему дать, вместе с зарплатой. Вас никто
 в этом не ограничит, и будет свободный выбор между "плестись в остающих
 на 3 года" или "опередить всех", "сделать свой форк" и т.д.

 А думать, что "свобода" это когда можно без подготовки и образования
 сесть и сходу поправить что-то в коде гигантского проекта, вроде ядра
 линукса, так это глупо. Никто ж не удивляется тому, что средняя кухарка
 не может просто так сесть и посчитать распределение радиационных потерь
 нейтронов в стенке реактора: ей нужно хотя бы квантовую механику изучить.
 Хотя книжек по физике на полке и в инете целый ряд, все свободно доступны.
 А если ещё возмущаться тем, что книжки "слишком сложно написаны", так
 это просто инфантилизм чистой воды. :)
-- 
 Eugene Berdnikov

Re: systemd-networkd

[Victor Wagner]

On Thu, 25 Jul 2019 09:47:34 +0300
Eugene Berdnikov  wrote:

> On Thu, Jul 25, 2019 at 12:54:43AM +0300, Victor Wagner wrote:
> > Здесь все не так. И война за свободу ПО, которую начал Столлман в
> > середине 80-х - проиграна.  
> 
>  Выиграна. Какую коробочку с WiFi или 4G ни возьми с полки, везде
>  внутри линукс, а из лога, если он показывается, торчат busybox,
>  dnsmasq и прочие ужасы... :) И каждый новый китаец, пришедший на
> рынок со своей новой коробочкой, пихает в неё тот же линукс. Потому

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


Собственно нарушается свобода N1.

The freedom to study how the
program works, and change it so it does your computing as you wish.

Более того, формально opensource продукты, такие как мозилла тоже
в общем-то нарушают свободу N1. Потому что дизайн там такой запутанный
что на выяснение того как там что устроено и "change it so it does
computing as you wish" уйдут годы. А за эти годы оно будет три раза
переделано. Поэтому если ты не имеешь возможности тратить на работу над
конкретным продуктом значительную часть своего времени, ты не сможешь 
"change it so it does your computing as you wish."

А с тех пор как Мозилла стала подписывать расширения ключом, сертификат
которого встроен в браузер, там все стало очень плохо со свободой N3.
Чтобы распространять модифицированную версию своего расширения, я должен
получить разрешение от чиновника из Mozilla foundation. Иначе оно не
будет работать у тех, у кого не отключена проверка подписи под
расширениями, что во-первых не во всех билдах отключаемо, во-вторых
вообще-то security hole.

Когда на выполнение какого-то действия требуется разрешительная виза 
от чиновника - это означает что свободы выполнять это действие нет.

> 
>  Экосистема живёт и развивается, это главный результат. А кто там

Крепостническая Россия при Екатерине II тоже жила и развивалась,
несмотря на отдельные мелкие шероховатости вроде восстания Пугачева.
Золотой, говорят, век. Только вот свободы нихрена там не было.

--

Re: systemd-networkd

[Victor Wagner]

On Thu, 25 Jul 2019 09:04:21 +0300
artiom  wrote:

>  > Прописывать адрес статически.  
> 
> А, ну да, в IPv6 у каждого диапазон же.
> Можно, конечно, особенно внутри сети.
> Но сейчас всё настроено с IPv4 и автоматической выдачей адресов, не 
> хочется переделывать.
> 
>  > Здесь все не так. И война за свободу ПО, которую начал Столлман в
>  > середине 80-х - проиграна.  
> 
> Хм, надо будет почитать...
> 
> 
>  > Если ты не можешь написать софт, который компилируется любым GCC
>  > начиная с 4.6 и конччая 9.1, то ты не умеешь программировать. Если
>  > ты скачал откуда-то такой софт, сотри немедленно. Потому что его
>  > автор не умеет программировать, и отсутствие поддержки компилятора
>  > имеющейся у тебя версии, скорее всего не единственная и не главная
>  > его проблема. 
> 
> Ну это излишне сильное утверждение.
> Я так думаю, вы на C++ не программируете.

Правильно думаете. Я имею слишком большой опыт  программирования на
этому уродце, чтобы заниматься этим в конце второго десятилетия XXI
века, когда есть Go и Rust. 

Код на C писать и поддерижвать - это да, приходится. За полвека его
слишком много было написано, и хорошего.

А код на C++ который существует ну слова доброго не стоит (ну скажем
мозилла или qt).

Опять же код на столь безумно устаревших языках интересен только если у
нас есть огромная старая codebase (ну скажем mozilla или qt). А эта
codebase все равно была написана по стандартам конца прошлого века. Так
что продолжать в том же духе не столь уже сложно

> (и почему gcc,
> а не clang, MSVC, icc, ну и прочие?), а внятное донесение человеку

Потому  что мы в debian-russian. Были бы во freebsd-russian или
macos-russian, шла бы речь про clang. Ну и понятно на какой платформе
шла бы речь про MSVC.

Лично мне clang под Debian стал интересен примерно год назад. Когда в
postgres появился jit-компилятор условий на базе llvm. И вот тут-то
оказалось что нужен И gcc, И clang. До этого я игрался периодически с
clang-analyze но как-то особой полезности в этом инструменте не увидел.
(особенно если у тебя есть 50Мб codebase четверть вековой давности, в
которой оно находит этак тысяч пять false positives).

> идеи. Причём так, чтобы это ещё и быстро работало, не падая в местах,
> где кривые внешние данные или нехватка ресурсов.

Вот совместимость с линейкой компиляторов очень способствует "чтобы оно
не падало в местах, где...". Разные компиляторы вылавливают в качестве
Warning-ов разные огрехи. И если все их гонять с -Werror и аналогами...

Очень полезно для этой цели также тестироваться на разных процессорах.
Вот, скажем если в тестовой ферме есть спарк, ни один не выровненный
доступ к памяти не уйдет.

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

Так борьба с systemd тоже требует времени. Вопрос в том, на что
потратить время - на борьбу с поделиями поттерингов или на создание
альтернативы им.

Собственно проблема devuan как раз в том, что люди предпочитают бухтеть
про то, какой плохой поттеринг, вместо того чтобы засучить рукава и
сделать свое. Столлман 35 лет назад не бухтел про то какая плохая
Symbolics, а писал патчи для LMI.

> А обновление зависимостей, среди которых будет glibc, от которого 
> зависит всё, требует ещё больше времени.

Не будет там glibc в зависимостях. Я же предлагаю собрать компилятор, 
а не готовый бинарник тянуть. Я что-то в своей практике не припомню
случаев, чтобы софт такого класса, делаемый столь профессиональной
командой, не собирался бы на системе 2-3 летней давности. Там проблемы
обычно с системами более чем 15-летней давности бывают.

> При этом, если моей задачей было что-то от сборки компилятора в
> Devuan отличное, где-то на полпути я задумаюсь, что занимаюсь не тем,
> чем требовалось.
> 
> В случае, если у меня не будет выбора, я просто возьму Docker-образ с 
> новым компилятором.

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


> 
> Да я не плачусь, а указываю вам на вполне объективные причины,
> которые переход на Devuan блокируют.

Объективная причина тут одна - люди не хотят в этом участвовать.
Вы не хотите, я не хочу (разок сунулся, остался неуслышанным и плюнул,
все равно мне дистрибутивы с systemd поддерживать, так что знать его
придется).

> Ну и прекращение их выхода для старых версий библиотек (та же OpenSSL
> в конце года выкидывает какую-то версию) и прекращение официальной 
> разработки и поддержки старых диалектов, типа Python 2, на котором в 
> Devuan много что есть, тоже не стимулирует к переходу.

Подавляющее боьшинство крупных корпоративных заказчиков использует
системы на базе RHEL 6 и 7. Которые обе гораздо старее Devuan. Так что не
беспокойтесь по поводу прекращения поддержки софта менее чем
десятилетней давности.

>  > в ответе человеку, который вынужден
>  > 

Re: systemd-networkd

[Eugene Berdnikov]

On Thu, Jul 25, 2019 at 12:54:43AM +0300, Victor Wagner wrote:
> Здесь все не так. И война за свободу ПО, которую начал Столлман в
> середине 80-х - проиграна.

 Выиграна. Какую коробочку с WiFi или 4G ни возьми с полки, везде
 внутри линукс, а из лога, если он показывается, торчат busybox,
 dnsmasq и прочие ужасы... :) И каждый новый китаец, пришедший на рынок
 со своей новой коробочкой, пихает в неё тот же линукс. Потому что
 иначе ему на массовый рынок сегодня не выползти.

 Только не надо говорить, что, мол, настоящие пацаны будут покупать
 дорогие брендовые железки со своим вылизанным ядром внутри. Мы это
 уже проходили на примере Digital, Sun, HP и прочих динозавров...
 Будете делать ставки на Cisco, господа? :)

> Но я же говорю - битва за свободу ПО проиграна. Замена Free Software
> на Open Source, которая казалась в конце 90-х замечательным тактическим
> ходом, позволяющим привлечь на сторону свободы ресурсы копораций,
> оказалась троянским конем. Она дала возмодность примазаться де Иказам и
> Поттерингам и постепенно захватить всю экосистему.

 Экосистема живёт и развивается, это главный результат. А кто там
 "примазался" -- несущественные детали. Нужно смотреть выше, глобально.
 Поттеринг, между прочим, уже перекачивает в эту экосистему ресурсы IBM.
-- 
 Eugene Berdnikov

Re: systemd-networkd

[artiom]

> Прописывать адрес статически.

А, ну да, в IPv6 у каждого диапазон же.
Можно, конечно, особенно внутри сети.
Но сейчас всё настроено с IPv4 и автоматической выдачей адресов, не 
хочется переделывать.


> Здесь все не так. И война за свободу ПО, которую начал Столлман в
> середине 80-х - проиграна.

Хм, надо будет почитать...


> Если ты не можешь написать софт, который компилируется любым GCC начиная
> с 4.6 и конччая 9.1, то ты не умеешь программировать. Если ты скачал
> откуда-то такой софт, сотри немедленно. Потому что его автор не умеет
> программировать, и отсутствие поддержки компилятора имеющейся у тебя
> версии, скорее всего не единственная и не главная его проблема.
>

Ну это излишне сильное утверждение.
Я так думаю, вы на C++ не программируете.

Я могу написать такой софт, но делать этого не буду, потому что моя 
задача - не совместимость кода с линейкой компиляторов (и почему gcc, а 
не clang, MSVC, icc, ну и прочие?), а внятное донесение человеку идеи.
Причём так, чтобы это ещё и быстро работало, не падая в местах, где 
кривые внешние данные или нехватка ресурсов.


И я буду пользоваться возможностями 17 стандарта (тем же std::variant, 
если потребуется), а не тащить для этого костыли из Boost и десятка 
отдельных библиотек, только для того, чтобы поддержать сборку 
компилятором 10 летней давности.



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

Ну проблема в том, что это требует времени.
А обновление зависимостей, среди которых будет glibc, от которого 
зависит всё, требует ещё больше времени.
При этом, если моей задачей было что-то от сборки компилятора в Devuan 
отличное, где-то на полпути я задумаюсь, что занимаюсь не тем, чем 
требовалось.


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

Но привычка.


> Чай не Solaris 9 где собрать gcc так, чтобы им потом можно было 
собрать openssl было еще тем квестом, и требуемые для этого патчи к 
crt1.o почему-то gcc-шная команда принимать отказывалась.


Я даже представляю их мотивировку...


> Впрочем, я про Solaris еще могу страшных сказок порассказывать, как 
там gcc 5.3 работает с 128-битными целыми, передаваемыми в функцию.

> Помнится мы зимой в pgsql-hackers на эту тему неделю ругались, пока
> наконец не написали более-менее приличный тест для configure.
>
> Вообще, конечно, плакаться по поводу старых компиляторов в devuan,
> которому без году неделя

Да я не плачусь, а указываю вам на вполне объективные причины, которые 
переход на Devuan блокируют.
Кроме того, я не уверен, что все патчи безопасности из Debian туда 
перекочевали.
Ну и прекращение их выхода для старых версий библиотек (та же OpenSSL в 
конце года выкидывает какую-то версию) и прекращение официальной 
разработки и поддержки старых диалектов, типа Python 2, на котором в 
Devuan много что есть, тоже не стимулирует к переходу.



> в ответе человеку, который вынужден
> поддерживать софт для RHEL 6, SLES 11sp4 и МСВС-6.3 (про эльбрусы я
> вообще полмолчу)...
>

Так кто же вас заставляет поддерживать всякое старьё?
Если вам это нравится, - дело хозяйское: есть и люди, которые VAX с 
OpenVMS разворачивают в гараже.
Но я же не занимаюсь поддержкой таких систем, и то, что где-то ещё 
работает МСВС 3 с ядром версии 2.9, меня не заставляет восхититься 
относительной новизной Devuan, отставшего года на 4.



25.07.2019 00:54, Victor Wagner пишет:

В Wed, 24 Jul 2019 21:20:24 +0300
artiom  пишет:


  > Можно прописать ему (в отдельном файлике для каждого интерфейса)
  > что надо и что не надо от этого интерфейса требовать.
  >

Я же прописал для bond интерфейса, по крайней мере...
У вас MAC не прописаны, кстати.


Я ж говорю - у меня конфигурация проще. Мне не надо менять mac
интерфейсу.
  

  > У меня, правда, более простая конфигурация - не бондинг, а бридж
  > (куда потом включаются tun-интерфейсы qemu-шных виртуалок и veth
  > lxc-шных контейнеров. Зато IPv4 у него статический (потому как
  > серый) а ipv6 - динамический (потому как globally routable).

В том и дело: не хочу статический, хочу DHCP, но всегда одинаковый.


  > ipv6 - динамический (потому как globally routable).

Если это сервер, как жить?


Прописывать адрес статически.




  > Потому что есть компания людей, которая считает, что Debian is not
  > about choice. И это они как-то открытым текстом в debian-devel
  > декларировали.

Скажите, а мне одному кажется, что здесь что-то не так?


Здесь все не так. И война за свободу ПО, которую начал Столлман в
середине 80-х - проиграна.


Вот, например, идеологии Linux это не противоречит?


Linux это ядро. Его идеологии совершенно пофиг как в юзерспейсе
конфигурируются интерфейсы.

Вот идеологии GNU-системы, описанной Столлманом в статье Opening The
Software toolbox оно противоречит, и еще как.

Но я же говорю - битва за свободу ПО проиграна. Замена Free Software
на Open Source, которая казалась в конце 90-х замечательным тактическим
ходом, 

Re: systemd-networkd

[Victor Wagner]

В Wed, 24 Jul 2019 21:20:24 +0300
artiom  пишет:

>  > Можно прописать ему (в отдельном файлике для каждого интерфейса)
>  > что надо и что не надо от этого интерфейса требовать.
>  >  
> 
> Я же прописал для bond интерфейса, по крайней мере...
> У вас MAC не прописаны, кстати.

Я ж говорю - у меня конфигурация проще. Мне не надо менять mac
интерфейсу. 
 
>  > У меня, правда, более простая конфигурация - не бондинг, а бридж
>  > (куда потом включаются tun-интерфейсы qemu-шных виртуалок и veth
>  > lxc-шных контейнеров. Зато IPv4 у него статический (потому как
>  > серый) а ipv6 - динамический (потому как globally routable).  
> 
> В том и дело: не хочу статический, хочу DHCP, но всегда одинаковый.
> 
> 
>  > ipv6 - динамический (потому как globally routable).  
> 
> Если это сервер, как жить?

Прописывать адрес статически. 

> 
> 
>  > Потому что есть компания людей, которая считает, что Debian is not
>  > about choice. И это они как-то открытым текстом в debian-devel
>  > декларировали.  
> 
> Скажите, а мне одному кажется, что здесь что-то не так?

Здесь все не так. И война за свободу ПО, которую начал Столлман в
середине 80-х - проиграна.

> Вот, например, идеологии Linux это не противоречит?

Linux это ядро. Его идеологии совершенно пофиг как в юзерспейсе
конфигурируются интерфейсы.

Вот идеологии GNU-системы, описанной Столлманом в статье Opening The
Software toolbox оно противоречит, и еще как.

Но я же говорю - битва за свободу ПО проиграна. Замена Free Software
на Open Source, которая казалась в конце 90-х замечательным тактическим
ходом, позволяющим привлечь на сторону свободы ресурсы копораций,
оказалась троянским конем. Она дала возмодность примазаться де Иказам и
Поттерингам и постепенно захватить всю экосистему.

> Debian, конечно, не Linux, однако ядро основное (а сейчас уже может и 
> единственное)...
> 
> 
>  > Увы, не поможет. Те, кто согласны с этим утверждением ушли на
>  > devuan.  
> 
> Который отстаёт на две версии от и так далеко не свежайшего Debian
> (даже с учётом бэк-портов), что особенно актуально с выходом нового 
> компилятора (ага, "компильте в Docker или на CI", но мне это иногда 
> менее удобно).

Если ты не можешь написать софт, который компилируется любым GCC начиная
с 4.6 и конччая 9.1, то ты не умеешь программировать. Если ты скачал
откуда-то такой софт, сотри немедленно. Потому что его автор не умеет
программировать, и отсутствие поддержки компилятора имеющейся у тебя
версии, скорее всего не единственная и не главная его проблема.

Но вообще, если нужен свеженький компилятор в deuvian, в чем проблема
его собрать самому в пакет (а то и мейнтейнером заделаться). Чай не
Solaris 9 где собрать gcc так, чтобы им потом можно было собрать openssl
было еще тем квестом, и требуемые для этого патчи к crt1.o почему-то
gcc-шная команда принимать отказывалась. 

Впрочем, я про Solaris еще могу страшных сказок порассказывать, как там
gcc 5.3 работает с 128-битными целыми, передаваемыми в функцию.
Помнится мы зимой в pgsql-hackers на эту тему неделю ругались, пока
наконец не написали более-менее приличный тест для configure.

Вообще, конечно, плакаться по поводу старых компиляторов в devuan,
которому без году неделя, в ответе человеку, который вынужден
поддерживать софт для RHEL 6, SLES 11sp4 и МСВС-6.3 (про эльбрусы я
вообще полмолчу)...

> в
-- 
   Victor Wagner 

Re: systemd-networkd

[artiom]

> Можно прописать ему (в отдельном файлике для каждого интерфейса) что
> надо и что не надо от этого интерфейса требовать.
>

Я же прописал для bond интерфейса, по крайней мере...
У вас MAC не прописаны, кстати.
Да и он его меняет, просто не сразу, видимо...


> У меня, правда, более простая конфигурация - не бондинг, а бридж (куда
> потом включаются tun-интерфейсы qemu-шных виртуалок и veth lxc-шных
> контейнеров. Зато IPv4 у него статический (потому как серый) а
> ipv6 - динамический (потому как globally routable).

В том и дело: не хочу статический, хочу DHCP, но всегда одинаковый.


> ipv6 - динамический (потому как globally routable).

Если это сервер, как жить?


> Потому что есть компания людей, которая считает, что Debian is not about
> choice. И это они как-то открытым текстом в debian-devel декларировали.

Скажите, а мне одному кажется, что здесь что-то не так?
Вот, например, идеологии Linux это не противоречит?
Debian, конечно, не Linux, однако ядро основное (а сейчас уже может и 
единственное)...



> Увы, не поможет. Те, кто согласны с этим утверждением ушли на devuan.

Который отстаёт на две версии от и так далеко не свежайшего Debian (даже 
с учётом бэк-портов), что особенно актуально с выходом нового 
компилятора (ага, "компильте в Docker или на CI", но мне это иногда 
менее удобно).



24.07.2019 15:03, Victor Wagner пишет:> On Wed, 24 Jul 2019 14:03:34 +0300
> Н. Артём  wrote:
>
>> Есть система, которая имеет SSH сервер в initramfs (dropbear).
>> Интерфейсы связаны через бондинг в bond0, на котором этот сервер
>> работает. Роутер выдаёт бондинг интерфейсу через DHCP фиксированный
>> IP по MAC.
>>
>> Когда система загружается, сервер убивается, бондинг разрушается и
>> запускается "нормальная" сетевая подсистема, которая настраивает
>> бондинг и поднимает OpenSSH. MAC bond0 не изменяется, IP выдаётся тот
>> же.
>>
>> Когда был Stretch, не было проблем, всё работало.
>> Обновил на Buster - всё сломалось.
>>
>> Выяснилось, что недавно пришедший на замену работающей подсистеме,
>> networkd-systemd всё ломает. Если я не опускаю бондинг, его
>> расхреначивает, и он требует IP для каждого адаптера. Когда я
>
> C этим мне все-таки удалось побороться.
>
> Можно прописать ему (в отдельном файлике для каждого интерфейса) что
> надо и что не надо от этого интерфейса требовать.
>
> У меня, правда, более простая конфигурация - не бондинг, а бридж (куда
> потом включаются tun-интерфейсы qemu-шных виртуалок и veth lxc-шных
> контейнеров. Зато IPv4 у него статический (потому как серый) а
> ipv6 - динамический (потому как globally routable).
>
> Получилось примерно так:
> ==> /etc/systemd/network/br0.netdev <==
> [NetDev]
> Name=br0
> Kind=bridge
>
>
> ==> /etc/systemd/network/br0.network <==
> [Match]
> Name=br0
> [Network]
> Address=192.168.217.1/25
> Gateway=192.168.217.63
> Broadcast=192.168.217.128
> DHCP=ipv6
> DNS=127.0.0.1
>
> ==> /etc/systemd/network/eth0.network <==
> [Match]
> Name=eth0
> [Network]
> Bridge=br0
> DHCP=no
>
> Вообще в *.network можно вписать Unmanaged=yes и
> тогда, по утверждению документации, systemd-networkd вообще не будет
> трогать этот интерфейс.
>
> И можно будет конфигурировать его через ipupdown (это же имеется в виду
> под старой подсистемой), не снося systemd-networkd.
>
> У меня, правда, сходу не получилось. Потому что я не ожидал от ini-style
> конфигурационного файла того, что пробелы вокруг знака равенства
> недопустимы.
>
>> Отсюда вопросы (реально не в курсе, так что может не в тему):
>>
>> - Что я делаю не так?
>> - Зачем поменяли работающее на это?
>> - Повинен в этом Леннар или это последователи?
>
> Потому что есть компания людей, которая считает, что Debian is not about
> choice. И это они как-то открытым текстом в debian-devel декларировали.
>
>> - Что их не устраивало в resolv.conf?
>> - Стоит ли намекнуть маинтайнерам дистрибутива на то, что это
>> какая-то сильно непрозрачная, кривая и неочевидная в настройке херня?
>
> Увы, не поможет. Те, кто согласны с этим утверждением ушли на devuan.
>
> --
>

Re: systemd-networkd

[Victor Wagner]

On Wed, 24 Jul 2019 14:03:34 +0300
Н. Артём  wrote:

> Есть система, которая имеет SSH сервер в initramfs (dropbear).
> Интерфейсы связаны через бондинг в bond0, на котором этот сервер
> работает. Роутер выдаёт бондинг интерфейсу через DHCP фиксированный
> IP по MAC.
> 
> Когда система загружается, сервер убивается, бондинг разрушается и
> запускается "нормальная" сетевая подсистема, которая настраивает
> бондинг и поднимает OpenSSH. MAC bond0 не изменяется, IP выдаётся тот
> же.
> 
> Когда был Stretch, не было проблем, всё работало.
> Обновил на Buster - всё сломалось.
> 
> Выяснилось, что недавно пришедший на замену работающей подсистеме,
> networkd-systemd всё ломает. Если я не опускаю бондинг, его
> расхреначивает, и он требует IP для каждого адаптера. Когда я

C этим мне все-таки удалось побороться.

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

У меня, правда, более простая конфигурация - не бондинг, а бридж (куда
потом включаются tun-интерфейсы qemu-шных виртуалок и veth lxc-шных
контейнеров. Зато IPv4 у него статический (потому как серый) а
ipv6 - динамический (потому как globally routable).

Получилось примерно так:
==> /etc/systemd/network/br0.netdev <==
[NetDev]
Name=br0
Kind=bridge


==> /etc/systemd/network/br0.network <==
[Match]
Name=br0
[Network]
Address=192.168.217.1/25
Gateway=192.168.217.63
Broadcast=192.168.217.128
DHCP=ipv6
DNS=127.0.0.1

==> /etc/systemd/network/eth0.network <==
[Match]
Name=eth0
[Network]
Bridge=br0
DHCP=no

Вообще в *.network можно вписать Unmanaged=yes и
тогда, по утверждению документации, systemd-networkd вообще не будет
трогать этот интерфейс.

И можно будет конфигурировать его через ipupdown (это же имеется в виду
под старой подсистемой), не снося systemd-networkd.

У меня, правда, сходу не получилось. Потому что я не ожидал от ini-style
конфигурационного файла того, что пробелы вокруг знака равенства
недопустимы.

> Отсюда вопросы (реально не в курсе, так что может не в тему):
> 
> - Что я делаю не так?
> - Зачем поменяли работающее на это?
> - Повинен в этом Леннар или это последователи?

Потому что есть компания людей, которая считает, что Debian is not about
choice. И это они как-то открытым текстом в debian-devel декларировали.

> - Что их не устраивало в resolv.conf?
> - Стоит ли намекнуть маинтайнерам дистрибутива на то, что это
> какая-то сильно непрозрачная, кривая и неочевидная в настройке херня?

Увы, не поможет. Те, кто согласны с этим утверждением ушли на devuan.

--  

Re: [systemd] Как запустить службу со StopWhenUnneeded=true?

[Tim Sattarov]

On 6/12/19 9:38 PM, Dmitry Alexandrov wrote:
> Добрых всем суток.
>
> Собственно, есть служба со StopWhenUnneeded=true.  На приказ включиться она 
> изображает, что включается, и немедленно же выключается.
>
> Есть ли какой более элегантный способ ее разово запустить, чем написать 
> зависящую от нее заглушку?
А если сделать копию этого сервиса, без опции StopWhenUnneeded=true, и без 
автоматического старта,
только вручную?
и возможно с конфликтом между ручным сервисом и автоматическим, чтобы оба 
одновременно не запускались.

Re: [systemd-journald] Бессистемно теряется вывод пользовательской службы

[Dmitry Alexandrov]

Tim Sattarov  wrote:
> On 6/15/19 9:52 PM, Dmitry Alexandrov wrote:
>> Дано: Дебиан ГНУ/Линукс 9.9, искоробочный systemd 232.
>>
>> Из-под рута все, вроде бы, в порядке:
..
>> # for _ in {1..10}; do systemctl start test-echo.service; sleep 1; done
>> Starting test-echo.service...
>> Hi there.
>> Started test-echo.service.
>> Starting test-echo.service...
>> Hi there.
>> Started test-echo.service.
>> Starting test-echo.service...
>> Hi there.
>> Started test-echo.service.
..
>> А теперь то же самое, но с пользовательской службой:
..
>> $ for _ in {1..10}; do systemctl --user start test-echo.service; sleep 1; 
>> done
>> Starting test-echo.service...
>> Hi there.
>> Started test-echo.service.
>> Starting test-echo.service...
>> Started test-echo.service.
>> Starting test-echo.service...
>> Started test-echo.service.
..
>
> А пробовал смотреть в логи системы вокруг (самого systemd) на предмет 
> throttle/rate limit?

Да, ничего такого.  Более того, в нефильтрованном журнале и вывод 
test-echo.service весь есть.  То есть дело явно не в rate limit’е (тем более, 
что он, кажется, единый для всего журнала; по крайней мере, где его еще 
настроить, кроме как в /etc/systemd/journald.conf, я не знаю).

Я погуглил получше, и, думаю, что нашел релевантный баг от февраля 2017-го —  
«Journalctl miss to show logs from unit» [0]:

Michal Sekletar:
| This is a known issue. systemd-journald sometimes fails to record information 
about unit from which log message originates. There is a higher probability of 
hitting this problem if the process that logs the message is short lived.

| It's just that for some log messages that originate from short lived 
processes journald can't figure out respective cgroup (unit). Thus you will not 
see those log lines if you apply filtering based on unit name. *We can't do 
anything about this* until kernel gives us a way to gather cgroup information 
in non racy way. But then again, logs are there and your first command that 
uses time based filtering proves that.

(выделение мое)

Баг закрыт как повтор бага от 2013 года под маловнятной темой «journald: we 
need a way to get audit, cgroup, ... information attached to log...» [1], 
который заканчивается жизнеутверждающим вопросом:

Rich Megginson 2017-08-11 16:42:37 UTC:
| What ever happened with the upstream [Linux] patch for this?

[0] https://bugzilla.redhat.com/1426152
[1] https://bugzilla.redhat.com/963620


signature.asc
Description: PGP signature

Re: [systemd-journald] Бессистемно теряется вывод пользовательской службы

[Tim Sattarov]

On 6/17/19 7:06 PM, Tim Sattarov wrote:
> On 6/15/19 9:52 PM, Dmitry Alexandrov wrote:
>> Добрых суток уважаемой рассылке.
>>
>> Дано: Дебиан ГНУ/Линукс 9.9, искоробочный systemd 232.
>>
>> Из-под рута все, вроде бы, в порядке:
>> 
>> Как это понимать?
> А пробовал смотреть в логи системы вокруг (самого systemd) на предмет 
> throttle/rate limit?
только что проверил у себя, вроде всё ок, ничего не теряется (я на buster, 
systemd 241-5)

Re: [systemd-journald] Бессистемно теряется вывод пользовательской службы

[Tim Sattarov]

On 6/15/19 9:52 PM, Dmitry Alexandrov wrote:
> Добрых суток уважаемой рассылке.
>
> Дано: Дебиан ГНУ/Линукс 9.9, искоробочный systemd 232.
>
> Из-под рута все, вроде бы, в порядке:
> 
> Как это понимать?
А пробовал смотреть в логи системы вокруг (самого systemd) на предмет 
throttle/rate limit?

Re: [systemd] Как запустить службу со StopWhenUnneeded=true?

[Dmitry Alexandrov]

Pavel Volkov  wrote:
> On четверг, 13 июня 2019 г. 04:38:19 MSK, Dmitry Alexandrov wrote:
>> Собственно, есть служба со StopWhenUnneeded=true.  На приказ включиться она 
>> изображает, что включается, и немедленно же выключается.
>>
>> Есть ли какой более элегантный способ ее разово запустить, чем написать 
>> зависящую от нее заглушку?
>
> Можно типа так:
> systemctl add-wants --runtime default.target myservice.service
> systemctl start myservice.service

Ну это хуже, чем то, с чего начали: создать заглушку myservice.target типа:

[Unit]
Wants=myservice.service

и запускать уже ее.

Ее потом можно так и оставить на будущее, а лишнюю зависимость у ‘default’а 
надо будет не забыть подчистить, причем вручную, ибо команды типа 
‘remove-wants’ для этого, как я вижу, не предусмотрено.


signature.asc
Description: PGP signature

Re: [systemd] Как запустить службу со StopWhenUnneeded=true?

[Dmitry Alexandrov]

Igor Savluk  wrote:
> On 13/06/2019 04.38, Dmitry Alexandrov wrote:
>> Собственно, есть служба со StopWhenUnneeded=true.  На приказ включиться она 
>> изображает, что включается, и немедленно же выключается.
>>
>> Есть ли какой более элегантный способ ее разово запустить, чем написать 
>> зависящую от нее заглушку?
>>
> Юзать systemd timer?

Не-а.  Пуск по таймеру же тождественен просто ‘start’у — точно так же все будет:
$ systemd-run --user --on-active=1s --unit=xeyes.service
Running timer as unit: xeyes.timer
$ systemctl --user status xeyes.service
● xeyes.service - xeyes
   Loaded: loaded (/home/dag/.config/systemd/user/xeyes.service; static; vendor preset: enabled)
   Active: inactive (dead)

Jun 14 00:51:59 martha systemd[3822]: Started xeyes.
Jun 14 00:51:59 martha systemd[3822]: xeyes.service: Unit not needed anymore. Stopping.
Jun 14 00:51:59 martha systemd[3822]: Stopping xeyes...
Jun 14 00:51:59 martha systemd[3822]: Stopped xeyes.
Ну или я не вкурил в суть предложения.


signature.asc
Description: PGP signature

Re: [systemd] Как запустить службу со StopWhenUnneeded=true?

[Pavel Volkov]

On четверг, 13 июня 2019 г. 04:38:19 MSK, Dmitry Alexandrov wrote:

Добрых всем суток.

Собственно, есть служба со StopWhenUnneeded=true.  На приказ 
включиться она изображает, что включается, и немедленно же 
выключается.


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





Можно типа так:
systemctl add-wants --runtime default.target myservice.service
systemctl start myservice.service

Re: [systemd] Как запустить службу со StopWhenUnneeded=true?

[Igor Savluk]

On 13/06/2019 04.38, Dmitry Alexandrov wrote:

Добрых всем суток.

Собственно, есть служба со StopWhenUnneeded=true.  На приказ включиться она 
изображает, что включается, и немедленно же выключается.

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


Юзать systemd timer?

Re: systemd ssh logout at reboot-restart

[sergio]

On 06/06/2019 19:39, Геннадий Ковалёв wrote:

> И не должен выключаться, выключать должен poweroff. Если
> поведение было другое, то это был глюк.

Я переформулирую для упоротых:

"Раньше поведение команды halt регулировалось файлом /etc/default/halt"

% cat /etc/default/halt
# Default behaviour of shutdown -h / halt. Set to "halt" or "poweroff".
HALT=poweroff


-- 
sergio.

Re: systemd ssh logout at reboot-restart

[Геннадий Ковалёв]

В Пт, 31/05/2019 в 17:12 +0300, sergio пишет:
> Говоришь halt --- хост не выключается

Обсуждали уже. И не должен выключаться, выключать должен poweroff. Если
поведение было другое, то это был глюк.

Re: systemd ssh logout at reboot-restart

[Igor Savluk]

On 02/06/2019 18.24, Andrey Jr. Melnikov wrote:

sergio  wrote:

On 29/05/2019 22:13, Andrey Tataranovich wrote:



А на хосте B пакет libpam-systemd установлен?



Нет. А должен?



Спрошу иначе. Кто вылогинивает меня при ребуте системы на sysvinit,
обязан ли он это делать и от чего должен зависеть libpam-systemd что бы
это поведение не ломалось?

Тот-же ssh. Ибо в случае с sysvinit - он завершается до того, как потушат
сеть. В случае с systemd - что и в каком порядке он потушит - незнает никто.
Ну а чё? зато - быстро.


Самая большая проблема с systemd которую я наблюдаю --- это изменение
поведения. Говоришь halt --- хост не выключается, говоришь apt install
radvd --- radvd запущен, но только до первого ребута, говоришь reboot
--- sshd не вылогинивает...

Ха-ха-ха, редхат заботиться о вас :)

PS: Включи в ssh_config `ServerAliveInterval 30' и забей на Лёнины поделья.


Ты придумал и написал что-то получше?

Re: systemd ssh logout at reboot-restart

[Andrey Jr. Melnikov]

sergio  wrote:
> On 29/05/2019 22:13, Andrey Tataranovich wrote:

> > А на хосте B пакет libpam-systemd установлен?

> Нет. А должен?

> Спрошу иначе. Кто вылогинивает меня при ребуте системы на sysvinit,
> обязан ли он это делать и от чего должен зависеть libpam-systemd что бы
> это поведение не ломалось?
Тот-же ssh. Ибо в случае с sysvinit - он завершается до того, как потушат
сеть. В случае с systemd - что и в каком порядке он потушит - незнает никто.
Ну а чё? зато - быстро.

> Самая большая проблема с systemd которую я наблюдаю --- это изменение
> поведения. Говоришь halt --- хост не выключается, говоришь apt install
> radvd --- radvd запущен, но только до первого ребута, говоришь reboot
> --- sshd не вылогинивает...
Ха-ха-ха, редхат заботиться о вас :)

PS: Включи в ssh_config `ServerAliveInterval 30' и забей на Лёнины поделья.

Re: systemd ssh logout at reboot-restart

[Коротаев Руслан]

sergio  пишет:

> Спрошу иначе. Кто вылогинивает меня при ребуте системы на sysvinit,
> обязан ли он это делать и от чего должен зависеть libpam-systemd что бы
> это поведение не ломалось?
> 
> 
> Самая большая проблема с systemd которую я наблюдаю --- это изменение
> поведения. Говоришь halt --- хост не выключается, говоришь apt install
> radvd --- radvd запущен, но только до первого ребута, говоришь reboot
> --- sshd не вылогинивает...

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

Как альтернативу radvd, можно использовать systemd, он умеет раздавать
префикс для IPv6 из коробки (через systemd.network).

-- 
Коротаев Руслан
https://blog.kr.pp.ru


smime.p7s
Description: S/MIME cryptographic signature

Re: systemd inittab

[sergio]

On 23/05/2019 10:26, Victor Wagner wrote:

> Может поискать что другое для управления kvm-виртуалками.

Может просто libvirt-daemon-system не должен зависеть от policykit-1?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897936

Гентушники говорят, что у них libvirt отлично без systemd работает.

Но дебиановкие мэинтейнеры не спешат:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897936

Как я понял, надо просто попробовать убрать policykit-1 из зависимостей
libvirt-daemon-system.

-- 
sergio.

Re: systemd ssh logout at reboot-restart

[sergio]

On 29/05/2019 22:13, Andrey Tataranovich wrote:

> А на хосте B пакет libpam-systemd установлен?

Нет. А должен?

Спрошу иначе. Кто вылогинивает меня при ребуте системы на sysvinit,
обязан ли он это делать и от чего должен зависеть libpam-systemd что бы
это поведение не ломалось?


Самая большая проблема с systemd которую я наблюдаю --- это изменение
поведения. Говоришь halt --- хост не выключается, говоришь apt install
radvd --- radvd запущен, но только до первого ребута, говоришь reboot
--- sshd не вылогинивает...


-- 
sergio.

Re: systemd ssh logout at reboot-restart

[Andrey Tataranovich]

On Wed, 22 May 2019 21:29:58 +0300
sergio  wrote:

> Когда я говорю reboot или poweroff через ssh на хосте A, сессия, как
> ей и положено, закрывается:
> 
> Connection to A closed by remote host.
> Connection to A closed.
> 
> 
> А вот на хосте B ничего не происходит, хост уже выключился, а мёртвая
> сессия продолжает висеть.

А на хосте B пакет libpam-systemd установлен? Насколько я помню именно
этот пакет отвечает за "разлогинивание" при reboot/poweroff.

-- 
Best regards,
Andrey Tataranovich

Re: systemd inittab

[sergio]

On 24/05/2019 15:28, Victor Wagner wrote:


> SPICE хорош

Для графики --- безусловно.


-- 
sergio.

Re: systemd inittab

[Victor Wagner]

On Fri, 24 May 2019 11:25:00 +0300
sergio  wrote:

> On 24/05/2019 09:51, Victor Wagner wrote:
> 
> > Ну можно на мой vws посмотреть. Вроде все перечисленное он делает.
> > 
> > https://www.wagner.pp.ru/fossil/vws  
> 
> SPICE ради serial console? Это клиент нужен, что бы ходить в него,

А как иначе работать с консолью, ну скажем Windows server? 
SPICE хорош тем что лучше всех других возможных вариантов интегрирует
окно виртуальной машины в десктоп. Там и мышь не захватывается в окне,
в отличие от sdl-интерфейса qemu, и clipboard общий.

Все равно же работаешь на своей рабочей станции в какой-нибудь
графической среде. Потому что браузер нужен, читалка pdf-ов нужна.

> порты ещё прокидывать. Нет. Плохо объяснил, я хочу serial console
> через ssh, как в libvirt (который её через /dev/pts отдаёт)

Ну, порты прокидывать - это у меня бродит в голове такая мысль -
сделать в vws прозрачную поддержку ssh. Чтобы можно было указать
имя виртуалки в виде "имя хоста:имя виртуалки" и оно бы само разобралось
как что запускать (при условии правильно заполненных authorized_keys).

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

-- 

Re: systemd inittab

[sergio]

On 24/05/2019 09:51, Victor Wagner wrote:

> Ну можно на мой vws посмотреть. Вроде все перечисленное он делает.
> 
> https://www.wagner.pp.ru/fossil/vws

SPICE ради serial console? Это клиент нужен, что бы ходить в него, порты
ещё прокидывать. Нет. Плохо объяснил, я хочу serial console через ssh,
как в libvirt (который её через /dev/pts отдаёт)


-- 
sergio.

Re: systemd inittab

[Victor Wagner]

On Fri, 24 May 2019 04:49:17 +0300
sergio  wrote:

> On 23/05/2019 10:26, Victor Wagner wrote:
> 
> 
> > Написать unit-файл, который будет это делать. И кстати и respawn
> > средствами systemd организовать можно будет.  
> 
> Написал, как дебажить?

Я бы использовал для запуска процессов на свободном терминале
программу openvt. Она и переменные среды выставит какие надо, и
настройки терминала. 

Судя по тому, что написано ниже, терминал настраивать tty_clock и сам
умеет. Но, будучи честной программой на ncurses, нуждается в переменной
TERM указывающей, какой тип терминала.

Если мы видим, что процесс убит сигналом, надо в первую очередь
разрешить ему оставлять core dump.

Добавив для этого в unit-файл строчку LimitCORE=infinity, ну и
позаботившись о том, чтобы текущая директория процесса была доступна
ему на запись (либо чтобы ядро знало, что надо core в какое-то другое
место писать).



> 
> # cat /etc/systemd/system/tty_clock.service 
> [Unit]
> Description=tty-clock
> 
> [Service]
> Environment="LANG=ru_RU.UTF-8 TERM=linux"
> ExecStart=/usr/bin/tty-clock -x -s -c -C 7 -f '%%F %%A' -T /dev/tty10
> ExecStartPost=chvt 10
> Restart=on-failure
> 
> [Install]
> WantedBy=default.target
> 
> 
> # systemctl status tty_clock.service 
> ● tty_clock.service - tty-clock
>Loaded: loaded (/etc/systemd/system/tty_clock.service; enabled;
> vendor preset: enabled) Active: failed (Result: signal) since Fri
> 2019-05-24 04:41:08 MSK; 5s ago Process: 13038
> ExecStart=/usr/bin/tty-clock -x -s -c -C 7 -f %F %A -T /dev/tty10
> (code=killed, signal=ABRT) Process: 13039 ExecStartPost=/bin/chvt 10
> (code=exited, status=0/SUCCESS) Main PID: 13038 (code=killed,
> signal=ABRT)
> 
> systemd[1]: tty_clock.service: Service RestartSec=100ms expired,
> scheduling restart. systemd[1]: tty_clock.service: Scheduled restart
> job, restart counter is at 5. systemd[1]: Stopped tty-clock.
> systemd[1]: tty_clock.service: Start request repeated too quickly.
> systemd[1]: tty_clock.service: Failed with result 'signal'.
> systemd[1]: Failed to start tty-clock.
> systemd[1]: tty_clock.service: Start request repeated too quickly.
> systemd[1]: tty_clock.service: Failed with result 'signal'.
> systemd[1]: Failed to start tty-clock.
> 
> 
> 
> 
> Так работает:
> 
> [Service]
> ExecStart=/usr/local/bin/tty_clock
> 
> 
> # cat /usr/local/bin/tty_clock
> #!/bin/sh
> 
> LANG=ru_RU.UTF-8 TERM=linux /usr/bin/tty-clock -x -s -c -C 7 -f '%F
> %A' -T /dev/tty10 (4:47:08)[root@boo:system]# 
> 
> 

Re: systemd inittab

[Victor Wagner]

On Fri, 24 May 2019 04:20:39 +0300
sergio  wrote:

> On 23/05/2019 10:26, Victor Wagner wrote:
> 
> > Может поискать что другое для управления kvm-виртуалками.  
> 
> Я пробовал, но не нашёл.
> 
> > Я после некоторой возни с libvirt плюнул и вообще свой скрипт на
> > питоне написал.   
> 
> Я пробовал, libvirt победил. Требования просты:
> 
> 1. Запуск при загрузке хоста.
> 2. Остановка при перезагрузке/выключении хоста.
> 3. Консоль.

Ну можно на мой vws посмотреть. Вроде все перечисленное он делает.

https://www.wagner.pp.ru/fossil/vws

Re: systemd inittab

[sergio]

On 23/05/2019 10:26, Victor Wagner wrote:


> Написать unit-файл, который будет это делать. И кстати и respawn
> средствами systemd организовать можно будет.

Написал, как дебажить?

# cat /etc/systemd/system/tty_clock.service 
[Unit]
Description=tty-clock

[Service]
Environment="LANG=ru_RU.UTF-8 TERM=linux"
ExecStart=/usr/bin/tty-clock -x -s -c -C 7 -f '%%F %%A' -T /dev/tty10
ExecStartPost=chvt 10
Restart=on-failure

[Install]
WantedBy=default.target


# systemctl status tty_clock.service 
● tty_clock.service - tty-clock
   Loaded: loaded (/etc/systemd/system/tty_clock.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: signal) since Fri 2019-05-24 04:41:08 MSK; 5s ago
  Process: 13038 ExecStart=/usr/bin/tty-clock -x -s -c -C 7 -f %F %A -T 
/dev/tty10 (code=killed, signal=ABRT)
  Process: 13039 ExecStartPost=/bin/chvt 10 (code=exited, status=0/SUCCESS)
 Main PID: 13038 (code=killed, signal=ABRT)

systemd[1]: tty_clock.service: Service RestartSec=100ms expired, scheduling 
restart.
systemd[1]: tty_clock.service: Scheduled restart job, restart counter is at 5.
systemd[1]: Stopped tty-clock.
systemd[1]: tty_clock.service: Start request repeated too quickly.
systemd[1]: tty_clock.service: Failed with result 'signal'.
systemd[1]: Failed to start tty-clock.
systemd[1]: tty_clock.service: Start request repeated too quickly.
systemd[1]: tty_clock.service: Failed with result 'signal'.
systemd[1]: Failed to start tty-clock.




Так работает:

[Service]
ExecStart=/usr/local/bin/tty_clock


# cat /usr/local/bin/tty_clock
#!/bin/sh

LANG=ru_RU.UTF-8 TERM=linux /usr/bin/tty-clock -x -s -c -C 7 -f '%F %A' -T 
/dev/tty10
(4:47:08)[root@boo:system]# 


-- 
sergio.

Re: systemd inittab

[sergio]

On 23/05/2019 10:26, Victor Wagner wrote:

> Может поискать что другое для управления kvm-виртуалками.

Я пробовал, но не нашёл.

> Я после некоторой возни с libvirt плюнул и вообще свой скрипт на
> питоне написал. 

Я пробовал, libvirt победил. Требования просты:

1. Запуск при загрузке хоста.
2. Остановка при перезагрузке/выключении хоста.
3. Консоль.


>> 1. почему меня после загрузки переключает на 10 vt?
> 
> Видимо потому, что переключение был прописно не в inittab а где-то еще.

И правда, сама строчка "10:2345:respawn:/usr/local/bin/tty_clock" же
ничего не переключает.


-- 
sergio.

Re: systemd inittab

[Victor Wagner]

On Wed, 22 May 2019 23:43:45 +0300
sergio  wrote:

> 
> Был хост, в /etc/inittab которого было написано:
> 
> 10:2345:respawn:/usr/local/bin/tty_clock
> 
> 
> На хосте стоит libvirt-daemon-system для запуска kvm виртуалок,
> который требует systemd, и для которого стоял systemd-shim пока там
> был stretch. Я обновил его до buster, systemd-shim на нём нет и
> systemd там в полный рост.

Может поискать что другое для управления kvm-виртуалками.
Я после некоторой возни с libvirt плюнул и вообще свой скрипт на питоне
написал. 



> 1. почему меня после загрузки переключает на 10 vt?

Видимо потому, что переключение был прописно не в inittab а где-то еще.
 
> 2. как запустить tty_clock на vt 10?

Написать unit-файл, который будет это делать. И кстати и respawn
средствами systemd организовать можно будет.
> 
> 

Re: systemd nfs background mount

[Stanislav Vlasov]

22.05.2019, sergio написал(а):

> A:/share /mnt/share nfs4 auto,nodev,bg,rw 0 0
[...]
> но если потом вдруг перезагрузиться, то повиснет навечно (пока не
> появится A):
>
> A start job is running for /mnt ( / no limit)

Некоторые рекомендуют сиё монтировать с добавлением x-systemd.automount,noauto
Правда, хз, что будет, если при этом зайти в каталог. Подозреваю, что
подвисание и надо добавить ещё и intr.

-- 
Stanislav

Re: systemd halt

[Evgeny Zubok]

sergio  writes:

> On 13/10/2018 16:07, Evgeny Zubok wrote:
>
>> Не пользуюсь systemd, поэтому поинтересуюсь: systemd каким-нибудь
>> образом использует прежние настройки системы из
>> /etc/default? Предполагаю, что нет. Но если использует, то там есть
>> файлик /etc/default/halt, в котором надо указать HALT=poweroff. Тогда он
>> по halt будет выключать машину.
>>
>
> То есть это баг, можно смело вешать на пакет systemd?

Нет, halt по умолчанию - это останов без выключения питания, poweroff -
останов с выключением питания. Если нужно поменять действие halt, то
надо это специально ему высказать. Я не знаю просто, где в systemd можно
высказаться по этому поводу и можно ли. Смотри документацию.

Re: systemd halt

[artiom]

Спасибо. Тоже эта неприятная мелочь раздражала.

13.10.2018 16:27, Evgeny Zubok пишет:

Evgeny Zubok  writes:


sergio  writes:


Как правильно выключать debian с systemd?

говорю sudo halt, система доходит до "reboot: System halted" и всё.


Не пользуюсь systemd, поэтому поинтересуюсь: systemd каким-нибудь
образом использует прежние настройки системы из
/etc/default? Предполагаю, что нет. Но если использует, то там есть
файлик /etc/default/halt, в котором надо указать HALT=poweroff. Тогда он
по halt будет выключать машину.


Если что, то эта переменная среды описана в man shutdown в разделе HALT
OR POWEROFF в конце. В общем, задача сводится к тому, чтобы установить
эту переменную среды при помощи этой вашей systemd, то есть найти
правильное место.

Re: systemd halt

[sergio]

On 13/10/2018 16:07, Evgeny Zubok wrote:


Не пользуюсь systemd, поэтому поинтересуюсь: systemd каким-нибудь
образом использует прежние настройки системы из
/etc/default? Предполагаю, что нет. Но если использует, то там есть
файлик /etc/default/halt, в котором надо указать HALT=poweroff. Тогда он
по halt будет выключать машину.



То есть это баг, можно смело вешать на пакет systemd?

--
sergio.

Re: systemd halt

[Evgeny Zubok]

Evgeny Zubok  writes:

> sergio  writes:
>
>> Как правильно выключать debian с systemd?
>>
>> говорю sudo halt, система доходит до "reboot: System halted" и всё.
>
> Не пользуюсь systemd, поэтому поинтересуюсь: systemd каким-нибудь
> образом использует прежние настройки системы из
> /etc/default? Предполагаю, что нет. Но если использует, то там есть
> файлик /etc/default/halt, в котором надо указать HALT=poweroff. Тогда он
> по halt будет выключать машину.

Если что, то эта переменная среды описана в man shutdown в разделе HALT
OR POWEROFF в конце. В общем, задача сводится к тому, чтобы установить
эту переменную среды при помощи этой вашей systemd, то есть найти
правильное место.

Re: systemd halt

[Evgeny Zubok]

sergio  writes:

> Как правильно выключать debian с systemd?
> говорю sudo halt, система доходит до "reboot: System halted" и всё.

Сам не пользуюсь systemd, сижу на sysV, поэтому сказанное может не
действовать на systemd. Если systemd по-прежнему читает настройки
системы из /etc/default, то найди там файл /etc/default/halt и укажи
HALT=poweroff. Тогда halt будет выключать машину.

Re: systemd halt

[Evgeny Zubok]

sergio  writes:

> Как правильно выключать debian с systemd?
>
> говорю sudo halt, система доходит до "reboot: System halted" и всё.

Не пользуюсь systemd, поэтому поинтересуюсь: systemd каким-нибудь
образом использует прежние настройки системы из
/etc/default? Предполагаю, что нет. Но если использует, то там есть
файлик /etc/default/halt, в котором надо указать HALT=poweroff. Тогда он
по halt будет выключать машину.

Re: systemd halt

[dvs]

Геннадий Ковалёв всё правильно говорит.
Добавлю только, что все эти команды - мягкие ссылки на sysytemctl.

halt = systemctl halt  Shut down and halt the system
poweroff = systemctl poweroff  Shut down and power-off the system
reboot = systemctl reboot  Shut down and reboot the system

Это произошло после замены SysV на systemd.

вт, 2 окт. 2018 г. в 12:15, Геннадий Ковалёв :

> В Вт, 02/10/2018 в 10:57 +0300, sergio пишет:
> > On 02/10/2018 06:46, Леонид Кальмаев wrote:
> > > А чем не устроил poweroff?
> >
> > многабукаф, привык halt говорить.
> >
> > Попробовал, poweroff работает.
> >
>
> Так слово halt обозначает "повиснуть", вырубает все процессы и cpu, но
> команда не должена выключать питание. А poweroff как раз его вырубает.
> Так что всё законно.
>
> То, что раньше вырубало на halt - это глюк, на разных машинах это вело
> себя по разному. Ровно как и poweroff периодически глючил и не вырубал
> питание.
>

Re: systemd halt

[Геннадий Ковалёв]

В Вт, 02/10/2018 в 10:57 +0300, sergio пишет:
> On 02/10/2018 06:46, Леонид Кальмаев wrote:
> > А чем не устроил poweroff?
> 
> многабукаф, привык halt говорить.
> 
> Попробовал, poweroff работает.
> 

Так слово halt обозначает "повиснуть", вырубает все процессы и cpu, но
команда не должена выключать питание. А poweroff как раз его вырубает.
Так что всё законно. 

То, что раньше вырубало на halt - это глюк, на разных машинах это вело
себя по разному. Ровно как и poweroff периодически глючил и не вырубал
питание.

Re: systemd halt

[sergio]

On 02/10/2018 06:46, Леонид Кальмаев wrote:

А чем не устроил poweroff?


многабукаф, привык halt говорить.

Попробовал, poweroff работает.

--
sergio.

Re: systemd halt

[yuri . nefedov]

On Tue, 2 Oct 2018, sergio wrote:



Как правильно выключать debian с systemd?

говорю sudo halt, система доходит до "reboot: System halted" и всё.

Это баг или так и должно быть? Баг какого пакета?

Если нажать 'выключить' в оконном менеджере, то система выключается
полностью.

--
sergio.



  Ответ я не знаю, самому стало интересно, нашел вот это описание.

  https://unix.stackexchange.com/a/196014/5132

  Особенно порадовало
  - Forget about the manual page that marcelm quoted;
it's not from the right toolset at all, and is a description
of another toolset's command, incorrect for systemd's.

  И краткий вывод, что да, halt просто останавливает CPU
  и не пытается отключить питание.

Ю.

  p.s. Не откажу себе в удовольствии:
  In the systemd toolset
halt,poweroff,reboot, telinit, and shutdown
  are all symbolic links to /bin/systemctl.

Re: systemd tmp tmpfs

[Konstantin Matyukhin]

> Ну вот /usr/share/systemd/tmp.mount нашёл, а применять его как?
cp /usr/share/systemd/tmp.mount /etc/systemd/system/
systemctl enable tmp.mount

> Баг на какой пакет рисовать?
systemd

-- 
С уважением,
Константин Матюхин

Re: systemd tmp tmpfs

[Иван Лох]

On Fri, Sep 21, 2018 at 11:35:43AM +0300, sergio wrote:
> Вот раньше я раскаменчивал RAMTMP=yes, TMP_SIZE=50% в /etc/default/tmpfs
> и получал /tmp на tmpfs, а как теперь с этим вашим системдэ это делать
> нужно? А читать что и где? Ну вот /usr/share/systemd/tmp.mount нашёл, а
> применять его как? Баг на какой пакет рисовать?

Точно также как и без systemd. 
RTFM fstab

tmpfs  /tmp   tmpfs  rw,nosuid,nodev,size=50% 0   0

Re: systemd X.device vs dev-X.device

[sergio]

On 11/09/2018 01:13, sergio wrote:


А mmcblk0p2.device что такое? Где про него читать?


Внимание, правильный ответ: просто systemd не проверяет существование 
X.device по-этому для любого X выдаёт "Active: inactive (dead)"


# systemctl status nonexistent.device
● nonexistent.device
   Loaded: loaded
   Active: inactive (dead)

Про это нигде не написано.

--
sergio.

Re: systemd X.device vs dev-X.device

[sergio]

On 18/09/2018 10:17, Anatoly Pugachev wrote:

Часть в ядре (то есть это ваша MMC card) , часть в манулах системд. Я бы 
сказал что dev- это префикс, а device обозначение класса (подробнее в 
мануалах systemd)


Ответ неверный.

--
sergio.

Re: systemd X.device vs dev-X.device

[Anatoly Pugachev]

On Tue, Sep 11, 2018, 01:30 sergio  wrote:

> В чём разница между dev-mmcblk0p2.device и mmcblk0p2.device?
>
> Ну вот про dev-mmcblk0p2.device тут написано:
> https://freedesktop.org/software/systemd/man/systemd.device.html
>
> А mmcblk0p2.device что такое? Где про него читать?
>

Часть в ядре (то есть это ваша MMC card) , часть в манулах системд. Я бы
сказал что dev- это префикс, а device обозначение класса (подробнее в
мануалах systemd)

>

Re: systemd symlink vs file в dev-X1.device.requires

[sergio]

On 11/09/2018 08:20, Artem Chuprina wrote:


  > # ln -s /lib/systemd/system/X@.service
  > /etc/systemd/system/dev-X1.device.requires



Оба неправильные, насколько я понимаю... Но я могу неправильно понимать.


Неправильно понимаешь, симлинк в 
/etc/systemd/system/dev-X1.device.requires работает.



А линковать непосредственно в /etc/systemd/system/ ничего не следует,
он там этого не ожидает.


Полно их там, и я их не создавал:

% ls -l /etc/systemd/system
...
sshd.service -> /lib/systemd/system/ssh.service
syslog.service -> /lib/systemd/system/rsyslog.service
...





--
sergio.

Re: systemd symlink vs file в dev-X1.device.requires

[Artem Chuprina]

sergio -> debian-russian@lists.debian.org  @ Tue, 11 Sep 2018 01:45:58 +0300:


 > Есть пустой /etc/systemd/system/dev-X1.device.requires

 > В чём разница между

 > # ln -s /lib/systemd/system/X@.service
 > /etc/systemd/system/dev-X1.device.requires

 > и

 > # cp /lib/systemd/system/X@.service 
 > /etc/systemd/system/dev-X1.device.requires

 > ?

Оба неправильные, насколько я понимаю... Но я могу неправильно понимать.

В смысле, systemd - это не init.d, в его конфигурации симлинки
развешиваются только в директории вида *.wants/. А линковать
непосредственно в /etc/systemd/system/ ничего не следует, он там этого
не ожидает.

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

Re: systemd symlink vs file в dev-X1.device.requires

[sergio]

On 11/09/2018 02:13, Alex Kicelew wrote:

Делался ли после cp/ln systemctl daemon-reload? 


Делался reboot.

--
sergio.

Re: systemd symlink vs file в dev-X1.device.requires

[Alex Kicelew]

On 09/11/18 01:45, sergio wrote:
> Почему в первом случае в выводе
> # systemctl
> есть X@dev-X1.service
> А во втором нет?

Делался ли после cp/ln systemctl daemon-reload?

Re: systemd debug

[sergio]

On 09/09/2018 18:35, Maxim Nikulin wrote:

> "отладь секретный сервис вслепую"

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


>> В dev@.service написано
>>
>> Before=dev-%i.device
>>
>> Стартует и обламывается по таймауту dev-X.device а до dev@.service 
>> вообще дело не доходит.

> Не уверен, что порядок указан правильно.

Какой порядок?


А в чём разница между dev-DEV.device и DEV.device?

# systemctl status X.device
● X.device
   Loaded: loaded
   Active: inactive (dead)

# systemctl status dev-X.device
● dev-X.device
   Loaded: loaded
  Drop-In: /run/systemd/generator/dev-X.device.d
   └─50-netdev-dependencies.conf
   Active: inactive (dead)

... systemd[1]: dev-X.device: Job dev-X.device/start timed out.
... systemd[1]: Timed out waiting for device dev-X.device.
... systemd[1]: dev-X.device: Job dev-X.device/start failed with result 
'timeout'.



-- 
sergio.

Re: systemd debug

[Maxim Nikulin]

08.09.2018 19:53, sergio пишет:


На самом деле я наврал. Тут две сущности. dev-X.device и 
/lib/systemd/system/dev@.service


В третьей серии санта-барбары "отладь секретный сервис вслепую" 
выяснилось, что service - это на самом деле переодетый device. Сервисом 
оказался его сводный брат, при этом до конца не прояснилось, кто из них 
играл в каждой из сцен. Да и имена героям сценарист-постмодернист 
предоставил выбирать самостоятельно. Видимо, для удобства обсуждения. За 
развитием интриги я может еще понаблюдаю, если не станет совсем скучно, 
но от дальнейшего участия, пожалуй, воздержусь.



В dev@.service написано

Before=dev-%i.device

Стартует и обламывается по таймауту dev-X.device а до dev@.service 
вообще дело не доходит.


Не уверен, что порядок указан правильно.

Re: systemd debug

[sergio]

On 08/09/2018 12:51, Maxim Nikulin wrote:

А если ExecStart с двух слэшей начинается (ExecStart=//sbin/...), это 
что значит?



systemctl cat:
No files found


Опечатка в имени unit?


Нет.


systemctl show показывает кучу каких-то переменных


Там много интересного. Хотя бы Exec* (ExecStart, ExecStartPre), 
TimeoutStart.


Ничего из этого там нет.


Что хотя бы показывает status?


   Loaded: loaded
   Active: inactive (dead)


На самом деле я наврал. Тут две сущности. dev-X.device и 
/lib/systemd/system/dev@.service


В dev@.service написано

Before=dev-%i.device


Стартует и обламывается по таймауту dev-X.device а до dev@.service 
вообще дело не доходит.



--
sergio.

Re: systemd debug

[Maxim Nikulin]

08.09.2018 14:42, sergio пишет:

On 08/09/2018 07:07, Maxim Nikulin wrote:


Возможно, что для service указан тип notify

Type=forking


Не видел, как выглядит такая ситуация, но может не было fork или 
последующего exit?


В этом unit файле написан ExecStart, который как я понимаю вообще не 
выполняется. Как можно понять, что именно пытается сделать systemd и 
с чем у него возникает таймаут? По шагам.


Не совсем то, что хочется, но могу предложить посмотреть, что думает 
systemd об этом сервисе. systemctl cat и systemctl show с указанием 
имени сервиса.


systemctl cat:
No files found


Опечатка в имени unit?


systemctl show показывает кучу каких-то переменных


Там много интересного. Хотя бы Exec* (ExecStart, ExecStartPre), 
TimeoutStart.


Что хотя бы показывает status?

Re: systemd debug

[sergio]

On 08/09/2018 07:07, Maxim Nikulin wrote:


Возможно, что для service указан тип notify

Type=forking

В этом unit файле написан ExecStart, который как я понимаю вообще не 
выполняется. Как можно понять, что именно пытается сделать systemd и с 
чем у него возникает таймаут? По шагам.


Не совсем то, что хочется, но могу предложить посмотреть, что думает 
systemd об этом сервисе. systemctl cat и systemctl show с указанием 
имени сервиса.


systemctl cat:
No files found

systemctl show показывает кучу каких-то переменных


--
sergio.

Re: systemd debug

[Maxim Nikulin]

08.09.2018 07:39, sergio пишет:


Ну вот есть сервис, и он при старте говорит Job /start timed out.

А как понять, что там происходит? В journalctl -xe ничего интересного 
кроме этого "timed out" нет, даже с LogLevel=debug в 
/etc/systemd/system.conf


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


В этом unit файле написан ExecStart, который как я понимаю вообще не 
выполняется. Как можно понять, что именно пытается сделать systemd и с 
чем у него возникает таймаут? По шагам.


Не совсем то, что хочется, но могу предложить посмотреть, что думает 
systemd об этом сервисе. systemctl cat и systemctl show с указанием 
имени сервиса.

Re: systemd /etc/init.d

[Михаил Касаджиков]

sergio  писал(а) в своём письме Tue, 13 Mar 2018 06:09:22 
+0300:


Добавил в /etc/init.d файлик, написал в нём:
Default-Start: 2 3 4 5
потом сказал
# update-rc.d файлик defaults
бутнулся, сервис запущен, systemctl его показывает!

потом поменял ту строчку на
Default-Start: S
# update-rc.d файлик remove
# update-rc.d файлик defaults
бутнулся, сервис НЕ запущен, systemctl его НЕ показывает!


А разве в stretch (тогда ещё testing) они не выкинули вообще этот S-уровень? Я 
когда переносил более свежий systemd в jessie, то в какой-то момент налетел на 
это изменение и так и оставил 230-ю версию. Лень было разбирать что там 
понаделали.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: systemd /etc/init.d

[Dmitry E. Oboukhov]

> Добавил в /etc/init.d файлик, написал в нём:
> Default-Start: 2 3 4 5
> потом сказал
> # update-rc.d файлик defaults
> бутнулся, сервис запущен, systemctl его показывает!

> потом поменял ту строчку на
> Default-Start: S
> # update-rc.d файлик remove
> # update-rc.d файлик defaults
> бутнулся, сервис НЕ запущен, systemctl его НЕ показывает!

> https://www.debian.org/doc/manuals/debian-reference/ch03.en.html
> systemd offers backward compatibility features. SysV-style boot scripts
> in "/etc/init.d/rc[0123456S].d/[KS]" are still parsed and
> !!!^^^!!!
> telinit(8) is translated into systemd unit activation requests.

> На какой пакет баг рисовать?

по моему надо systemd-sysv поставить чтоб оно работало, но пока еще
можно говорить apt-get remove systemd я так и делаю.
-- 

. ''`.Dmitry E. Oboukhov 
: :’  :
`. `~’   GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756


signature.asc
Description: PGP signature

Re: systemd не поднимает интерфейс из /etc/network/interfaces

[Oleksandr Gavenko]

On 2017-07-30, yuri.nefe...@gmail.com wrote:

>> iface eth1 inet static
>>
>
>  Ещё надо указать
>
>  auto eth1
>
>  или
>
>  allow-hotplug eth1

Упустил. Давненько не настраивал...

-- 
http://defun.work/

Re: systemd не поднимает интерфейс из /etc/network/interfaces

[yuri . nefedov]

On Sun, 30 Jul 2017, Oleksandr Gavenko wrote:


On 2017-07-28, Tim Sattarov wrote:



Нескромный вопрос: а он прописан как auto ?

On 28/07/17 04:28 PM, Oleksandr Gavenko wrote:

В виртуалочке один интерфейс NAT в мир (разрешаеться по DHCP наверно), другой
**статически** описан в /etc/network/interfaces и не инициализируеться при 
старте.


iface eth1 inet static



 Ещё надо указать

 auto eth1

 или

 allow-hotplug eth1

 Можно и оба вместе.

 man interfaces /INTERFACE SELECTION

Ю.

Re: systemd не поднимает интерфейс из /etc/network/interfaces

[Eugene Berdnikov]

On Sun, Jul 30, 2017 at 02:29:54PM +0300, Oleksandr Gavenko wrote:
> On 2017-07-28, Tim Sattarov wrote:
> >>
> > Нескромный вопрос: а он прописан как auto ?
> >
> > On 28/07/17 04:28 PM, Oleksandr Gavenko wrote:
> >> В виртуалочке один интерфейс NAT в мир (разрешаеться по DHCP наверно), 
> >> другой
> >> **статически** описан в /etc/network/interfaces и не инициализируеться при 
> >> старте.
> 
> iface eth1 inet static

 То есть auto нет? Поэтому и не поднимается.

 Интерфейс с динамическим адресом (dhcp) тоже кто-то должен поднять.
 Если ему auto не прописан, то об этом должен позаботиться какой-то
 процесс: либо network manager, либо wpa_supplicant и т.д.
-- 
 Eugene Berdnikov

Re: systemd не поднимает интерфейс из /etc/network/interfaces

[Oleksandr Gavenko]

On 2017-07-28, Tim Sattarov wrote:
>>
> Нескромный вопрос: а он прописан как auto ?
>
> On 28/07/17 04:28 PM, Oleksandr Gavenko wrote:
>> В виртуалочке один интерфейс NAT в мир (разрешаеться по DHCP наверно), другой
>> **статически** описан в /etc/network/interfaces и не инициализируеться при 
>> старте.

iface eth1 inet static

-- 
http://defun.work/

Re: systemd не поднимает интерфейс из /etc/network/interfaces

[Artem Chuprina]

Tim Sattarov -> debian-russian@lists.debian.org  @ Fri, 28 Jul 2017 18:07:13 
-0400:

 >> В виртуалочке один интерфейс NAT в мир (разрешаеться по DHCP наверно), 
 >> другой
 >> статически описан в /etc/network/interfaces и не инициализируеться при 
 >> старте.
 >>
 >> Комадной:
 >>
 >>   sudo /sbin/ifup eth1
 >>
 >> поднимаеться. Это в Jessy уже не используеться /etc/network/interfaces ?
 >>
 >> Или нужно поколдовать с systemd?
 >>
 > Нескромный вопрос: а он прописан как auto ?

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

Re: systemd не поднимает интерфейс из /etc/network/interfaces

[Tim Sattarov]

On 28/07/17 04:28 PM, Oleksandr Gavenko wrote:
> В виртуалочке один интерфейс NAT в мир (разрешаеться по DHCP наверно), другой
> статически описан в /etc/network/interfaces и не инициализируеться при старте.
>
> Комадной:
>
>   sudo /sbin/ifup eth1
>
> поднимаеться. Это в Jessy уже не используеться /etc/network/interfaces ?
>
> Или нужно поколдовать с systemd?
>
Нескромный вопрос: а он прописан как auto ?

Re: systemd не поднимает интерфейс из /etc/network/interfaces

[Artem Chuprina]

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Fri, 28 Jul 2017 
23:28:41 +0300:

 > В виртуалочке один интерфейс NAT в мир (разрешаеться по DHCP наверно), другой
 > статически описан в /etc/network/interfaces и не инициализируеться при 
 > старте.

 > Комадной:

 >   sudo /sbin/ifup eth1

 > поднимаеться. Это в Jessy уже не используеться /etc/network/interfaces ?

 > Или нужно поколдовать с systemd?

В jessie - используется. Ну, с systemd не пробовал...

На той машинке, где есть systemd, /etc/network/interfaces слишком
дефолтный...

На тестовой виртуалке со stretch вот сейчас провел эксперимент с заменой
sysvinit-core на systemd-sysv, предварительно настроив вторую сетевку в
/etc/network/interfaces (вернее, первую - изначально была
вторая). Подхватил.

А вот чего ни на одной из этих машин не было, нет, и не будет, так это
Network Manager'а.

Re: [systemd] [suspend] [перфекционизм] А какой сейчас документированный способ передергивания беспроводных адаптеров при спячке?

[Dmitry Alexandrov]

>> Как известно, многие беспроводные сетевые карты с несвободными
>> прошивками (да и не только они) плохо совместимы с погружением машины
>> спячку того или иного вида (suspending / hibernation).
>> 
>> Есть и традиционный костыль, решающий эту проблему, — выгрузка-
>> загрузка линуксового модуля, отвечающего за таковое устройство.
>> 
>> До прихода systemd в Дебиане был предусмотрен и описан в pm-action(8) 
>> интерфейс для настройки костыля: куда-нибудь в /etc/pm/config.d/
>> можно было прописать, к примеру, SUSPEND_MODULES="r8712u".
>> 
>> А что теперь?  Нет, мне, разумеется, не сложно написать два .service-
>> файла и кинуть их в /etc/systemd/system/:
>>
>> ...
>>
>> Но какого-нибудь более пользовательского, документированного решения
>> ныне в Дебиане из коробки не предусмотрено?
>
> Я сделал так. Этот скрипт повесил на systemd и горя с sleep и hibernate
> не имею. http://codepad.org/BH0HDxXC

Э... Вы, кажется, ссылку перепутали.  (И вообще — какие ссылки — мы же не в 
IRC!)  Там следующее:



raw.rb
Description: application/ruby

Это, насколько я понял, костыль для отключения пробуждения из энергозависимой 
спячки (suspending) по сигналу с ряда устройств.  Там, кстати, написано «from 
hibernate or sleep», но я не могу представить себе, как это может повлиять на 
способы *включения* машины; если ошибаюсь — поправьте.

И хотя вы меня не спрашивали, как это делается по-нормальному, но тем, кто это 
письмо когда-нибудь найдет, могу сообщить, что, разумеется, правилами для 
udev’а.  Например, таким:

,[ /etc/udev/rules.d/43-disable-wakeup-on-peripherals.rules ]
| ACTION=="add", TEST=="power/wakeup", ATTR{power/wakeup}="disabled"
`

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


А от вас я жду того кода, который вы хотели привести.  :-)

Re: [systemd] [suspend] [перфекционизм] А какой сейчас документированный способ передергивания беспроводных адаптеров при спячке?

[Igor Savlook]

On Tue, 2017-03-28 at 23:49 +0300, Dmitry Alexandrov wrote:
> Добрых суток уважаемой рассылке.
> 
> Как известно, многие беспроводные сетевые карты с несвободными
> прошивками (да и не только они) плохо совместимы с погружением машины
> спячку того или иного вида (suspending / hibernation).
> 
> Есть и традиционный костыль, решающий эту проблему, — выгрузка-
> загрузка линуксового модуля, отвечающего за таковое устройство.
> 
> До прихода systemd в Дебиане был предусмотрен и описан в pm-action(8) 
> интерфейс для настройки костыля: куда-нибудь в /etc/pm/config.d/
> можно было прописать, к примеру, SUSPEND_MODULES="r8712u".
> 
> А что теперь?  Нет, мне, разумеется, не сложно написать два .service-
> файла и кинуть их в /etc/systemd/system/:
> 
> ,
> > [Unit]
> > Before=hibernate.target suspend.target hybrid-sleep.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/sbin/modprobe -r r8712u
> > 
> > [Install]
> > WantedBy=hibernate.target suspend.target hybrid-sleep.target
> 
> `
> 
> ,
> > [Unit]
> > After=hibernate.target suspend.target hybrid-sleep.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/sbin/modprobe r8712u
> > 
> > [Install]
> > WantedBy=hibernate.target suspend.target hybrid-sleep.target
> 
> `
> 
> Но какого-нибудь более пользовательского, документированного решения
> ныне в Дебиане из коробки не предусмотрено?

Ну и вроде как незабываем про rfkill.

Re: [systemd] [suspend] [перфекционизм] А какой сейчас документированный способ передергивания беспроводных адаптеров при спячке?

[Igor Savlook]

On Tue, 2017-03-28 at 23:49 +0300, Dmitry Alexandrov wrote:
> Добрых суток уважаемой рассылке.
> 
> Как известно, многие беспроводные сетевые карты с несвободными
> прошивками (да и не только они) плохо совместимы с погружением машины
> спячку того или иного вида (suspending / hibernation).
> 
> Есть и традиционный костыль, решающий эту проблему, — выгрузка-
> загрузка линуксового модуля, отвечающего за таковое устройство.
> 
> До прихода systemd в Дебиане был предусмотрен и описан в pm-action(8) 
> интерфейс для настройки костыля: куда-нибудь в /etc/pm/config.d/
> можно было прописать, к примеру, SUSPEND_MODULES="r8712u".
> 
> А что теперь?  Нет, мне, разумеется, не сложно написать два .service-
> файла и кинуть их в /etc/systemd/system/:
> 
> ,
> > [Unit]
> > Before=hibernate.target suspend.target hybrid-sleep.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/sbin/modprobe -r r8712u
> > 
> > [Install]
> > WantedBy=hibernate.target suspend.target hybrid-sleep.target
> 
> `
> 
> ,
> > [Unit]
> > After=hibernate.target suspend.target hybrid-sleep.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/sbin/modprobe r8712u
> > 
> > [Install]
> > WantedBy=hibernate.target suspend.target hybrid-sleep.target
> 
> `
> 
> Но какого-нибудь более пользовательского, документированного решения
> ныне в Дебиане из коробки не предусмотрено?

Я сделал так. Этот скрипт повесил на systemd и горя с sleep и hibernate
 не имею. http://codepad.org/BH0HDxXC

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey Kirpichev]

On Jun 30, 2016 4:18 PM, "Dmitrii Kashin"  wrote:
> > Увы, это говорит о том, что кто-то другой наплевал на багрепорты, причем 
> давно.
>
> Интересное замечание с учётом того, что авторы systemd тупо закрывают
> баги, которые им не нравятся. Это, по-вашему, называется "не забивать на
> багрепорты?

Речь шла о мейнтейнерах systemd в Debian.  Если у вас есть аргументы в
пользу таких "тупых закрытий" - баги просто надо открывать обратно, для этого
никаких специальных прав в проекте не надо.  Только желание делать работу.

А телепатически о вашем важном мнении просто никто не узнает
от слова совсем.  Такие дела.

> >> > Баги, висящие годами - это, увы, про sysvinit.
> >>
> >> Ну так надо работать, а не брюзжать в debian-russian о том, как всё
> >> плохо.
> >
> > И что, вы уже не брюзжите и пошли предложить свою помощь в RFA баг?
>
> Да, и уже включаюсь в работу.

Будем посмотреть.  Приятно что я хоть кого-то сподвиг.

Но было бы больше надежды, если б вы ранее были замечены
в работе над пакетами Debian.

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitrii Kashin]

Sergey B Kirpichev  writes:

>> > Реальность, увы разбивает ваши фантазии.  Мейнтейнеры systemd весьма
>> > активно разбираются с багрепортами, чего не скажешь про других...
>> 
>> Это говорит скорее о сырости продукта.
>
> Увы, это говорит о том, что кто-то другой наплевал на багрепорты, причем 
> давно.

Интересное замечание с учётом того, что авторы systemd тупо закрывают
баги, которые им не нравятся. Это, по-вашему, называется "не забивать на
багрепорты?

>> > Баги, висящие годами - это, увы, про sysvinit.
>> 
>> Ну так надо работать, а не брюзжать в debian-russian о том, как всё
>> плохо.
>
> И что, вы уже не брюзжите и пошли предложить свою помощь в RFA баг?

Да, и уже включаюсь в работу.



signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitry E. Oboukhov]

>> из недавного: наткнулись на серьезные проблемы отрезания systemd в
>> контейнерах VZ.
>> ща разбирается у нас отдел с этим, но блин каждый раз когда какие-то
>> глобальные траблы с разворачиванием систем - так всегда все в это
>> systemd упирается

> Стоны есть - багов, как и прежде - нет.  Так и живем.  И с чего-б
> это все "разбираться" приходится?!

стоял вопрос "смигрировать на современный Perl в проекте"
соответственно в рамках этого вопроса решалось 100500 задач разного
уровня (в частности например преодолевалось упрямство Марка Леманна,
которое в Debian таки успешно преодолелось) и выяснилось, что
современный Debian с отрезанным от него systemd с VZ не дружит.

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

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitry Nezhevenko]

On Sun, Jun 12, 2016 at 11:31:39AM +0300, Sergey B Kirpichev wrote:
> On Sun, Jun 12, 2016 at 11:05:15AM +0300, Dmitry Nezhevenko wrote:
> > А баги не всегда на systemd пишут. Например:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824098
> 
> А это точно _та_ проблема, о которой шла речь?

Это точно НЕ та проблема о которой шла речь. Это был ответ на 'багов нет'
-- 
WBR, Dmitry


signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sun, Jun 12, 2016 at 05:50:19PM +0300, Dmitrii Kashin wrote:
> Социальная деятельность занимает время. У этих людей тоже есть работа,
> дела. Они, вероятно, тоже очень заняты.

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

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

Увы, это говорит о том, что кто-то другой наплевал на багрепорты, причем давно.

> > Баги, висящие годами - это, увы, про sysvinit.
> 
> Ну так надо работать, а не брюзжать в debian-russian о том, как всё
> плохо.

И что, вы уже не брюзжите и пошли предложить свою помощь в RFA баг?

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitrii Kashin]

Sergey B Kirpichev  writes:

> On Sun, Jun 12, 2016 at 01:48:13AM +0300, Dmitrii Kashin wrote:
>> Возможно смысл в том, чтобы повесить баг всё же есть.
>
> Но пусть это сделает кто-то другой.
>
> И эти люди удивляются почему в Debian теперь systemd.

Социальная деятельность занимает время. У этих людей тоже есть работа,
дела. Они, вероятно, тоже очень заняты.

>> Пусть на systemd
>> копятся баги. Пусть сообщество знает, что с systemd есть проблемы.
>> 
>> А то и правда, повсюду вижу, как люди страдают от него, а баги внезапно
>> оказываются объективно не отражающими статистику.
>
> А может наоборот, отражают.  Я вот уже начинаю сомневаться.

Ну и сомневайтесь дальше.

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

Это говорит скорее о сырости продукта.

> Баги, висящие годами - это, увы, про sysvinit.

Ну так надо работать, а не брюзжать в debian-russian о том, как всё
плохо.


signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Melleus]

Sergey B Kirpichev  writes:

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

Множественные баги, которые можно активно и быстро исправить лишь
подтверждают гипотезу об изначальной и намеренной сырости продукта, тем
более, когда из-за спины разработчика торчат уши нехилой корпорации. Так
что не в багах проблема, а в интересах. Интересы являются мотивами, а не
баги. Баги - лишь способ "заболтать" проблему, нейтрализовать наиболее
активных и талантливых оппонентов, подменив им истинные цели - ложными и
направив их энергию в пустоту. Подход весьма умен и по-факту оказался
результативен. Именно это следует называть реальностью.

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sun, Jun 12, 2016 at 11:05:15AM +0300, Dmitry Nezhevenko wrote:
> А баги не всегда на systemd пишут. Например:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824098

А это точно _та_ проблема, о которой шла речь?

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sun, Jun 12, 2016 at 01:48:13AM +0300, Dmitrii Kashin wrote:
> Возможно смысл в том, чтобы повесить баг всё же есть.

Но пусть это сделает кто-то другой.

И эти люди удивляются почему в Debian теперь systemd.

> Пусть на systemd
> копятся баги. Пусть сообщество знает, что с systemd есть проблемы.
> 
> А то и правда, повсюду вижу, как люди страдают от него, а баги внезапно
> оказываются объективно не отражающими статистику.

А может наоборот, отражают.  Я вот уже начинаю сомневаться.

> Само собой, чёрта с два мейнтейнеры эту проблему решат.

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

Баги, висящие годами - это, увы, про sysvinit.

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sun, Jun 12, 2016 at 01:31:39AM +0300, Dmitrii Kashin wrote:
> что раньше gnome зависел от logind.
> 
> Я ошибся, gnome дейстивтельно отвязали от systemd-as-pid-1.

logind тоже никаким боком не являлся(ется) pid 1...

Грустно.  Вот-это-вот-все...

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitry Nezhevenko]

On Sat, Jun 11, 2016 at 08:13:53PM +0300, Sergey B Kirpichev wrote:
> On Sat, Jun 11, 2016 at 04:54:58PM +0300, Dmitry E. Oboukhov wrote:
> > из недавного: наткнулись на серьезные проблемы отрезания systemd в
> > контейнерах VZ.
> > ща разбирается у нас отдел с этим, но блин каждый раз когда какие-то
> > глобальные траблы с разворачиванием систем - так всегда все в это
> > systemd упирается
> 
> Стоны есть - багов, как и прежде - нет.  Так и живем.  И с чего-б
> это все "разбираться" приходится?!

А баги не всегда на systemd пишут. Например:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824098

-- 
WBR, Dmitry


signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitrii Kashin]

Melleus  writes:

> Sergey B Kirpichev  writes:
>
>> Стоны есть - багов, как и прежде - нет.
>
> Это как же можно сформулировать баг к квадратному колесу, если его
> основной фичей по задумке изобретателя является именно квадратность?
> Само квадратное колесо баг и есть. Очень плохо ехать машине на
> квадратных колесах, в какой цвет их не покрась и какими болтами не
> прикрути. Продукт - сырой и не юникс-вей. Вообще удивительно, как он в
> стабильную ветку попал. Болтался бы в сиде себе, где ему и место, пока
> не созреет.

Возможно смысл в том, чтобы повесить баг всё же есть. Пусть на systemd
копятся баги. Пусть сообщество знает, что с systemd есть проблемы.

А то и правда, повсюду вижу, как люди страдают от него, а баги внезапно
оказываются объективно не отражающими статистику.

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



signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitrii Kashin]

Dmitrii Kashin  writes:

> Sergey B Kirpichev  writes:
>
>>> но из за нескольких лентяев никчемного пакета
>>
>> "Лентяи" - все-таки обеспечили работу gnome без systemd.
>
> По-моему Вы что-то путаете. Я вот выставил отрицательные пины пакетам
> systemd, и сейчас по вашей наводке решил поставить gnome. Само собой он
> не поставился. Поскольку никаких других пинов у меня в системе нет, он
> всё-таки жёстко зависит от systemd.

upd: Вспомнил, что у меня часть пакетов из sid. Для чистоты эксперимента
сделал полный даунгдейд на jessie. Оказалось, что gnome тянет лишь
libsystemd0, что, в принципе, уже не так страшно, по сравнению с тем,
что раньше gnome зависел от logind.

Я ошибся, gnome дейстивтельно отвязали от systemd-as-pid-1.


signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Melleus]

Sergey B Kirpichev  writes:

> Стоны есть - багов, как и прежде - нет.

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

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitrii Kashin]

Sergey B Kirpichev  writes:

> On Sat, Jun 11, 2016 at 04:20:09PM +0300, Dmitrii Kashin wrote:
>> Дискуссия однозначно на уровне.
>
> Ну а что еще прикажете сказать тому, что даже release notes
> не читал от слова совсем?

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

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


signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sat, Jun 11, 2016 at 04:54:58PM +0300, Dmitry E. Oboukhov wrote:
> из недавного: наткнулись на серьезные проблемы отрезания systemd в
> контейнерах VZ.
> ща разбирается у нас отдел с этим, но блин каждый раз когда какие-то
> глобальные траблы с разворачиванием систем - так всегда все в это
> systemd упирается

Стоны есть - багов, как и прежде - нет.  Так и живем.  И с чего-б
это все "разбираться" приходится?!

ЗЫ: RFA sysvinit все еще прием...

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sat, Jun 11, 2016 at 04:20:09PM +0300, Dmitrii Kashin wrote:
> Дискуссия однозначно на уровне.

Ну а что еще прикажете сказать тому, что даже release notes
не читал от слова совсем?

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sat, Jun 11, 2016 at 04:18:01PM +0300, Dmitrii Kashin wrote:
> Сообщество сторонников systemd.

А я-то грешный к нему каким боком?

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitry E. Oboukhov]

>>> Я вот выставил отрицательные пины пакетам
>>> systemd, и сейчас по вашей наводке решил поставить gnome.
>> 
>> Не лезьте в систему, если неспособны прочесть документацию.

> Дискуссия однозначно на уровне.

грустно что эта хрень таки проникает всюду.

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

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitrii Kashin]

Sergey B Kirpichev  writes:

> On Sat, Jun 11, 2016 at 03:09:40PM +0300, Dmitrii Kashin wrote:
>> Sergey B Kirpichev  writes:
>> >> но из за нескольких лентяев никчемного пакета
>> >
>> > "Лентяи" - все-таки обеспечили работу gnome без systemd.
>> 
>> По-моему Вы что-то путаете.
>
> Ну а как же я без вас, да еще самостоятельно - способен
> опознать работающий у себя init.  Никак, ессно.
>
>> Я вот выставил отрицательные пины пакетам
>> systemd, и сейчас по вашей наводке решил поставить gnome.
>
> Не лезьте в систему, если неспособны прочесть документацию.

Дискуссия однозначно на уровне.


signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Melleus]

Dmitrii Kashin  writes:
> Но в принципе жить
> уже можно.

Опыт подсказывает, что только мейнстримные дистрибутивы и имеют
достаточный* уровень стабильности и поддержки. А из мейнстрима только
генту и держится пока еще. Ну и BSD еще, если шире посмотреть.

Но удовольствие компилять сутками напролет опен офис после каждого
обновления вместо своей непосредственной работы, лишь ради того, чтобы
избавиться от системд тоже не каждый может себе позволить, ИМХО.

*) достаточный для пользователя - не - проф. айтишника имеется в виду.

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Dmitrii Kashin]

Sergey B Kirpichev  writes:

> On Sat, Jun 11, 2016 at 02:51:56PM +0300, Dmitrii Kashin wrote:
>> Вот такая вот статистика, что подобной фразой сыплет всё ваше сообщество
>> на любую критику systemd.
>
> "Ваше", это, пардонте, какое?

Сообщество сторонников systemd.

PS: и не надо меня в Cc: добавлять, пожалуйста.


signature.asc
Description: PGP signature

Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sat, Jun 11, 2016 at 03:09:40PM +0300, Dmitrii Kashin wrote:
> Sergey B Kirpichev  writes:
> >> но из за нескольких лентяев никчемного пакета
> >
> > "Лентяи" - все-таки обеспечили работу gnome без systemd.
> 
> По-моему Вы что-то путаете.

Ну а как же я без вас, да еще самостоятельно - способен
опознать работающий у себя init.  Никак, ессно.

> Я вот выставил отрицательные пины пакетам
> systemd, и сейчас по вашей наводке решил поставить gnome.

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