systemd 233

рм -рф...
дд...

Дружелюбное и профессиональное линукс-комьюнити во всей красе.

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

Каково это, интересно, хейтить здесь прямо на лоре, который сам запускается из-под systemd?

Люди хейтят применительно к своему локалхосту, а что там на интернетовских серверах всем фиолетово.

Откуда копипасту брал?

Эх, жаль Александр Сергеевич не дожил.
PS: речь про Грибоедова.

Это тот кто писал «горе от ума»? а кому горе он забыл уточнить или как? а то в школе так и не рассказали кому горе.

Может лучше починить кривых демонов?

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

Но не наоборот-же...

Аргумент непреодолимой силы. Почему должно быть наоборот-то?
https://www.opennet.ru/tips/2589_cgroups_linux_limit.shtml
Был ещё демон для аналогичной задачи, написанный кем-то в порыве поттерингофобии. Давно про него ничего не слышно. Где применяется не в курсе.

Так при чем тут сЫстемд?

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

И что? То что что-то есть в сЫстемд не значит что этого больше ни где нет.

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

Я спросил, в чём конкретно плюс, в частности чтобы понять, а стоит-ли знакомиться плотно с этой матчастью.

Плюсы для кого-то тебе могут казаться минусами и наоборот, для примера:
1) интеграция в проект (или написание своих велосипедных компонент) всего, что требуется для менеджмента системы: таймеры, управление сетью, клиент ntp, генерация resolv.conf, свои логи и т.д.
Плюс — чтобы создать минимально самодостаточную функционирующую систему уже практически достаточно компонентов systemd без привлечения стороннего зоопарка. Это позволяет завернуть корень в initrd и вообще его монтировать только для чтения. Вся остальная система монтируется в /usr.
Минус — знающие люди говорят про низкое качество кода, отсутствие ревью и планирования. Недавняя уязвимость говорит о том же. Проект молодой, сколько багов ещё выйдет наружу никому не известно, в том числе и архитектурных просчётов. Плюс к этому процессом номер один в системе получается весьма жирный бинарник, с кучей зависимостей, а значит и потенциальных уязвимостей с их стороны.
2) Межпроцессное взаимодействие через дбас.
Это также одновременно и плюс и минус. Поскольку тормоз, а ядерной реализации до сих пор нет и будет ли она неизвестна. Зависимость от дбаса тоже является предметом критики. С другой стороны дбас хоть как-то более-менее стандартен. Формат вывода программы может поменяться и сломать парсинг. Пример недавно был, когда шифрование происходило с паролем «p».
3) Скриптовая лапша в инитах заменена такой же лапшой юнитов.
Тут уж и вовсе вкусовщина. Но, любители скриптов могут вполне их использовать, а в юнитах оперировать этими скриптами. С одной стороны это должно радовать, но почему-то наоборот сильно огорчает радетелей прежнего порядка. Сами претензии к юнитам, их сложности, дроблёности и т.д. на мой взгляд выглядят насосанными из пальца. Юниты проще, просты просто до безобразия. И до безобразия стандартны, в отличие от инит-скриптов, которые в каждом дистрибутиве лепили по своему обобому.
4) скорость загрузки
если когда-то это и было плюсом, то сейчас это скорее приятный бонус, поскольку systemd уже переросла фазу простой пускалки дерева процессов. Если уж быть честным, то добиться такой же скорости не проблема и с другими системами инициализации.
5) как я уже говорил, это уже в продакшене и будет там ещё очень долго
здесь минусы и плюсы вообще из разряда синдрома утёнка и большинство критиков в жизни не написали самостоятельно ни одного инит-скрипта.
Шапке это нужно в первую очередь для виртуалок. Те дистрибутивы, у кого хватает сил поддерживать свои системы инициализации без проблем это делают. Выбор всегда есть. Хотя у корпоративщиков его и отняли фактически, но мы за это деньги получаем.
6) фактически systemd единственная система, которая использует нововведения в ядре. Здесь уже полезность и бесполезность определяется назначением самой системы. В системе управления инкубатором это всё нна не надо.

Ты же сам хамишь и отсылаешь к тому что мне не нужно.

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

Все мои вопросы, в том числе касательно ваших знаний так и остались открыты.

