Help! Настройка systemd в обновлённом с чего-то Ubuntu 22.04.5 LTS на ARM transmission

Спасибо, сработало.

Команда sudo systemctl edit transmission-daemon.service ВСЕГДА перезатирает ПОСЛЕ выхода из редактора первоначальным вариантом.

Кажется, я знаю в чём причина и виноват даже не systemd. Название редактора?

Хаха, я же олдскул сисадмин в свитере. Пробовал два - nano и mcedit.

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

Понадобилось ещё ExecStart переопределить, это вот всё в systemd - какой-то позор, конечно, уровня умолчаний при приведении типов в JS...

Если бы был сисадмином - использовал бы vim и разобрался с systemd даже без systemctl edit.

Я его в итоге тоже поставил - тот же эффект от systemctl edit, фича, видно, в этой версии systemd/ubuntu/архитектура сломана.

Без понятия что там в трансиссион накуралесили, именно в самом трансмиссион, но чтобы программа, запускаемая через systemd unit запускалась от указанного пользователя достаточно указать «User=», а все остальное это трансмиссион проблемы, а не systemd.

У него конфиг не редактируется штатной командой, причём тут программа? Очевидный баг ненужнод.

На самом деле, сам он вроде и ничего так, но размазанные конфиги по /usr, /etc и /home доставляют. Вообще, лучшие практики RH - всё свалить в кучу и потом раскидать в случайном порядке (в солярке и BSD такого не было!)

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

А так всё супер, на одном ядре отлично работают transmission и tor. Думаю локальный джаббер поднять для семьи и друзей.

[offtopic on]

Хаха, я же олдскул сисадмин в свитере. Пробовал два - nano и mcedit.

nano и mcedit, какой же это олдскул? Это почти ньюфаг :) vi ну максимум vim. И я почти не шучу, вспомнилось что со временем в дистрах vi стал vim-ом, вроде уже привыкаешь к этому и тут фигак! попадаешь на старый олдскульный vi, приходиться включать шестеренки воспоминаний на тему как же в нем работать. :)

systemctl edit вообще не особо удобный костыль, проще напрямую редактировать /etc/systemd/system/transmission-daemon.service.d/user.conf как и сказал костик в первом сообщении.
только потом знай что если тег списочный к примеру ExecStart, то измененное не заменяет, а добавляется в список.

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

Да ладно, mcedit не сильно младше vim. И в этом дистрибутиве почему-то был только nano, mc и vim я доустанавливал.

Это я уже заметил и IMHO это трэш по сравнению с переменными шелла.

Да ладно, mcedit не сильно младше vim.

Только в год его рождения занести ncurses было не так уж легко, а без него толку от mcedit было в разы меньше чем от vim.

И в этом дистрибутиве почему-то был только nano, mc и vim я доустанавливал.

«олдскул» и «доустанавливал» что-то странное слышится мне :) Но если серьезно, то я тоже в прошлом году доустанавливал vim в каком-то из посконных дистров.

Проблема в том, что systemctl edit под капотом выполняет команду:

$EDITOR +4 /etc/systemd/system/transmission-daemon.service.d/user.conf

Соответсвенно, есть риск того, что редактор поймёт +4 как ./+4, то есть как файл, а не адрес строки.

Но nano должен уметь в +4, значит проблема в другом.

Ну тут ТВ приставка с кем-то собранным образом для SD карты. И я его ещё и обновил...

Я никогда не использовал эту «штатную» команду и не понимаю зачем она нужна.

Всегда руками делал drop-in изменение конфигурации.

Ровно так, как указано в первом сообщении в теме.

А по поводу программы, если ты внимательно читал, что пишет автор: «Понадобилось ещё ExecStart переопределить».

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

Но ты этого не захотел понять, для тебя слово «systemd» и всё, мышление отключается.

Но автор не раскрыл, что он там правил. А так, для того, чтобы изменить пользователя от имени которого через систему инициализации запускается программа, указанная в ExecStart - достаточно задать / переопределить директиву «User=».

Что правил, что правил... Опцию с путями своими добавил. И да, там ментейнеры криворукие, всё заточено на init.d скрипт, и параметры настройки при запуске игнорируются - потому что systemd. Ещё раз спасибо, при непонятном в systemd буду кастовать :)

