Запускается disabled сервис

Сокет-активация, нет?

disabled == «нет в default.target» (см. вывод systemctl disable). если этот сервис от кого-то зависит, он будет запущен.

если нужно не запускать ни при каких условиях, используйте systemctl mask

Без понятия. Но с чего бы сокету активировать disabled сервис?

именно, у cups есть cups.socket

если кто-то зависит от этого сервиса

FTFY

disabled значит, что сервис не запускается автоматически при загрузке системы. Но он может быть активирован по сокету.

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

если нужно не запускать ни при каких условиях, используйте systemctl mask

Судя по «Created symlink from /etc/systemd/system/cups.service to /dev/null.», я вообще не смогу запустить теперь этот сервис?

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

спсб

да

Мде. Охренеть как удобно.

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

Интуитивно.

Систумд же. Удобен и универсален. Просто имеет ряд ограничений на никому не нужных вещах вроде кастомных старт-скриптов или отключения сервисов.

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

Хотя да, это не так прозрачно.

КМК, лучше так, чем разбираться, почему не запустился сервис

лучше плюнуть сообщение что мол «сорян, нужен еще вот этот сервис, который отключен». Или состояние no-auto-start. Вязать на /dev/null это треш и угар

Мде. Охренеть как удобно.

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

ᐅ systemctl stop org.cups.cupsd.service
Warning: Stopping org.cups.cupsd.service, but it can still be activated by:
  org.cups.cupsd.socket

хочешь чтоб не запускался дисабли socket

хочешь чтоб не запускался дисабли socket

Я его дизаблю. А потом, при старте cups, он всё равно запускается. Очень, #%%^&*, удобно.

Тебе уже сказали про mask.

       mask NAME...
           Mask one or more unit files, as specified on the command line. This will link these units to /dev/null, making it
           impossible to start them. This is a stronger version of disable, since it prohibits all kinds of activation of the
           unit, including enablement and manual activation. Use this option with care. This honors the --runtime option to only
           mask temporarily until the next reboot of the system. The --now option can be used to ensure that the units are also
           stopped.

file a bug

file a bug

на ДНК поцеринга

Я его дизаблю. А потом, при старте cups, он всё равно запускается. Очень, #%%^&*, удобно.

мне кажется ты пиз#%шь, cups.socket не зависит от cups.service и не будет запускаться при старте сервиса. disable/mask cups.socket, и когда нужно вручную запускаешь cups.service.

мне кажется ты пиз#%шь

Не волнуйся так.

Не волнуйся так.

это было сказано мной, абсолютно спокойно.

это было сказано мной, абсолютно спокойно.

Вот и славно.

Во-первых: сервис может запускать сокет, который зависит от сервиса
Во-вторых: другой зависимый юнит или таргет запускает сервис

при запуске cups.service ничего не будет происходить, так как он теперь ссылается на /dev/null
И сколько бы cups.socket не бился, ничего у него теперь не выйдет

...даже когда таргет disabled. Это уже объяснили выше, про mask - тоже.

Имеется в виду, что временно systemctl start ты сделать не сможешь. Будет надо - удаляешь симлинк в /etc/systemd/{system,user,multiuser.target.wants}/servicename.service и снова делаешь systemctl enable. (Не исключено, что это все костыль и можно сделать systemctl unmask, но я не в курсе)

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

коверкание имени неугодных не делает вас более (или менее) правым. К.О.

Enable/disable надо рассматривать в контексте автозапуска при загрузке. И тогда всё будет достаточно интуитивно. А если ты отключил автозапуск при загрузке, это не значит, что его нельзя будет поднять при необходимости (да хоть вручную).

И раньше, со всякими upstart и init, это тоже было так. Просто там не было модели зависимостей и активации по сокету.

Но ведь поныть, что «Лёня сломал мне шаблоны, и запускает мне сервис, когда я его дисейблнул!» - обязательно надо, да... Тем временем в man systemctl:

Enabling units should not be confused with starting (activating) units, as done by the start command.
Enabling and starting units is orthogonal: units may be enabled without being started and started without being enabled. Enabling simply hooks the unit into various suggested places (for example, so that the unit is automatically started on boot or when a particular kind of hardware is plugged in). Starting actually spawns the daemon process (in case of service units), or binds the socket (in case of socket units), and so on.

Enable/disable надо рассматривать в контексте автозапуска при загрузке. И тогда всё будет достаточно интуитивно.

Выбрать слова «enable» и «disable» для значения «autostart on/off». Шалтай-Болтай наносит ответный удар.

Тем временем в man systemct

Поныть «ты нипрачитал man»- это обязательно, да. Тем временем, вопрос был «почему systemd запускает отключенные службы», а не «почему я отключаю службу, а она не останавливается».