Как стать автором
Обновить

Комментарии 10

А подскажите, как запретить запуск сервиса, который триггерится по событию?
Вот тот же (всеми любимый) avahi?
systemctl disable avahi-daemon.service


не работает?
datacompboy@nuuzerpogodible:~$ sudo systemctl disable avahi-daemon
Synchronizing state for avahi-daemon.service with sysvinit using update-rc.d…
Executing /usr/sbin/update-rc.d avahi-daemon defaults
Executing /usr/sbin/update-rc.d avahi-daemon disable
insserv: warning: current start runlevel(s) (empty) of script `avahi-daemon' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `avahi-daemon' overrides LSB defaults (0 1 6).
insserv: warning: current start runlevel(s) (empty) of script `avahi-daemon' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `avahi-daemon' overrides LSB defaults (0 1 6).
Removed symlink /etc/systemd/system/dbus-org.freedesktop.Avahi.service.
Removed symlink /etc/systemd/system/sockets.target.wants/avahi-daemon.socket.
datacompboy@nuuzerpogodible:~$ sudo ps -fax | grep avahi
32162? Ss 0:00 avahi-daemon: running [nuuzerpogodible.river-net]
32163? S 0:00 \_ avahi-daemon: chroot helper
32450 pts/0 S+ 0:00 \_ grep avahi
datacompboy@nuuzerpogodible:~$ sudo systemctl stop avahi-daemon
Warning: Stopping avahi-daemon.service, but it can still be activated by:
avahi-daemon.socket
systemctl mask name.service?
вот mask сработало на ура.
service nginx restart vs systemctrl restart nginx.service. Не нравится мне это. Команда длиннее, результат тот же. Пока работает и старая версия, но никто же не даст гарантии, что так будет всегда. Да и shell-скрипты, которые на рестарт сервисов завязаны, в перспективе перестанут работать.
Можно просто systemctl restart nginx. А вообще, я у себя сделал:
alias 'stop'='sudo systemctl stop'
alias 'start'='sudo systemctl start'
alias 'restart'='sudo systemctl restart'
alias 'status'='sudo systemctl status'

Стало гораздо удобней.
Вам просто нужно время привыкнуть. Я также как и Вы изначально очень негативно воспринял переход на systemd, из-за того что всё привычное поменялось. Но на самом деле использование systemctl гораздо удобнее хотя бы потому, что позволяет точно контролировать состояние запущенных/включенных сервисов (is-enable/is-active).

Или, например, взгляните на systemctl status. Если вы поправили конфиг в процессе тестирования, теперь Вам больше не нужно лезть в логи для просмотра последних строк вывода — все будет в выводе systemctl. Экономит уйму времени. Если Вам часто приходится писать системные сценарии — Вы оцените его, поверьте.
Пару дней назад перевели часть серверов на Centos 7.0
Один из самописных сервисов на старом init-скрипте номально не стартовал по причине того, что systemd не мог найти pid-файл и висел ожидая когда он появится. Искал pid-файл он совсем не там, где он на самом деле был.
Оказалось, что кривой путь был где-то в комментарии скрипта, который systemd зачем-то еще и запомнил.
Т.е. после правки нужно еще запускать systemctl daemon-reload.
А тем временем, народ наконец то начал пилить альтернативы и заглушки для поделок Потерринга. Недавно apulse появился как замена PulseAudio (к которому у меня куча претензий), в стане gentoo реализовали systemd сервисы для Gnome авторизации (полноценные dbus службы), ну и eudev теперь вместо udev.
Так что крайне надеюсь у systemd будут достойные замены.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.