Уважаемый, вы сами написали, что в systemd ни бум-бум. Назвали себя якобы системным администратором, но прочитать как настраивается система инициализации, даже то, что по факту делается при systemctl edit unit.service, т.е. создание директории и помещение в неё изменений в файл, не удосужились.

Потом написали, что какие-то правки сделали, что читалось, что есть проблемы, а это просто ваши хотелки.

И сейчас когда вы пишете, что «потому что systemd», как бы и да, а как бы и нет, по факту это выглядит бледно, человек назвавшийся «системным администратором» не смог разобраться как сделать действия из 3-х команд:

mkdir /etc/systemd/system/transmission-daemon.service.d
echo "[Service]
User=myuser" > /etc/systemd/system/transmission-daemon.service.d/user.conf
systemctl daemon-reload

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

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

Зачем дескать изучать что-то новое, если лет двадцать до этого работало одно.

К примеру я nftables не использую, а пишу в синтаксисе iptables, пускай даже потом оно даже обрабатывается утилитами и в ядре имеет другое представление.

Но против nft я тоже в целом ничего не имею сказать плохого. Это лично мне удобнее использовать синтаксис iptables и лень глубоко разбираться в nft.

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

Разобраться - это systemctl edit. Кто ж знал, что это для отвода глаз и для обмана волосатых одминов-шпиёнов, А НА САМОМ ДЕЛЕ...

Не смогли, так не смогли, не хотите признавать, ну так не хотите.

Всегда есть несколько решения требуемой задачи.

Я спорить с вами не буду. То, что не сработало - да, нехорошо, но всегда есть документация, в которой можно прочитать как и что работает.

А в Linux / Unix в 95% случаев всё решается правкой текстовых конфигов или созданием некоторых файлов.

Даже к примеру когда вы делаете

systemctl enable unit.service

по факту создаётся символьная ссылка

/etc/systemd/system/multi-user.target.wants/unit.serice -> /etc/systemd/system/unit.service

или

/etc/systemd/system/multi-user.target.wants/unit.serice -> /lib/systemd/system/unit.service

В целом, было бы желание.

Удачи.

всё решается правкой текстовых конфигов

И тут вопрос:

• конфиг в /etc/defaults (кстати, если это defaults, есть где-то для custom? НАДО ПОЧИТАТЬ СОРЦЫ!)
• конфиг в /usr/lib/systemd
• конфиг или ссылка на /usr/lib в /etc/systemd
• .d директории в тех же местах

Да, избаловался я в своё время на *BSD и OpenWRT (uCI) конфигах. Но описанное буквально похоже на путь Сусанина либо спецификацию JS с оригинальными решениями. И с непривычки простые инструкции не помогут, создаётся впечатление, что надо читать спецификацию с сорцами. Только чтобы «вкатиться», начать. И это не потому, что софт сложный, это потому, что вот так вот сложилось.

Назвали себя якобы системным администратором, но прочитать как настраивается система инициализации, даже то, что по факту делается при systemctl edit unit.service, т.е. создание директории и помещение в неё изменений в файл, не удосужились.

Скажу несколько слов в защиту ТС. Когда ненужнод не твоя «основная» система инициализации и когда вопрос не связан с производственным процессом т.е. время терпит, то почему бы и не задать вопрос на ЛОРе? Вы посмотрите сколько откровенно ламерских вопросов люди задают в инете и в ответ им патчи бармина в панамку накидывают. А здесь имхо, с учетом кумарности ненужнод, вполне нормальный вопрос.

Понимаешь в чём суть, я не про то, что человек задал вопрос.

А про то, что уповает на то, что условно «Я не шмагла, но я админ и поэтому все проблемы из-за systemd».

И дальше все комментарии по факту: «Я не шмагла - systemd овно».

Так может вопросы к тебе?

Я понимаю, что человек расценивает, что если он использует функционал systemd, а именно systemct edit unit.service - он должен работать, но как показывает практика - это далеко не так.

Так автору и был дан чёткий и короткий ответ: Help! Настройка systemd в обновлённом с чего-то Ubuntu 22.04.5 LTS на ARM transmission (комментарий)

Без всяких отсылок, ах ты такой сякой не смог. В ответ было сообщение «спасибо».

Что делает автор дальше?