Я не в курсе того, что именно ты хочешь услышать.
Задай конкретный вопрос — получишь конкретный ответ. Никто тебе войну и мир на твой риторический вопрос тут писать не будет. И не тебе закрывать вопросы моих знаний.

Это тот кто писал «горе от ума»?

Да

а кому горе он забыл уточнить или как?

Не успел, убили его.

Я ытаюсь найти плюсы и понять фанатичное «ЗА SYSTEMD, ВАТАКУ»...

Проблем особо нет. Другое дело что:

systemd довольно не маленький комбайн, его сейчас везде пихают как только могут. (прочитал тут в мифах что он типа модульный. а зависимостей как будто нет) Если он так попрет, то другие системы инициализации рано или поздно склеют ласты.

При этом все радостно орут как оно тыкается мышкой, вообще «няшно и кошегно».

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

Если действительно в нём всё лучше/быстрее/стабильнее работает, то нужно уже изучать. Теб более сам десктоп обновил, так что теперь сам на системд. А если реально плюсов нет, а это крики неквалифецированных мышевозов, то ну его в топку и лучше поискать куда от него бежать.

Ответы «учи матчасть» меня не устраивают. Школьник может потратить недельку поизучав просто так системд, мне и без него хватает гемороя.

Собственно почему спрашиваю «серьёзно, чем оно лучше?». Ну а люди уже тролят сами себя, тоже забавно.

Если он так попрет, то другие системы инициализации рано или поздно склеют ласты.

Неужели они будут не нужны даже своим авторам?

Авторам может и будут нужны. Только авторов не много. А чем меньше людей работают над каким-то ПО тем больше в нём багов, либо уже направленность.

кормить троллей
провокатор

Does not compute.

Вот уже более адекватный ответ. Однако это уже известно.

По факту у системд нету плюсов, кроме «это красношапка» и всех новых фич за счет этого. В фанатизм скатываться не будем, но пока готовя ЛЮБУЮ систему для определенных нужд (не многоцелевую) очевидным будет избегать системд.

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

Я ытаюсь найти плюсы и понять фанатичное «ЗА SYSTEMD, ВАТАКУ»...

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

Лично я в большинстве случаев встречаюсь с инитами в виртуалках при подготвке каких-либо сервисов. В такой ситуации для меня плюсы следующие:

• Системд везде одинаковый. Берёшь любой современный мэйнстрим дистрибутив, и там системд. Он везде конфигурируется одинаково, управляется одинаково, юниты везде практически одинаковые (различия могут быть, но они минимальны). Если, для сравнения взять предыдущие выпуски debian и centos, то там инит скрипты просто полные противоположности.
• Синтаксис юнитов простой, читанув манца можно быстро навертеть вмеру сложной логики, и она будет работать.
• journalctl просто прекрасен. Но есть существенный косяк. На действительно больших объемах логов он тормозит безбожно. В таких ситуациях приходится выбирать альтернативные логи для сервиса. Надеюсь в будующем ситуация исправится. Но у меня это редкая ситуация.
• Он хорошо работает с кривыми сервисами и позволяет с минимальными телодвижениями обеспечивать приемлимую их работоспособность. Сейчас, возможно, набегут школьники, рассказывающие, что если какой-то сервис не может наработать 100500 часов без утечек/крэшей/висюнов, то он недостоен быть запущенным. Но чуть более адекватные люди знают, что это отнюдь не всегда так.

Ну это так, навскидку. Для более детальных обсуждений, нужна более узкая область.

Если он так попрет, то другие системы инициализации рано или поздно склеют ласты.

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

При этом все радостно орут как оно тыкается мышкой, вообще «няшно и кошегно».

Ты что-то прогоняешь. Тут наоборот искали, с помощью чего бы тыкать мышкой.

Одновременно нет ни одного адекватного сравнения по фичам/быстродействию/стабильности.

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

Любой вопрос, потипу моего изначального воспринимается как вброс.

Потому что это и есть вброс.

А если реально плюсов нет

Для тебя может и не быть. Но надо искать не плюсы, а минусы. Если минусов нет, то изучать. Иначе искать альтернативы. Ибо это уже стандарт инициализации линукса. И любые поделки без системд скоро пользователями будут восприниматься как маргинальное говно, в котором хрен разберёшься.

Собственно почему спрашиваю «серьёзно, чем оно лучше?».

