Re: научите systemd!
Artem Chuprina wrote: > Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 5 Mar 2018 > 15:14:32 +0300: > >> >> >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не > может > >> >> >> >> прописать зависимость от системного. (В документации, кстати, > я этого не > >> >> >> > А я вот не понимаю. Все эти приседания вокруг > Before|After|Requires|Want > >> >> >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь > с D-BUS'ом. > >> >> >> Правов у него нет. Информация о зависимостях и, главное, степени > успеха > >> >> >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский > >> >> >> systemctl (или отдельный экземпляр systemd?) туда не пускают. > >> >> > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на > спросить - это > >> >> > ШЕСТЬ. Это даже не пять. > >> >> Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и > >> >> драйвера принтеров теперь зависят... > >> > Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это > уже > >> > тонкости реализации. > >> Не, они там от policykit чего-то хотели. udev, в общем, > > Интересно, а зачем это нужно в случае принтера. С флешками как-то еще > > понятно, но вот с принтером... > Подозреваю, нотификации юзеру о втыкании принтера в USB. Оно ему надо, тому юзеру? Особенно в момент загрузки, когда еще нету собственно тех Xов/Wayland/четамсейчасмодно для показать? Скорее всего всё тот-же танец с бубнами вокруг "мы тут MFU нашли - кому права на сканер давать будем?" > >> отсоединен. Впрочем, кажется, то, чего они хотели от policykit, тоже > >> отсоединено, только надо более вдумчиво попинать aptitude. > > Увы - udev вмоноличен, а то что они идет отдельным пакетиком - так вышло. > > Как выкинут sysvinit - так сразу станет всё в одном. > Выкинут - поставлю FreeBSD. А ей уже можно пользоваться? Так, чтоб не заниматься постоянным приседанием вокруг пересборки системы и вялотекщих прыжков с версии на версию из-за того, что левая нога разработчиков решила, что в этой версии мы порты не поддерживаем и все строем бегут жрать новый RELENG. > >> >> Меня привлекает в нем идея, что можно делать тома с разными > свойствами, > >> >> распределяемые по пространству диска динамически. Без танцев с > ресайзом, > >> >> где каждую вторую файловую систему нельзя уменьшить без > отмонтирования, > >> >> а каждую четвертую - и увеличить... > >> > А зачем это нужно? Нет, реально - зачем? Мне видиться только один > вариант > >> > использования - петабайтные хранилища. Но там увы своё железо и свои > fs. > >> Ровно наоборот. Когда диска некоторый дефицит. > > Когда диска дефицит - надо идти за новым. Или посылать счет в бухгалтерию. > > Собирать оделяо из лоскутков - ну, в виде развлечения и народных промыслов > > только интересно. > Идти за новым не всегда своевременно. Он все-таки не три копейки стоит, > особенно если тихий. А где ты видел громкий? Я давно не вижу громких, кроме как в исполнении "для рейдов". Но его в стойке и не слышно. А для дома для семьи - можно взять и тихий, но он будет и не скоростной. А можно вобще NAS в кладовку засунуть, пусть там шумит, за дверкой. [...]
Re: научите systemd!
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 5 Mar 2018 15:14:32 +0300: >> >> >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не >> может >> >> >> >> прописать зависимость от системного. (В документации, кстати, я >> этого не >> >> >> > А я вот не понимаю. Все эти приседания вокруг >> Before|After|Requires|Want >> >> >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с >> D-BUS'ом. >> >> >> Правов у него нет. Информация о зависимостях и, главное, степени >> успеха >> >> >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский >> >> >> systemctl (или отдельный экземпляр systemd?) туда не пускают. >> >> > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на >> спросить - это >> >> > ШЕСТЬ. Это даже не пять. >> >> Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и >> >> драйвера принтеров теперь зависят... >> > Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это уже >> > тонкости реализации. >> Не, они там от policykit чего-то хотели. udev, в общем, > Интересно, а зачем это нужно в случае принтера. С флешками как-то еще > понятно, но вот с принтером... Подозреваю, нотификации юзеру о втыкании принтера в USB. >> отсоединен. Впрочем, кажется, то, чего они хотели от policykit, тоже >> отсоединено, только надо более вдумчиво попинать aptitude. > Увы - udev вмоноличен, а то что они идет отдельным пакетиком - так вышло. > Как выкинут sysvinit - так сразу станет всё в одном. Выкинут - поставлю FreeBSD. >> >> Меня привлекает в нем идея, что можно делать тома с разными свойствами, >> >> распределяемые по пространству диска динамически. Без танцев с ресайзом, >> >> где каждую вторую файловую систему нельзя уменьшить без отмонтирования, >> >> а каждую четвертую - и увеличить... >> > А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант >> > использования - петабайтные хранилища. Но там увы своё железо и свои fs. >> Ровно наоборот. Когда диска некоторый дефицит. > Когда диска дефицит - надо идти за новым. Или посылать счет в бухгалтерию. > Собирать оделяо из лоскутков - ну, в виде развлечения и народных промыслов > только интересно. Идти за новым не всегда своевременно. Он все-таки не три копейки стоит, особенно если тихий. >> >> Память он, кстати, жрет весьма умеренно, если дедупликацию не >> >> включать. >> >> totalusedfree shared buff/cache >> available >> >> Mem:3935296 2414300 1420856 29512 100140 >> 1338100 >> >> Swap: 4194300 46848 4147452 >> >> Диск 4 терабайта, и помимо файлосерверения машина занята только >> >> роутингом. Еще оно при записи подтормаживает, но там двухъядерный >> >> гигагерцовый целерон, и включена компрессия. >> > Файло помойка без роутинга, дисков на 8 терабайт: >> > totalusedfree shared buff/cache >> available >> > Mem:8172772 103200 288628 29116 7780944 >> 7734592 >> > Swap: 1951740 0 1951740 >> > ZFS и компрессии нет, да. >> Если ты хотел помериться, то ты победил. Но я мериться не предлагал. Я >> всего лишь показал, что у меня оно в небольшую, в общем, память >> нормально влезает. > Не, меряться я не хотел. Хотел показать, что a) по выводу free нефига не > понятно, сколько жреть этот ZFS, b) у машины без zfs тупо больше места под > дисковые кэши. Ну, меня в данном случае интересует интегральная характеристика "хватает памяти или маловато". Хватает. Дисковые кэши мне там не особо нужны. >> >> Компрессия, да, приятное дополнение, но насколько я понимаю, ее и еще >> >> кто-то умел. Вдумчивая проверка целостности - но да, ECC оно хочет. Но >> >> они меня, в общем, убедили, что если хочешь целостности, надо хотеть и >> >> ECC. С любой FS. Просто без ECC ZFS в случае сбоев памяти начнет >> >> ругаться раньше, когда меньше данных поломали. А остальные будут делать >> >> вид, что все хорошо. >> > А как ваш волшебный ZFS догадается, что произошла битовая ошибка в момент >> > чтения памяти контроллером DMA при перекачке странцы в контроллер SATA? >> > Только считав её (страницу) назад с диска и сравнив checksumm? >> Да. У него для этого специальная ручка есть, рекомендуемая для запуска >> по крону. > Дык такая ручка и у mdadm'a есть и у железных контроллеров. Всякие там > Patrol Read/Background consistency check, и от живости cron'a не зависят. Если рейд, то да, пожалуй, можно. >> > А если взять более реальный вариант обсчета каких нибудь матриц в GPU - >> то >> > туда тоже заносить память с ECC? Вот ведь геймеры будут рады, что их >> шейдеры >> > теперь защищены ценой потери производительности в 3-5% и ценником на >> видяху >> > в 15-20%. >> А геймерам целостность низачем. > А других видях не делают. Точнее - нонче делают, но за др
Re: научите systemd!
D. H. wrote: > О©╫О©╫О©╫-О©╫О©╫ О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫. О©╫О©╫О©╫ > О©╫О©╫О©╫ О©╫О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫" > ZFS. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ ZFS О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. > О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ > О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫. > О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫ 4 О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫. Шел XXI век. yahoo так и не сумело в UTF-8. ПрЭлЭстно.
Re: научите systemd!
Artem Chuprina wrote: > Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Sat, 3 Mar 2018 > 21:50:51 +0300: > >> >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не > может > >> >> >> прописать зависимость от системного. (В документации, кстати, я > этого не > >> >> > А я вот не понимаю. Все эти приседания вокруг > Before|After|Requires|Want > >> >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с > D-BUS'ом. > >> >> Правов у него нет. Информация о зависимостях и, главное, степени > успеха > >> >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский > >> >> systemctl (или отдельный экземпляр systemd?) туда не пускают. > >> > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на спросить > - это > >> > ШЕСТЬ. Это даже не пять. > >> Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и > >> драйвера принтеров теперь зависят... > > Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это уже > > тонкости реализации. > Не, они там от policykit чего-то хотели. udev, в общем, Интересно, а зачем это нужно в случае принтера. С флешками как-то еще понятно, но вот с принтером... > отсоединен. Впрочем, кажется, то, чего они хотели от policykit, тоже > отсоединено, только надо более вдумчиво попинать aptitude. Увы - udev вмоноличен, а то что они идет отдельным пакетиком - так вышло. Как выкинут sysvinit - так сразу станет всё в одном. > >> > А расскажите мне, что вы так бегаете с этим zfs? Решение же не для > нищих, > >> > так еще и мертвое. Что вы в нем такого супер-пупер находите? > >> > Память жрет как свинья помои? Причем память подай с ECC и вагон. > >> > Компрессия? Восстановление данных после сбоя? > >> > Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут > во все места? > >> Вообще в SunOS было немало хороших вещей. Иногда стоит что-нибудь и > >> подтянуть. > > Зачем? Если она была такая все из себя перспективная и бац "тузик сдох и > > больше не воняет". А то что осталось от трупика - закопирайчено так, что > > даже не разлагается. > Маркетинговая политика у нее была никуда не годная. Вот и сдохло. Мы > тоже скоро сдохнем. А отдельные куски там были проработаны неплохо, нам > бы так. Не-не-не.. Идеи там конечно хорошие, но реализации и вобще вся инфраструктура - говно. Да еще и с затычками по времени, чтоб преставало работать после определенной даты. Померла - так померла. > >> Меня привлекает в нем идея, что можно делать тома с разными свойствами, > >> распределяемые по пространству диска динамически. Без танцев с ресайзом, > >> где каждую вторую файловую систему нельзя уменьшить без отмонтирования, > >> а каждую четвертую - и увеличить... > > А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант > > использования - петабайтные хранилища. Но там увы своё железо и свои fs. > Ровно наоборот. Когда диска некоторый дефицит. Когда диска дефицит - надо идти за новым. Или посылать счет в бухгалтерию. Собирать оделяо из лоскутков - ну, в виде развлечения и народных промыслов только интересно. > >> Еще в нем обещали намного более аккуратно сделанный рейд, нежели в > >> обычной архитектуре, с намного более нежным по отношению к дискам > >> ребилдом. Но на практике не проверял :) > > Эмм, сомнительное достижение. Любой контроллер имеет ручку rebuild rate, > > которую можно покрутить. > Говорю же, не проверял. Но в документации ссылаются на исследования из > датацентров, где рассказывают, что вероятность слета второго диска во > время ребилда оказывается несколько более высокой, чем хотелось бы. А > эти обещают, что они нежнее. Обещать - не значит жениться, блин. Диски в случае ребилда дохнут больше частью из-за того, что они из одной партии/коробки/уроненой при перегрузке палеты. Меняй диски планово, по достижению 2х-3х летнего срока эксплуатации с задержкой в 2-3 недели между заменой - и всё будет нормально. Но нет, это же raid, надо 5 лет жарить диски выской температурой, нагрузками и потом удивлятся - ой, а чё это они все разом сдохли? > >> Память он, кстати, жрет весьма умеренно, если дедупликацию не > >> включать. > >> totalusedfree shared buff/cache > available > >> Mem:3935296 2414300 1420856 29512 100140 > 1338100 > >> Swap: 4194300 46848 4147452 > >> Диск 4 терабайта, и помимо файлосерверения машина занята только > >> роутингом. Еще оно при записи подтормаживает, но там двухъядерный > >> гигагерцовый целерон, и включена компрессия. > > Файло помойка без роутинга, дисков на 8 терабайт: > > totalusedfree shared buff/cache > available > > Mem:8172772 103200 288628 29116 7780944 > 7734592 > > Swap: 1951740 0 1951740 > > ZFS и компрессии нет, да. > Если ты хотел помериться, то ты победил. Но я мериться не предлагал. Я >
Re: научите systemd!
On 03/04/18 11:14, D. H. wrote: > О©╫О©╫О©╫-О©╫О©╫ О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫. О©╫О©╫О©╫ > О©╫О©╫О©╫ О©╫О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫" > ZFS. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ ZFS О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. > О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ > О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫. > > О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫ 4 О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ > О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫ > О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫. > Что то неладно в кодировке... (проверил в web-view, то же самое: https://lists.debian.org/debian-russian/2018/03/msg00025.html)
Re: научите systemd!
О©╫О©╫О©╫-О©╫О©╫ О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫. О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫" ZFS. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ ZFS О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫ 4 О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫.
Re: научите systemd!
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Sat, 3 Mar 2018 21:50:51 +0300: >> >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может >> >> >> прописать зависимость от системного. (В документации, кстати, я >> этого не >> >> > А я вот не понимаю. Все эти приседания вокруг >> Before|After|Requires|Want >> >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с >> D-BUS'ом. >> >> Правов у него нет. Информация о зависимостях и, главное, степени успеха >> >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский >> >> systemctl (или отдельный экземпляр systemd?) туда не пускают. >> > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на спросить - >> это >> > ШЕСТЬ. Это даже не пять. >> Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и >> драйвера принтеров теперь зависят... > Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это уже > тонкости реализации. Не, они там от policykit чего-то хотели. udev, в общем, отсоединен. Впрочем, кажется, то, чего они хотели от policykit, тоже отсоединено, только надо более вдумчиво попинать aptitude. >> > А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих, >> > так еще и мертвое. Что вы в нем такого супер-пупер находите? >> > Память жрет как свинья помои? Причем память подай с ECC и вагон. >> > Компрессия? Восстановление данных после сбоя? >> > Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во >> все места? >> Вообще в SunOS было немало хороших вещей. Иногда стоит что-нибудь и >> подтянуть. > Зачем? Если она была такая все из себя перспективная и бац "тузик сдох и > больше не воняет". А то что осталось от трупика - закопирайчено так, что > даже не разлагается. Маркетинговая политика у нее была никуда не годная. Вот и сдохло. Мы тоже скоро сдохнем. А отдельные куски там были проработаны неплохо, нам бы так. >> Меня привлекает в нем идея, что можно делать тома с разными свойствами, >> распределяемые по пространству диска динамически. Без танцев с ресайзом, >> где каждую вторую файловую систему нельзя уменьшить без отмонтирования, >> а каждую четвертую - и увеличить... > А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант > использования - петабайтные хранилища. Но там увы своё железо и свои fs. Ровно наоборот. Когда диска некоторый дефицит. >> Еще в нем обещали намного более аккуратно сделанный рейд, нежели в >> обычной архитектуре, с намного более нежным по отношению к дискам >> ребилдом. Но на практике не проверял :) > Эмм, сомнительное достижение. Любой контроллер имеет ручку rebuild rate, > которую можно покрутить. Говорю же, не проверял. Но в документации ссылаются на исследования из датацентров, где рассказывают, что вероятность слета второго диска во время ребилда оказывается несколько более высокой, чем хотелось бы. А эти обещают, что они нежнее. >> Память он, кстати, жрет весьма умеренно, если дедупликацию не >> включать. >> totalusedfree shared buff/cache >> available >> Mem:3935296 2414300 1420856 29512 100140 >> 1338100 >> Swap: 4194300 46848 4147452 >> Диск 4 терабайта, и помимо файлосерверения машина занята только >> роутингом. Еще оно при записи подтормаживает, но там двухъядерный >> гигагерцовый целерон, и включена компрессия. > Файло помойка без роутинга, дисков на 8 терабайт: > totalusedfree shared buff/cache > available > Mem:8172772 103200 288628 29116 7780944 > 7734592 > Swap: 1951740 0 1951740 > ZFS и компрессии нет, да. Если ты хотел помериться, то ты победил. Но я мериться не предлагал. Я всего лишь показал, что у меня оно в небольшую, в общем, память нормально влезает. >> Компрессия, да, приятное дополнение, но насколько я понимаю, ее и еще >> кто-то умел. Вдумчивая проверка целостности - но да, ECC оно хочет. Но >> они меня, в общем, убедили, что если хочешь целостности, надо хотеть и >> ECC. С любой FS. Просто без ECC ZFS в случае сбоев памяти начнет >> ругаться раньше, когда меньше данных поломали. А остальные будут делать >> вид, что все хорошо. > А как ваш волшебный ZFS догадается, что произошла битовая ошибка в момент > чтения памяти контроллером DMA при перекачке странцы в контроллер SATA? > Только считав её (страницу) назад с диска и сравнив checksumm? Да. У него для этого специальная ручка есть, рекомендуемая для запуска по крону. > А если взять более реальный вариант обсчета каких нибудь матриц в GPU - то > туда тоже заносить память с ECC? Вот ведь геймеры будут рады, что их шейдеры > теперь защищены ценой потери производительности в 3-5% и ценником на видяху > в 15-20%. А геймерам целостность низачем. >> Как у нас сейчас на разных FS обстоят дела с восстановлением после сбоя, >> я не
Re: научите systemd!
Dmitry Kulagin wrote: > > А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих, > > так еще и мертвое. Что вы в нем такого супер-пупер находите? > > Память жрет как свинья помои? Причем память подай с ECC и вагон. > > Компрессия? Восстановление данных после сбоя? > > Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во > > все места? > > > Так нет же ничего иного, если нужно больше, чем просто фс на диске: > RAID, отдельный контроллер > ssd кеш, там-же, на контроллере. > снапшоты, компрессия, блочные устройства с thin provisioning в общем > пространстве > данных, дедупликация для backup; Фичи сомнительной нужности. Компрессию сейчас почти всё само умеет, то что не умеет - можно заставить через fusecompress. С дедупликацией - в реальной жизни это надо всяческим хостерам, у который по 1000 псевдовиртуалок с одним и тем-же набором хлама. Но сейчас этот набор хлама можно подавать через overlayfs всем желающим. Дедуплцированный бакап - это какой-то оксюморон получается. Накрылась одна и единственная копия файлика - всем остальным тоже хана? Или будем его плотно обмазывать Ридом-Соломоном? Снапшоты.. никогда не понимал нужность этой радости. > ну кроме btrfs, которая не умеет часть > из выше перечисленного. > MDRAID и LVM в Linux не умеют Write Barriers сквозь себя пропускать от > файловой > системы, и я замучился чинить xfs после отключений питания, а fs > непосредственно > на диске без lvm - чинить не надо... lvm сам по себе лишняя абстрация. А UPS придумали трусы наверное? > О systemd! Никто не знает, почему при установке пакета, который > добавляет и запускает > новый сервис systemd, компьютер виснет наглухо с запущенными виртуалками > kvm, если > их остановить предварительно, то все работает, и без systemd все работает?..
Re: научите systemd!
Artem Chuprina wrote: > Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 26 Feb 2018 > 22:45:28 +0300: > >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может > >> >> прописать зависимость от системного. (В документации, кстати, я этого > не > >> > А я вот не понимаю. Все эти приседания вокруг > Before|After|Requires|Want > >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с > D-BUS'ом. > >> Правов у него нет. Информация о зависимостях и, главное, степени успеха > >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский > >> systemctl (или отдельный экземпляр systemd?) туда не пускают. > > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на спросить - это > > ШЕСТЬ. Это даже не пять. > Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и > драйвера принтеров теперь зависят... Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это уже тонкости реализации. > >> >> нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой > >> >> архитектуры до сих пор не поскользнулся на арбузной корке... > >> > А зачем ему убиваться-то? Вся аудитория этого комбайна - качественно > >> > окучена до предела "а вы так не делайте", скоро будет переустанавливать > >> > систему если DM не запускается. Или в платный саппорт. > >> Угу. Я уже тут прошелся по граблям с тем же zfs. Конфиги для старта в > >> дистрибутиве у него есть только для systemd, поэтому на сервере, где у > >> меня zfs, я его оставил. Ну и... zfs mount -a при старте системы > > А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих, > > так еще и мертвое. Что вы в нем такого супер-пупер находите? > > Память жрет как свинья помои? Причем память подай с ECC и вагон. > > Компрессия? Восстановление данных после сбоя? > > Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во > все места? > Вообще в SunOS было немало хороших вещей. Иногда стоит что-нибудь и > подтянуть. Зачем? Если она была такая все из себя перспективная и бац "тузик сдох и больше не воняет". А то что осталось от трупика - закопирайчено так, что даже не разлагается. Вон один уже повосхищался идеями из SMF. Скажите спасибо, что вы еще XML не редактируете в java тулзе. > Меня привлекает в нем идея, что можно делать тома с разными свойствами, > распределяемые по пространству диска динамически. Без танцев с ресайзом, > где каждую вторую файловую систему нельзя уменьшить без отмонтирования, > а каждую четвертую - и увеличить... А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант использования - петабайтные хранилища. Но там увы своё железо и свои fs. > Еще в нем обещали намного более аккуратно сделанный рейд, нежели в > обычной архитектуре, с намного более нежным по отношению к дискам > ребилдом. Но на практике не проверял :) Эмм, сомнительное достижение. Любой контроллер имеет ручку rebuild rate, которую можно покрутить. > Память он, кстати, жрет весьма умеренно, если дедупликацию не > включать. > totalusedfree shared buff/cache > available > Mem:3935296 2414300 1420856 29512 100140 > 1338100 > Swap: 4194300 46848 4147452 > Диск 4 терабайта, и помимо файлосерверения машина занята только > роутингом. Еще оно при записи подтормаживает, но там двухъядерный > гигагерцовый целерон, и включена компрессия. Файло помойка без роутинга, дисков на 8 терабайт: totalusedfree shared buff/cache available Mem:8172772 103200 288628 29116 7780944 7734592 Swap: 1951740 0 1951740 ZFS и компрессии нет, да. > Компрессия, да, приятное дополнение, но насколько я понимаю, ее и еще > кто-то умел. Вдумчивая проверка целостности - но да, ECC оно хочет. Но > они меня, в общем, убедили, что если хочешь целостности, надо хотеть и > ECC. С любой FS. Просто без ECC ZFS в случае сбоев памяти начнет > ругаться раньше, когда меньше данных поломали. А остальные будут делать > вид, что все хорошо. А как ваш волшебный ZFS догадается, что произошла битовая ошибка в момент чтения памяти контроллером DMA при перекачке странцы в контроллер SATA? Только считав её (страницу) назад с диска и сравнив checksumm? А если взять более реальный вариант обсчета каких нибудь матриц в GPU - то туда тоже заносить память с ECC? Вот ведь геймеры будут рады, что их шейдеры теперь защищены ценой потери производительности в 3-5% и ценником на видяху в 15-20%. ECC - это увы очень дорогостоящий обвес, т.к. затрагивает не только саму планку памяти - а все шины до перефирии. > Как у нас сейчас на разных FS обстоят дела с восстановлением после сбоя, > я не копал. Журналируемая каждая первая, скоро, наверное, уже > журналируемый FAT сделают. А вот насколько хорошо оно восстанавливается, > если что... В документации на ZFS было довольно подробно расписано, > когда у нее что
Re: научите systemd!
А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих, так еще и мертвое. Что вы в нем такого супер-пупер находите? Память жрет как свинья помои? Причем память подай с ECC и вагон. Компрессия? Восстановление данных после сбоя? Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во все места? Так нет же ничего иного, если нужно больше, чем просто фс на диске: RAID, ssd кеш, снапшоты, компрессия, блочные устройства с thin provisioning в общем пространстве данных, дедупликация для backup; ну кроме btrfs, которая не умеет часть из выше перечисленного. MDRAID и LVM в Linux не умеют Write Barriers сквозь себя пропускать от файловой системы, и я замучился чинить xfs после отключений питания, а fs непосредственно на диске без lvm - чинить не надо... О systemd! Никто не знает, почему при установке пакета, который добавляет и запускает новый сервис systemd, компьютер виснет наглухо с запущенными виртуалками kvm, если их остановить предварительно, то все работает, и без systemd все работает?..
Re: научите systemd!
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 26 Feb 2018 22:45:28 +0300: >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может >> >> прописать зависимость от системного. (В документации, кстати, я этого не >> > А я вот не понимаю. Все эти приседания вокруг Before|After|Requires|Want >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с D-BUS'ом. >> Правов у него нет. Информация о зависимостях и, главное, степени успеха >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский >> systemctl (или отдельный экземпляр systemd?) туда не пускают. > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на спросить - это > ШЕСТЬ. Это даже не пять. Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и драйвера принтеров теперь зависят... >> >> нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой >> >> архитектуры до сих пор не поскользнулся на арбузной корке... >> > А зачем ему убиваться-то? Вся аудитория этого комбайна - качественно >> > окучена до предела "а вы так не делайте", скоро будет переустанавливать >> > систему если DM не запускается. Или в платный саппорт. >> Угу. Я уже тут прошелся по граблям с тем же zfs. Конфиги для старта в >> дистрибутиве у него есть только для systemd, поэтому на сервере, где у >> меня zfs, я его оставил. Ну и... zfs mount -a при старте системы > А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих, > так еще и мертвое. Что вы в нем такого супер-пупер находите? > Память жрет как свинья помои? Причем память подай с ECC и вагон. > Компрессия? Восстановление данных после сбоя? > Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во все > места? Вообще в SunOS было немало хороших вещей. Иногда стоит что-нибудь и подтянуть. Меня привлекает в нем идея, что можно делать тома с разными свойствами, распределяемые по пространству диска динамически. Без танцев с ресайзом, где каждую вторую файловую систему нельзя уменьшить без отмонтирования, а каждую четвертую - и увеличить... Еще в нем обещали намного более аккуратно сделанный рейд, нежели в обычной архитектуре, с намного более нежным по отношению к дискам ребилдом. Но на практике не проверял :) Память он, кстати, жрет весьма умеренно, если дедупликацию не включать. totalusedfree shared buff/cache available Mem:3935296 2414300 1420856 29512 100140 1338100 Swap: 4194300 46848 4147452 Диск 4 терабайта, и помимо файлосерверения машина занята только роутингом. Еще оно при записи подтормаживает, но там двухъядерный гигагерцовый целерон, и включена компрессия. Компрессия, да, приятное дополнение, но насколько я понимаю, ее и еще кто-то умел. Вдумчивая проверка целостности - но да, ECC оно хочет. Но они меня, в общем, убедили, что если хочешь целостности, надо хотеть и ECC. С любой FS. Просто без ECC ZFS в случае сбоев памяти начнет ругаться раньше, когда меньше данных поломали. А остальные будут делать вид, что все хорошо. Как у нас сейчас на разных FS обстоят дела с восстановлением после сбоя, я не копал. Журналируемая каждая первая, скоро, наверное, уже журналируемый FAT сделают. А вот насколько хорошо оно восстанавливается, если что... В документации на ZFS было довольно подробно расписано, когда у нее что куда пишется, и где делается синхронизация на диски.
Re: научите systemd!
Artem Chuprina wrote: > Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 26 Feb 2018 > 17:23:00 +0300: > >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может > >> прописать зависимость от системного. (В документации, кстати, я этого не > > А я вот не понимаю. Все эти приседания вокруг Before|After|Requires|Want > > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с D-BUS'ом. > Правов у него нет. Информация о зависимостях и, главное, степени успеха > запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский > systemctl (или отдельный экземпляр systemd?) туда не пускают. Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на спросить - это ШЕСТЬ. Это даже не пять. > >> нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой > >> архитектуры до сих пор не поскользнулся на арбузной корке... > > А зачем ему убиваться-то? Вся аудитория этого комбайна - качественно > > окучена до предела "а вы так не делайте", скоро будет переустанавливать > > систему если DM не запускается. Или в платный саппорт. > Угу. Я уже тут прошелся по граблям с тем же zfs. Конфиги для старта в > дистрибутиве у него есть только для systemd, поэтому на сервере, где у > меня zfs, я его оставил. Ну и... zfs mount -a при старте системы А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих, так еще и мертвое. Что вы в нем такого супер-пупер находите? Память жрет как свинья помои? Причем память подай с ECC и вагон. Компрессия? Восстановление данных после сбоя? Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во все места?
Re: научите systemd!
Victor Wagner wrote: > В Mon, 26 Feb 2018 15:20:32 +0300 > Artem Chuprina пишет: > > Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может > > прописать зависимость от системного. (В документации, кстати, я этого > > не нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой > > архитектуры до сих пор не поскользнулся на арбузной корке... > > > ' > Потому что юзеры, порченные мукой и чародейством Билла Гейтса и Стива > Джобса, обожают терпеть мелкие неудобства. > И вообще человек много что готов вытерпеть ради того, чтобы не думать, > не понимать и не брать на себя ответственность. А им не надо - им дядя с галстуком рассказал, что "положите сюда файлик - у вас всё будет". Ну вот у них "всё было" (C)
Re: научите systemd!
В Mon, 26 Feb 2018 15:20:32 +0300 Artem Chuprina пишет: > Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может > прописать зависимость от системного. (В документации, кстати, я этого > не нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой > архитектуры до сих пор не поскользнулся на арбузной корке... > ' Потому что юзеры, порченные мукой и чародейством Билла Гейтса и Стива Джобса, обожают терпеть мелкие неудобства. И вообще человек много что готов вытерпеть ради того, чтобы не думать, не понимать и не брать на себя ответственность. -- Victor Wagner
Re: научите systemd!
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 26 Feb 2018 17:23:00 +0300: >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может >> прописать зависимость от системного. (В документации, кстати, я этого не > А я вот не понимаю. Все эти приседания вокруг Before|After|Requires|Want > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с D-BUS'ом. Правов у него нет. Информация о зависимостях и, главное, степени успеха запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский systemctl (или отдельный экземпляр systemd?) туда не пускают. >> нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой >> архитектуры до сих пор не поскользнулся на арбузной корке... > А зачем ему убиваться-то? Вся аудитория этого комбайна - качественно > окучена до предела "а вы так не делайте", скоро будет переустанавливать > систему если DM не запускается. Или в платный саппорт. Угу. Я уже тут прошелся по граблям с тем же zfs. Конфиги для старта в дистрибутиве у него есть только для systemd, поэтому на сервере, где у меня zfs, я его оставил. Ну и... zfs mount -a при старте системы почему-то уверенно не поднимает один из томов (там довольно хитрые настройки с правами и case sensitivity, это раздел, который отдается по самбе виндам, по локалке, без пароля). А после старта системы почему-то столь же уверенно поднимает. После чего, разумеется, приходится передергивать samba и nfsd, потому что собственные возможности zfs по шарингу тома мне недостаточны (он как бы умеет при подключении тома рассказать самбе и nfsd, что его надо расшарить, но не умеет при этом рассказать нужные мне опции). Причем zfs mount -a приходится говорить руками, systemctl restart zfs-mount не помогает. Хотя, глядя на unit, я не могу понять, с какого перепугу он не помогает. Там все тупо. И почему-то столь же упорно при старте системы не поднимается сервер rsync, но опять же, на ура рестартится после подъема, на сей раз уже средствами systemctl. И ничего содержательного на эту тему в логах обнаружить не удается. Разве что systemd тупо пытается запустить тот же rsync раньше времени, раньше времени сочтя, что файловые системы смонтировались. Я вот разнесу сервер и роутер, и таки поставлю туда sysvinit-core, вписав одну несчастную строчку в скрипт старта файловых систем... Сейчас вот роутер туда на замену настраивал - первым делом поставил sysvinit-core. Роутер на шкафу должен загружаться уверенно, а не мгновенно, и init в нем не должен падать, унося с собой всю систему, от неудачного DNS-ответа на свой запрос (не говоря уже о том, что init'у вообще не о чем спрашивать DNS).
Re: научите systemd!
On 26/02/18 10:14, Victor Wagner wrote: > Может все-таки install надо было что-то другое? > lightdm к примеру? Лет десять назад я настроил xdm, он у меня красивый, мне нравится. Всё работает как и раньше, зачем его менять. Но хоронить его придётся --- wayland потихоньку грядёт. > Или gdm? 0 upgraded, 107 newly installed, 0 to remove and 2 not upgraded. Need to get 82.9 MB of archives. After this operation, 260 MB of additional disk space will be used. НЕТ! > Лично мне появившаяся в современных дисплей-менеджерах возможность при > попытке логина другого пользователя в залоченную сессию, создавать > вторую сессию, кажется крайне удобной и полезной. Согласен, но у мне это не нужно. А тем кому нужно я так и делаю. -- sergio
Re: научите systemd!
Artem Chuprina wrote: > Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 26 Feb 2018 > 12:45:52 +0300: > >> > А как включить его обратно? > >> Обратно, конечно, так: > >> # apt remove xdm && apt install xdm > > Не умеешь сам - не учих других плохому. > > apt install --reinstall xdm > >> это же systemd. > > Нет, это его последователи. Которым пофигу какую документацию не читать. > > Для временного выключения в этом комбайне больше подходят mask/unmask > ${service} > Не так, кстати, просто в этой документации что-то найти... Я не так > давно синтаксис сервис-файлов читал, так он оказался раскидан минимум по > трем мануалам, и это я, наверное, еще чего-то не нашел... Хотя, надо > сказать, когда находишь нужное место, оно обычно написано довольно > внятно. А зачем тебе искать-то? Вон комитет выбрал себе путь "более удобного и всеми любимого init-manager" - надо открывать багу и пусть те, кто выбирал - разбираются, почему собственно и чинят. > Но anyway, нифига не понятно, почему после disable не получается сказать > enable. Дык, потому что последний раз xdm паковали в 2015 году, а комбайн уже по ходу движения успели 5 раз отрихтовать и сменить траекторию. > Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может > прописать зависимость от системного. (В документации, кстати, я этого не А я вот не понимаю. Все эти приседания вокруг Before|After|Requires|Want напоминают те-же циферки в sysvinit. Только в профиль. Теперь с D-BUS'ом. > нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой > архитектуры до сих пор не поскользнулся на арбузной корке... А зачем ему убиваться-то? Вся аудитория этого комбайна - качественно окучена до предела "а вы так не делайте", скоро будет переустанавливать систему если DM не запускается. Или в платный саппорт.
Re: научите systemd!
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 26 Feb 2018 12:45:52 +0300: >> > А как включить его обратно? >> Обратно, конечно, так: >> # apt remove xdm && apt install xdm > Не умеешь сам - не учих других плохому. > apt install --reinstall xdm >> это же systemd. > Нет, это его последователи. Которым пофигу какую документацию не читать. > Для временного выключения в этом комбайне больше подходят mask/unmask > ${service} Не так, кстати, просто в этой документации что-то найти... Я не так давно синтаксис сервис-файлов читал, так он оказался раскидан минимум по трем мануалам, и это я, наверное, еще чего-то не нашел... Хотя, надо сказать, когда находишь нужное место, оно обычно написано довольно внятно. Но anyway, нифига не понятно, почему после disable не получается сказать enable. Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может прописать зависимость от системного. (В документации, кстати, я этого не нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой архитектуры до сих пор не поскользнулся на арбузной корке...
Re: научите systemd!
sergio wrote: > On 25/02/18 08:59, sergio wrote: > > А как включить его обратно? > Обратно, конечно, так: > # apt remove xdm && apt install xdm Не умеешь сам - не учих других плохому. apt install --reinstall xdm > это же systemd. Нет, это его последователи. Которым пофигу какую документацию не читать. Для временного выключения в этом комбайне больше подходят mask/unmask ${service}
Re: научите systemd!
On Mon, 26 Feb 2018 03:38:06 +0300 sergio wrote: > On 25/02/18 08:59, sergio wrote: > > > А как включить его обратно? > > Обратно, конечно, так: > > # apt remove xdm && apt install xdm Может все-таки install надо было что-то другое? lightdm к примеру? Или gdm? Лично мне появившаяся в современных дисплей-менеджерах возможность при попытке логина другого пользователя в залоченную сессию, создавать вторую сессию, кажется крайне удобной и полезной.
Re: научите systemd!
On 25/02/18 08:59, sergio wrote: > А как включить его обратно? Обратно, конечно, так: # apt remove xdm && apt install xdm это же systemd. -- sergio
научите systemd!
Утро! Внезапно мне понадобилось выключить xdm на время. Ну я сказал # systemctl disable xdm и xdm на время выключился. А как включить его обратно? # systemctl enable xdm Synchronizing state of xdm.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable xdm The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. -- sergio