Он пишет:

Понадобилось ещё ExecStart переопределить, это вот всё в systemd - какой-то позор, конечно, уровня умолчаний при приведении типов в JS...

Если «системный администратор» не может прочитать документацию по продукту, то какой он системный администратор. И все отсылки, что я не разобрался, не хочу и поэтому продукт овно - пускай повесит себе в рамочку и читает.

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

Да, systemd не идеален и у меня самого к нему много вопросов. Но я не пишу, что я не смог разобраться - поэтому systemd овно.

Примите ответственность за себя, если «не шмагла» - ну так это ты не шмагла.

@firkax и иже с ним. Не используйте продукт, перепишите всё на BSD Style сценарии запуска, кто вам запрещает.

Только учтите, что к сожалению в новых версиях systemd поддержка запуска init сценариев вырезана.

Если сейчас ещё можно сделать systemctl start <init>, то когда современные дистрибутивы перейдут - уже нельзя будет.

Ещё /usr/share/systemd какие-то конфиги.

@firkax и иже с ним. Не используйте продукт, перепишите всё на BSD Style сценарии запуска, кто вам запрещает.

Я и не использую. На серверах freebsd, на основном десктопе devuan. На ноуте debian с этим, но если надо какой-то автозапуск - пишу или init-скрипты к нему или в rc.local вообще. Однако иногда либо приходится лазить по не мной настроенному железу и сталкиваться с этим непотребством, или на лоре кто-то пострадавший от него объявляется - как уж тут не высказаться.

Если сейчас ещё можно сделать systemctl start <init>, то когда современные дистрибутивы перейдут - уже нельзя будет.

Вообще плевать кто там куда перейдёт. Разве что случаи с чужим железом на котором оказался системг участятся немного.

Но описанное буквально похоже на путь Сусанина

Отличное сравнение! Я тоже как привыкший к SysV и другим BSD init, да и принципу KISS, смотрю на это дело с недоумением. Плачу, колюсь, жру, но принять моя душа этого до сих пор не может. Т.е. какбэ разобраться с этой хней с одной стороны не сложно, но с другой стороны взгляд на этот комбайн вызывает уныние.

Что поделать, либо использовать альтернативные версии дистрибутивов, либо всё как @firkax помещать в rc.local.

Можно, но условно неудобно и теряется гибкость.

Я так же плевался и искал обходные решение. Но systemd - стандарт системы инициализации в 95% дистрибутивов Linux.

Написать init сценарий запуска или unit service - плюс минус одно и тоже для меня сейчас.

В systemd есть вопросы работы с сетью для меня, к примеру pre-up и post-up сделать функционал можно и я даже где-то делал, но как сделано в /etc/netwoork/interfaces или допустим как в init cистемах инициализации - не получится.

Но решение найти можно.

И скажу более плюсы тоже есть, к тому же в Enterprise решениях самописные подходы не очень применимы. Хотя тоже приходится, если совсем уж никак.

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

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

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

Костенеть просто не нужно.

в новых версиях systemd поддержка запуска init сценариев вырезана

Так я и толкую, что в данном случае init сценарий НЕ запускается! А сам init сценарий обращается к юнитам.

При этом все параметры настраиваются (в смысле, по идее ментейнера) в файле параметров init скрипта, и это всё абсолютно deprecated. Меня расстроило, что это зоопарк, абсолютно криво сшитый и документ ированный плохо потому, что документация на разные стадии перехода с SysV на systemd.

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

размазанные конфиги по /usr, /etc и /home

Всё логично же. В /usr дефолт системы, в /etc конфиги админа, в /home — конфиги user-инстанса.

Edit: systemctl edit — костыль, но не беспрецедентный. visudo и crontab -e — звери той же породы.

Ээээ? crontab -e работает как часы десятки лет. А, ещё в BSD есть божественный vipw. В linux он бесполезен, в BSD он парсит что наредактировали и апдейтит сразу passwd, shadow и ещё бинарный BDB хеш этих файлов.

Что поделать, либо использовать альтернативные версии дистрибутивов

Это те которые с ненужнод альтернативные, а в старейший его не завезли.

либо всё как @firkax помещать в rc.local.

rc.local в ненужнод тоже не настоящий.