Спрашиваешь серьёзно - озвучь область применения.

По факту у системд нету плюсов, кроме ... всех новых фич за счет этого.
Это не вброс.
Я серьёзно спрашиваю.

Будь чуть более адекватен, а то так совсем не интересно.

прочитал тут в мифах что он типа модульный

qlist systemd | grep ^/usr/bin | wc -l
37

а зависимостей как будто нет

Хм... А это что?
ldd $(qlist systemd | grep ^/usr/bin) | awk '/=/{ print $1 }' | sort | uniq
libacl.so.1
libattr.so.1
libaudit.so.1
libblkid.so.1
libcap-ng.so.0
libcap.so.2
libcrypt.so.1
libc.so.6
libdl.so.2
libidn.so.11
libip4tc.so.0
libkmod.so.2
liblz4.so.1
liblzma.so.5
libmount.so.1
libm.so.6
libpam.so.0
libpcre.so.1
libpthread.so.0
libqrencode.so.3
librt.so.1
libseccomp.so.2
libselinux.so.1
libsystemd-shared-233.so
libuuid.so.1
libz.so.1

При этом все радостно орут как оно тыкается мышкой

Первый раз от тебя слышу

Одновременно нет ни одного адекватного сравнения по фичам/быстродействию/стабильности.
по фичам

ты же сам написал, что тебе это не нужно

быстродействию

быстродействию чего? старт/стоп юнита?

стабильности

Недавно дыру нашли, которая приводила к локальному дос.

Ответы «учи матчасть» меня не устраивают.

то есть прочитать мануал к systemctl и journalctl для тебя геморрой? Ок

Из минусов - постепенное вытеснение других систем инициализации

Да лаадно. Это что называется придраться не к чему. Вон linux по сути убил hurd, только сколько людей говорят что за это linux надо закапать?

По факту у системд нету плюсов, кроме «это красношапка» и всех новых фич за счет этого.

Ок. Значит у тебя нет областей применения, где systemd имеет преимущество.

В фанатизм скатываться не будем, но пока готовя ЛЮБУЮ систему для определенных нужд (не многоцелевую) очевидным будет избегать системд.

Ок. Твоё право. Никто тебе ничего не навязывает.

Из минусов - постепенное вытеснение других систем инициализации

Можно услышать все минусы?
А то обозначенный явно и откровенно трололошный.

Ах, да.

Вот уже более адекватный ответ. Однако это уже известно.

Спроси конкретнее, что тебе нужно знать.
Про модульность и зависимости я тебе уже ответил на «мифы и опровержения» конкретным ответом. Могу повторить без wc -l в финале, если хочешь.

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

то есть прочитать мануал к systemctl и journalctl для тебя геморрой?

Не геморрой, я задаю вопрос «чем реально серьёзно лучше?» ответом на него не моет быть по факту «иди читай ман такой-то». Ну да, прочту, и что? Я спрашивал именно про общее описание плюсов минусов, что и получил.

Для себя могу сказать - мне оно не нужно. Я не люблю леззть в чужой огород, однако, как уже обсуждалось выше, я не лезу, однако «Если Вы не идёте к системд, то оно идёт к Вам...» И это мне совсем не нравится.

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

Дружелюбное и профессиональное линукс-комьюнити во всей красе.

Заботливое, самое главное. Не оставили без внимания крик души арчевода-сустемдик-хейтера.

Каково это, интересно, хейтить здесь прямо на лоре, который сам запускается из-под systemd?

Как будто пока лор крутился на фёдоре это мешало её хейтить. Да и линукс-ненавистников тут достаточно.

Вот список из девятого дебиана:
libacl.so.1
libapparmor.so.1
libattr.so.1
libaudit.so.1
libblkid.so.1
libcap-ng.so.0
libcap.so.2
libc.so.6
libdl.so.2
libgcrypt.so.20
libgpg-error.so.0
libidn.so.11
liblz4.so.1
liblzma.so.5
libmount.so.1
libm.so.6
libpam.so.0
libpcre.so.3
libpthread.so.0
librt.so.1
libseccomp.so.2
libselinux.so.1
libsystemd-shared-232.so
libuuid.so.1

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

Назови знакомый, может у меня есть развёрнутый в виртуалке.

