Comments 5
В случае с Centos7 это говорит о том, что нужно создавать новый сервисный файл для systemd
а что, в седьмой центоси не было systemctl edit ... ?? насколько я помню было..
Да было конечно. Можно и так сделать, но на мой взгяд, в данном случае удобней сделать отдельный сервис, т.к. изменение в запуске существенные.
если говорить про удобства тогда можно и в ansible реализовать то же самое НО без интерактива как в случае с systemctl edit и без ручного вмешательства в сервисфайлы
- name: Create SERVICENAME.service.d directory
file:
path: /etc/systemd/system/SERVICENAME.service.d/
state: directory
owner: root
group: root
mode: 0755
- name: Copy SERVICENAME.service drop-in
template:
src: SERVICENAME.service.j2
dest: /etc/systemd/system/SERVICENAME.service.d/override.conf
owner: root
group: root
mode: 0644
notify: daemon-reloadили сделать то же самое создав директорию и положив туда файл bash скриптом или чем угодно другим, и это всё ещё будет более правильно чем ручное переписывание сервисфайла
ну а если уж вы стоите на своём что лучше сделать отдельный сервисфайл то хотя бы добавьте systemctl mask СТАРЫЙСЕРВИС чтобы сделать хоть какую-то защиту от дурака
Это все очень хорошо, ansible и т.п., но в данном конкретном случае имеется: один админ, один сервер, один контейнер на сервере. А вот про systemctl mask спасибо что напомнили, все время упускаю этот момент, а ведь в данном случае это необходимо сделать (как вы правильно сказали - защита от дурака).
ansible и т.п., но в данном конкретном случае имеется: один админ, один сервер, один контейнер на сервере
согласен что с ansible я перегнул (хотя он тут полезен хотя бы в качестве документации и исторической справки что и как было сделано)
ну а про mask напомнил потому что однажды обжёгся на этом сам, рад что был полезен
Systemd-nspawn (docker), mysqld --memlock