Недавно я заметил, что сервер выполняет apt-get update && apt-get dist-upgrade
Среди прочего, docker был обновлен и перезапущен.
Однако я заметил, что некоторые изменения, которые я внес в служебный файл ранее, исчезли. Файл в /lib/systemd/system/docker.service
, похоже, был сброшен.
Возможно ли это? Я не помню, запускал ли я daemon-reload
после этих изменений.
РЕДАКТИРОВАТЬ: Чтобы прояснить: мне интересно, dist-upgrade
в основном удалил служебный файл и заменил его файлом по умолчанию?
И выполняет ли daemon-reload
предотвратить это в будущем?
EDIT2: Хорошо, похоже, sudo systemctl edit docker.service
- это способ пойти и выполнить перезагрузку демона
при сохранении.
Не редактируйте файлы в / lib / systemd / или / usr / share / systemd, так как они будут перезаписаны при обновлении.
Вместо этого скопируйте файл в / etc / systemd / и внесите изменения там.
Каталог / etc / (по крайней мере, для systemd) считается местом для хранения локальных файлов конфигурации. Все остальные каталоги / ** / systemd / считаются источниками файлов конфигурации по умолчанию и образцами конфигурационных файлов, которые следует заменять при любом обновлении.
Еще одна причина не редактировать эти файлы конфигурации, поставляемые с пакетом, заключается в том, что если вы скопируете их в / etc / systemd / ..., отредактируете и сделаете ошибку, вы всегда сможете сравнить с исходным файлом.
systemctl daemon-reload
ничего не предотвращает. Он просто сообщает systemd повторно проверить всю свою конфигурацию и использовать все, что было изменено.
Есть некоторые недостатки хранения обычных файлов в / etc / systemd / system
не из-за самого systemd, а из-за того, что systemctl
находится в этом месте. Размещение обычных файлов в этом каталоге нарушит некоторые функции systemctl, в данном случае возможность маскировки вашего .service, и нет оснований полагать, что другие приложения будут обрабатывать это иначе. Теперь в systemd есть предопределенный набор путей поиска модулей , большинство из которых заняты дистрибутивом , это делает места, где вы можете разместить свой .service, в основном ограничены (или, по крайней мере, пока эта проблема не будет решена):
/usr/local/lib/systemd/system
Эта работа работает исключительно хорошо и без потери функциональности:
# cp -a hello-world.service /usr/local/lib/systemd/system
'hello-world.service' -> '/usr/local/lib/systemd/system/hello-world.service'
# systemctl daemon-reload
# dpkg -i hello-world_1.0-1_all.deb
Selecting previously unselected package hello-world.
(Reading database ... 396452 files and directories currently installed.)
Preparing to unpack hello-world_1.0-1_all.deb ...
Unpacking hello-world (1.0) ...
Setting up hello-world (1.0) ...
Created symlink /etc/systemd/system/multi-user.target.wants/hello-world.service → /usr/local/lib/systemd/system/hello-world.service.
# systemctl mask hello-world
Created symlink /etc/systemd/system/hello-world.service → /dev/null.
тот же хронологический порядок применяется и к вставкам, где / etc
имеют приоритет над / запустите
, которые, в свою очередь, имеют приоритет над / lib
... и так далее, выпадающие элементы с разными именами будут применяться в лексикографическом порядке независимо от местоположения. Если у вас есть перекрывающиеся директивы, то последняя будет иметь приоритет:
: systemctl cat hello-world
# /lib/systemd/system/hello-world.service
[Unit]
Description=Hello world (lib).
[Service]
Type=oneshot
ExecStart=/opt/bin/hello.sh lib
[Install]
WantedBy=multi-user.target
# /usr/local/lib/systemd/system/hello-world.service.d/10-local.conf
[Unit]
Description=Hello world (local).
[Service]
ExecStart=
ExecStart=/opt/bin/hello.sh local
# /etc/systemd/system/hello-world.service.d/override.conf
[Service]
ExecStart=
ExecStart=/opt/bin/hello.sh etc
: systemctl start hello-world
jun 28 15:20:24 betazoid systemd[1]: Starting Hello world (local)....
jun 28 15:20:24 betazoid hello[402381]: hello etc
jun 28 15:20:24 betazoid systemd[1]: hello-world.service: Succeeded.
jun 28 15:20:24 betazoid systemd[1]: Finished Hello world (local)..