Но всё-таки комбайн, собирать с ним ось под встраивание или любой другой аплаинс просто глупо.

То есть к двухсотому комментарию удалось вытянуть, что ты эмбедщик.
Здесь есть твой коллега, который применяет systemd у себя, говорит что примерно то же на то же выходит. Если он сюда заглянет, вам будет о чём поговорить. Если бы я ещё ник помнил, кастанул бы.
И не обязательно использовать все компоненты. Насколько я понимаю, то обязательны всего лишь четыре: login, journal, сам systemd и systemctl. Насчёт обязательности login, да и systemctl не уверен.
С обычным инитом тебе точно также будут нужны эти же компоненты.
Но, в эмбедде я не специалист. В принципе если железка однозадачная, а ядро полностью инициализирует железку, то инитом может быть сразу сама программа, без костылей.

Я спрашивал именно про общее описание плюсов минусов, что и получил.

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

Для себя могу сказать - мне оно не нужно.

А, ну теперь намного понятнее стало.

вот это как мне через гуи этот сделать?

systemctl disable dnf-makecache.service systemctl disable dnf-makecache.timer

Был-бы ещё, скажем, lua в качестве языка для настройки всего этого дела

Что за дурацкая мания пытаться засунуть Тьюринг-полный язык куда надо и, особенно, куда не надо? Хорошо что у Леннарта есть мозг и, как следствие, он этому синдрому не подвержен.

«Ключ на старт. Зажигание!»

Махмуд, паджигай! :)

таймеры

cron для слабаков?

управление сетью

а что не так было с управлением сетью ранее?

клиент ntp

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

генерация resolv.conf

зачем его генерировать?

свои логи

логгеров в мире написано предостаточно

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

вантуз не напоминает? какой зоопарк, омг? все что нужно обычно было в комплекте современных ОС еще до systemd

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

Лёня не умеет в архитектуру. Даже не пытается. Сорян, архитектурой там и не пахнет.

Межпроцессное взаимодействие через дбас

для IPC давным давно создали множество средств. Г-ди, десктопные окружения могли бы использовать mmap и/или shmem. Но нет! Нужен «менеджер»! Куда же без него! Для упрощения работы можно было бы написать какую-нибудь либу, но никак не демон.

скорость загрузки

единственный плюс, как по мне

runit и openrc имеют теже плюсы... главный минус СД - он лишает свободы выбпра

Адепты потеринга такие смешные...

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

Тогда ты явно сайтиком ошибся.

Даже хейтеры systemd не смогли подорвать мою веру в людей :-)

cron для слабаков?

да

а что не так было с управлением сетью ранее?

оно было сделано не Поттерингом

дабы не тянуть относительно...

этих клиентов уже написано достаточно, одним больше, одним меньше...

зачем его генерировать?

Возможно для тебя сюрприз, но этот файл и до systemd кто только не генерировал

логгеров в мире написано предостаточно

а c бинарными логами один

вантуз не напоминает?

https://ru.wikipedia.org/wiki/Вантуз что именно ты имеешь в виду?

какой зоопарк, омг? все что нужно обычно было в комплекте современных ОС еще до systemd

В сухом остатке ничего не изменилось

Лёня не умеет в архитектуру.

Как хорошо, что у нас есть ты!

Даже не пытается.

Помедленнее пожалуйста, я записываю.

Сорян, архитектурой там и не пахнет.

Как и во всём юниксе и юникслайк. Так что всё нормально.

для IPC давным давно создали множество средств.

Откровения уровня КО

Г-ди, *десктопные* окружения могли бы использовать mmap и/или shmem.

Ты узнал новое слово на букву «д»?

Но нет! Нужен «менеджер»! Куда же без него! Для упрощения работы можно было бы написать какую-нибудь либу, но никак не демон.

Какая разница, как это назвать?
dbus был ещё задолго до systemd и в муках его рожали совсем другие люди, но этот факт не вписывается в пятиминутку ненависти.

PS:

единственный плюс, как по мне

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

На этот счёт есть старая мудрость: в семье не без урода.

А ты самокритичен. С другой стороны должны же и у тебя быть хоть какие-то положительные черты.

cron для слабаков?

