SystemD намертво приклеился к сокету

systemd управляет демонами отдельно от сокетов. Для сокетов есть собственные юниты, которые нужно отключать после отключения демона, использующего этот сокет. То есть в твоём случае:

# systemctl stop mpd.service && systemctl stop mpd.socket
# systemctl disable mpd.service && systemctl disable mpd.socket

// Пользователь FreeBSD помогает с systemd.

// Пользователь FreeBSD помогает с systemd.

Спасибо, конечно, но в выводе вверху я глушу сокет. Вообще и mpd.service и mpd.socket отключены ещё со времён установки systemd.

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

Даже можно наверное шире вопрос поставить: можно ли запретить в systemd функциональность сокетов вообще?
А то, к примеру, завтра это поделие решит начать слушать ещё что-то, и вместо mpd отломает более критичный сервис.

#systemctl mask mpd.socket && systemctl stop mpd.socket

COMMAND PID
systemd 2884

Тебя не смущает, что PID != 1?

Скорее всего сокет слушает пользовательский systemd. Посмотри, чей он (systemctl status 2884), и уже от имени этого пользователя systemctl --user status mpd.socket.

но в выводе вверху я глушу сокет

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

Вообще и mpd.service и mpd.socket отключены ещё со времён установки systemd.

Про маскировку выше написали.

Меня много чего в systemd смущает.

root@optiplex:/home/aidaho# systemctl status 2884
● user@0.service - User Manager for UID 0
   Loaded: loaded (/lib/systemd/system/user@.service; static; vendor preset: enabled)
   Active: active (running) since Sat 2020-01-25 21:28:33 EET; 13h ago
     Docs: man:user@.service(5)
 Main PID: 2884 (systemd)
   Status: "Startup finished in 1min 30.282s."
   Memory: 1.9M
   CGroup: /user.slice/user-0.slice/user@0.service
           └─init.scope
             ├─2884 /lib/systemd/systemd --user
             └─2885 (sd-pam)

Jan 25 22:13:30 optiplex systemd[2884]: Failed to start Music Player Daemon.
Jan 25 22:20:18 optiplex systemd[2884]: Failed to create compat systemd cgroup /user.slice/user-0.slice/user@0.service/mpd.service: Read-only file system
Jan 25 22:20:18 optiplex systemd[2884]: Failed to attach 20764 to compat systemd cgroup /user.slice/user-0.slice/user@0.service/mpd.service: No such file or directory
Jan 25 22:20:18 optiplex systemd[2884]: Starting Music Player Daemon...
Jan 25 22:20:18 optiplex systemd[20764]: Failed to attach 20764 to compat systemd cgroup /user.slice/user-0.slice/user@0.service/mpd.service: No such file or directory
Jan 25 22:20:18 optiplex mpd[20764]: config_file: config parameter "id3v1_encoding" on line 391 is deprecated
Jan 25 22:20:18 optiplex mpd[20764]: Jan 25 22:20 : exception: Input plugin 'tidal' is unavailable: No Tidal application token configured
Jan 25 22:20:18 optiplex mpd[20764]: Jan 25 22:20 : exception: Input plugin 'qobuz' is unavailable: No Qobuz app_id configured
Jan 25 22:20:57 optiplex systemd[2884]: mpd.service: Failed with result 'protocol'.
Jan 25 22:20:57 optiplex systemd[2884]: Failed to start Music Player Daemon.

Кто такой user-0 не знаю, не знаком. Но догадываюсь.

aidaho@optiplex:~$ systemctl --user status mpd.socket
● mpd.socket
   Loaded: loaded (/usr/lib/systemd/user/mpd.socket; enabled; vendor preset: enabled)
   Active: failed (Result: resources)
   Listen: /run/user/1000/mpd/socket (Stream)
           [::]:6600 (Stream)
aidaho@optiplex:~$ systemctl --user disable mpd.socket
aidaho@optiplex:~$ systemctl --user stop mpd.socket
aidaho@optiplex:~$ systemctl --user mask mpd.socket
Created symlink /home/aidaho/.config/systemd/user/mpd.socket → /dev/null.
aidaho@optiplex:~$ systemctl --user disable mpd.service
aidaho@optiplex:~$ systemctl --user stop mpd.service
aidaho@optiplex:~$ systemctl --user mask mpd.service
Created symlink /home/aidaho/.config/systemd/user/mpd.service → /dev/null.

Однако, всё по прежнему:

root@optiplex:/home/aidaho# lsof -i tcp:6600
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd 2884 root   31u  IPv6  32705      0t0  TCP *:6600 (LISTEN)

Замаскировал и сервис и сокет. Бестолку.

Про маскировку выше написали.

Это уже начинает напоминать ритуалы вуду.
Если status подтверждает, что disabled, я таки ожидаю что это достоверная информация.
И когда командую stop, то считаю этого должно хватать, чтобы остановить сервис/сокет.

Меня вообще xinetd функциональность systemd не колышет. Он взялся решать проблемы, которых у меня не было.

Только смерть их разлучит.

Кто такой user-0 не знаю, не знаком.

Это как бы рут.

aidaho@optiplex:~$ systemctl –user status mpd.socket

А надо было от рута.

Но вообще с какого фига у тебя рутовый юзерский systemd (1) вообще запущен и (2) что-то делает? Пинай мейнтейнеров своих, какого чёрта они положили mpd.socket в global и по дефолту его включили.