В systemd есть вопросы работы с сетью для меня, к примеру pre-up и post-up сделать функционал можно и я даже где-то делал, но как сделано в /etc/netwoork/interfaces или допустим как в init cистемах инициализации - не получится.

От! Золотые слова.

к тому же в Enterprise решениях самописные подходы не очень применимы

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

Ок, хорошо.

Edit: systemctl edit — костыль, но не беспрецедентный. visudo и crontab -e — звери той же породы.

Сравнили мух с котлетами.

Некоторые аргументы против такого подхода навскидку:

• Если админ согласен использовать visudo, то есть прилагать дополнительные усилия, то он будет согласен использовать sudolint /etc/sudoers. При этом такой подход был бы прозрачнее. Понятный пример учит пользователя, а “visudo” — это просто заклинание.

• visudo создаёт ложное впечатление, будто система как бы защищает от дурака. Но это не сработает при редактировании других, не менее важных конфигов.

• Прозрачность и однородность системы — это тоже свойства безопасности.

• Проблема асинхронной записи решается на уровне текстовых редакторов для всех файлов, а не ≈5 специальных конфигов.

• Полагаться на inotify — та же ошибка, что и ожидать, что $EDITOR понимает +4 — неоправданно широкое предположение о среде. Надёжнее ручной reload, как в nginx.

Первый раз про эту штуку слышу. Оказывается и vi и mcedit такое поддерживают. Но надеяться что такое поддерживает произвольный редактор - очень странно.

После установки нормальных редакторов nano надо было purge ещё.

Согласен, что это странно. Но, кажется, это уже некое соглашение. gdb тоже так делает, но по крайне мере в ограниченном контексте: 1.

Если админ согласен использовать visudo, то есть прилагать дополнительные усилия, то он будет согласен использовать sudolint /etc/sudoers.

Как ты видишь использование этого гипотетического sudolint?

Копировать /etc/sudoers во временный файл, редактировать его, запускать на него sudolint, и, если все хорошо, копировать его обратно в /etc/sudoers?

Это слишком много дополнительных действий по сравнению с visudo.

visudo создаёт ложное впечатление, будто система как бы защищает от дурака.

Это только у дураков создается «ложное впечатление».

Но это не сработает при редактировании других, не менее важных конфигов.

А особенно что-то в духе /usr/src/linux/.config
Ну не натягивайте сову на глобус. Мухи отдельно, котлеты отдельно.

OK, признаю, что конкретно /etc/sudoers — особый случай.

Но вообще, если есть возможность открыть два окна, то visudo уже не нужен. Можно редактировать sudoers в одном окне, сохранить изменения и, не закрывая редактор, в другом окне выполнить sudolint. Но да, на некоторых минимальных системах даже редактора нет, не говоря об окнах.

Это только у дураков создается «ложное впечатление».

Никогда не знаешь, когда окажешься дураком. Или твой коллега.

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

в обилии путей конфигов systemd имеется свой смысл. его только надо понять :) и привыкнуть к логике service.d

в обилии путей конфигов

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

Вот же ты мазохист.

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

/usr/lib/systemd - дефолтные service, идущие с пакетом программы. их редактировать нельзя ибо они при обновлении заменяются и все редактирования улетают в пустоту.

/etc/systemd - локальные service, пакет установки не может иметь service по этому пути.
можно скопировать дефолтный в /etc/systemd и отредактировать. это будет пользовательский service и он полностью заменяет service из /usr/lib/systemd, как бы он там не заменялся при обновлении пакета.

через service.d в /etc/systemd можно исправить отдельные параметры service из /usr/lib/systemd и эти изменения локальные и не сотрутся при обновлении пакета.
удобно и логично.

обнуление идет из того что тего ExecStart списочный т.е. в service таковых может быть несколько, а не один как тег User.
они полноценны и просто выполняются последовательно.
у меня в одном сервисе четыре ExecStart: в первом качается deb-пакет с тырнета, во втором устанавливается черз dpkg -i, в третьем доустанавливаются зависмости, в четвертом пакет уадляется.
и вот как этот список изменять ?? :)
применили решение в виде удаления списка через пустой «ExecStart=» и прописывания с нуля нового списка ExecStart.
вполне логично.

работает и очень эффективно работает.
без мудрений с visudo и прочими костылями.