Да, для слабаков. Таймеры systemd как минимум интегрируются в state machine. На кроне ты не сделаешь запуск юнита через час после того, как он последний раз остановился. А триггер по абсолютному времени туда прикрутили, потому что почему бы и нет.

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

Это ты так расписываешься в абсолютном незнании матчасти, да? timesyncd — это и есть отдельная программа, не связанная с systemd.

зачем его генерировать?

Видимо, всё-таки да. Давай ты изучишь, как работает любая другая управлялка сетью?

какой зоопарк, омг?

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

а что не так было с управлением сетью ранее?

См. выше. Легковесной универсальной управлялки сетью не было.

Лёня не умеет в архитектуру. Даже не пытается. Сорян, архитектурой там и не пахнет.

kek

для IPC давным давно создали множество средств. Г-ди, десктопные окружения могли бы использовать mmap и/или shmem. Но нет! Нужен «менеджер»! Куда же без него! Для упрощения работы можно было бы написать какую-нибудь либу, но никак не демон.

Какой к чёртовой матери mmap и/или shmem? Ты понимаешь, что значит «мультикаст»?

единственный плюс, как по мне

Это не плюс. На скорость загрузки десктопа всем вообще пофиг, это побочный эффект.

что за нездоровый национализм?

Очень даже здоровый. А почему ты спрашиваешь - ты антисемит?

тогда будет логичнее создать систему иницализации на lua

кто-то может объяснить - в чем плюс его вообще?

Кто-то может. Данное объяснение широко представлено в сети в виде текста (блоги, документация), подкастов и даже видео. Какие из этих форматов ты попробовал понять, и почему у тебя это не получилось?

а что исходники на systemd закрыты?

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

timesyncd — это и есть отдельная программа, не связанная с systemd.

Зачем ты опять лжешь?

https://github.com/systemd/systemd/blob/master/src/timesync/timesyncd.c

This file is part of systemd

#include "sd-daemon.h"
#include "sd-event.h"

static int load_clock_timestamp(uid_t uid, gid_t gid) {
        _cleanup_close_ int fd = -1;
        usec_t min = TIME_EPOCH * USEC_PER_SEC;
        usec_t ct;
        int r;
        fd = open("/var/lib/systemd/clock", O_RDWR|O_CLOEXEC, 0644);

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

Ах да, харкод путей - это офигительно, но эту тему трогать не будем.

Внедренный как @init он сжирает контроль над системой, по мере «обновления».

Земля. Роботы. Они заполоняяяя... Эк у тебя славно бахнуло - асбест подложи, а то диван прогорит :-D :-D :-D

Для меня вопрос актуален так как строю системы с нуля.

Да ты герой! Титан просто!!! Много настроил уже?

Когда его уже переименуют из системного менеджера в операционную систему?

А теперь системдэ-фаги, задача на пятерочку, пару часиков назад сидел:

1) Сервачок крашнулся;

2) Нужно сделать SQL дамп некоторых баз;

3) Рекавери работает. Диски подмонтировались. Маунты /dev, /proc тоже. chroot сработал на ура. Я в системе;

4) Какова хра я не могу запустить mysql ?

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

6) Специально проверил на старой убунте, chroot, запуск мускуля, логи - работают на отлично.

Понятно что проблема решена, mysqld_safe я еще запустить в состоянии. Понятно что можно было заscp'шить 34-гиговый ibdata1. Вопрос в том, почему это убожество не умеет в chroot.

После того как systemd-boot окончательно «уйдет» ненужный grub :)

Я спросил, в чём конкретно плюс, в частности чтобы понять, а стоит-ли знакомиться плотно с этой матчастью.

Лично тебе - точно не стоит. Чем меньше нелюбознательных обывателей с обострённым чсв и проблемами в пользовании поисковыми системами припрётся в линукс - тем лучше.

3) Скриптовая лапша в инитах заменена такой же лапшой юнитов.
Тут уж и вовсе вкусовщина. Но, любители скриптов могут вполне их использовать, а в юнитах оперировать этими скриптами.

Кстати, интересно. Что-то я в shell-тредах на лоре любителей свободы выбора инита не замечал. А помогают и объясняют, в основном, одни и те же люди, которые в тупом хейтерстве замечены не были.

ручной контроль над ними невозможен. Только автоматический

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

Это отправит систему в саспенд, а когда она из него выйдет - в гибернацию.

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