Зачем тебе на десктопе системда? Поставь уже openrc, sysvinit или что там еще.

Если status подтверждает, что disabled, я таки ожидаю что это достоверная информация.

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

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

Как такое возможно?

Меня вообще xinetd функциональность systemd не колышет. Он взялся решать проблемы, которых у меня не было.

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

Во-вторых, «если мне что-то не нужно, то никому тоже не нужно». Ну да.

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

systemd --user

А надо было от рута.

root@optiplex:/home/aidaho# systemctl --user status mpd.socket
Failed to connect to bus: Operation not permitted

Зачем тебе на десктопе системда? Поставь уже openrc, sysvinit или что там еще.

Мне не надо, но в debian сейчас уже сложно иметь десктоп систему без systemd.
Много пакетов имеют жёсткую от него зависимость.

До этого сидел на sysvinit, пока была возможность.

я таки ожидаю что это достоверная информация

systemd

Когда они когда-то накосячили с монтированием efivar в rw, тебя это не насторожило? ☺

Да, (ре)стартовать systemd умеет отлично, но вот вовремя останавливаться, кажется, не собирается.

Либо по-настоящему зайди в систему от рута, либо machinectl shell попробуй, либо export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/0/bus. sudo и su не создают сессию.

А вообще знаешь что? systemctl --global disable mpd.socket mpd.service. Если я правильно предполагаю, где накосячили дебиановцы, это должно помочь.

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

арч, УМВР

$ systemctl --user stop mpd.service mpd.socket
$ lsof -i tcp:6600
$ echo $?
1

А зачем нам два systemd?

Я написал что нужно сделать в пятом сообщении треда, просто ТС уже второй день тупит и ноет на systemd.

Вам — не знаю. Нам — затем, чтобы вторым мог рулить пользователь.

Так это ж дебьяновцы. Этим криворучкам да, лучше держаться от systemd подальше и поставить OpenRC.

строго говоря, ТС допустил две ошибки. Первая - он пытался останавливать mpd из системной (или как она там называется) сессии systemd, хотя он был запущен в пользовательской. Вторая - он останавливал mpd.socket, забыв про mpd.service. Ты написал про первую ошибку, но не про вторую). Юзер из первого поста - наоборот, про вторую, но не про первую.

Действительно сработало вот это

systemctl --global disable mpd.socket mpd.service
systemctl --global stop mpd.socket mpd.service

И только из рут-консоли, экспорт рутового DBUS_SESSION_BUS_ADDRESS не помогает.

Спасибо.

Вторая - он останавливал mpd.socket, забыв про mpd.service

mpd.service у него неактивен. Если бы он был активен, сокет слушал бы не PID 2884 (systemd), а mpd.

строго говоря, ТС допустил две ошибки. Первая - он пытался останавливать mpd из системной (или как она там называется) сессии systemd, хотя он был запущен в пользовательской. Вторая - он останавливал mpd.socket, забыв про mpd.service.

С моей точки зрения события развивались примерно так: после установки Debian 10 + systemd, mpd.service и mpd.socket были отключены, и всё рабтало как положено.
В какой-то из апдейтов systemd начал запускаться в пользовательской сессии (нафига?), я и о возможности то такой был не в курсе.

Но все продолжало быть хорошо, т.к. я не фанат перезагрузок.
В конце-концов когда потребовался ребут, получилось то, что получилось.

mpd.service и mpd.socket были отключены, и всё рабтало как положено.

Если бы они были отключены, то этого топика бы не было. Они были включены в глобальной пользовательской конфигурации, и когда в какой-то момент твоя система решила запускать user@0.service, именно этот экземпляр systemd стал выигрывать гонку за сокет.

Кстати, а до этой проблемы тебя не смущало, что systemd слушает сокет mpd?

Но все продолжало быть хорошо, т.к. я не фанат перезагрузок.

А как ты, пардон, ядро обновляешь?

Если бы они были отключены, то этого топика бы не было. Они были включены в глобальной пользовательской конфигурации

Я уже понял, что верить выводу systemctl enable/disable/stop без --global просто нельзя. Но всё равно спасибо за напоминание. Добавлю в копилку причин, почему я ссу обновить на Debian 10 систему доступную только через tinc vpn.
Одна неучтённая деталь, и можно собирать чемоданы на внеплановый вояж.

Кстати, а до этой проблемы тебя не смущало, что systemd слушает сокет mpd?

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

P.S. кстати, кто придумал объединять два дефиса в посте в тире? Драма уже была, или я всё пропустил?

А как ты, пардон, ядро обновляешь?

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

Я уже понял, что верить выводу systemctl enable/disable/stop без –global просто нельзя.

Кажется, ты приписываешь --global то, чем он не является. systemctl --global — это не надмножество обычного systemctl, если что. Это глобальная конфигурация пользовательских systemd.

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

А, то есть ты всё это время запускал mpd не через свой systemd --user, а как-то ещё?

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

Кажется, ты приписываешь –global то, чем он не является. systemctl –global — это не надмножество обычного systemctl, если что. Это глобальная конфигурация пользовательских systemd.

В «реальности данной мне в ощущениях», оказалось, что нельзя чувствовать себя в безопасности, опираясь только на вывод systemctl.
Ты фокусируешься в данной ситуации на том «кто виноват», я же на том, что она вообще имела место быть.

А, то есть ты всё это время запускал mpd не через свой systemd –user, а как-то ещё?

Да, он стартует из .profile при первом логине.