Zanim wszystkie pliki jednostek były w, /etc/systemd/system/
ale teraz niektóre pojawiają się w /usr/lib/systemd/system
(<- na CentOS lub /lib/systemd/system
<- na Debian / Ubuntu), jaka jest różnica między tymi folderami?
Odpowiedź na to pytanie jest już dostępna w man 7 file-hierarchy
systemied (dostępna jest również wersja online ):
/etc
System-specific configuration.
(…)
VENDOR-SUPPLIED OPERATING SYSTEM RESOURCES
/usr
Vendor-supplied operating system resources.
Usually read-only, but this is not required. Possibly
shared between multiple hosts. This directory should not
be modified by the administrator, except when installing
or removing vendor-supplied packages.
Zasadniczo pliki dostarczane w paczkach pobranych z repozytorium dystrybucyjnego trafiają do /usr/lib/systemd/
. Modyfikacje wprowadzone przez administratora systemu (użytkownika) wchodzą /etc/systemd/system/
.
Jednostki specyficzne dla systemu zastępują jednostki dostarczane przez dostawców. Używając drop-ins, możesz przesłonić tylko określone części plików jednostkowych, pozostawiając resztę dostawcy (drop-ins są dostępne od samego początku systemd, ale zostały odpowiednio udokumentowane tylko w v219; patrz man systemd.unit
).
Jeśli spojrzysz na stronę podręcznika man systemd.unit
, ma ona tabelę wyjaśniającą różnice. Pochodzi z systemu CentOS 7.x.
UNIT LOAD PATH Unit files are loaded from a set of paths determined during compilation, described in the two tables below. Unit files found in directories listed earlier override files with the same name in directories lower in the list. Table 1. Load path when running in system mode (--system). ┌────────────────────────┬─────────────────────────────┐ │Path │ Description │ ├────────────────────────┼─────────────────────────────┤ │/etc/systemd/system │ Local configuration │ ├────────────────────────┼─────────────────────────────┤ │/run/systemd/system │ Runtime units │ ├────────────────────────┼─────────────────────────────┤ │/usr/lib/systemd/system │ Units of installed packages │ └────────────────────────┴─────────────────────────────┘
Kiedy mówią „zainstalowane pakiety”, odnoszą się do wszystkiego, co zostało zainstalowane przez RPM. To samo można założyć dla Debian / Ubuntu, gdzie plik DEB byłby „zainstalowanym pakietem”.
UWAGA: powyższa tabela z systemu Debian / Ubuntu jest nieco inna.
Table 1. Load path when running in system mode (--system). ┌────────────────────┬─────────────────────────────┐ │Path │ Description │ ├────────────────────┼─────────────────────────────┤ │/etc/systemd/system │ Local configuration │ ├────────────────────┼─────────────────────────────┤ │/run/systemd/system │ Runtime units │ ├────────────────────┼─────────────────────────────┤ │/lib/systemd/system │ Units of installed packages │ └────────────────────┴─────────────────────────────┘
/usr/lib/systemd/system
Możesz powiedzieć, w których pakietach znajdują się /usr/lib/systemd/system
takie pliki jednostek w systemie CentOS / Fedora / RHEL:
$ rpm -qf /usr/lib/systemd/system/* |sort -u | head
abrt-2.1.11-50.el7.centos.x86_64
abrt-addon-ccpp-2.1.11-50.el7.centos.x86_64
abrt-addon-kerneloops-2.1.11-50.el7.centos.x86_64
abrt-addon-pstoreoops-2.1.11-50.el7.centos.x86_64
abrt-addon-vmcore-2.1.11-50.el7.centos.x86_64
abrt-addon-xorg-2.1.11-50.el7.centos.x86_64
accountsservice-0.6.45-7.el7.x86_64
acpid-2.0.19-8.el7.x86_64
alsa-utils-1.1.3-2.el7.x86_64
anaconda-core-21.48.22.134-1.el7.centos.x86_64
/etc/systemd/system
Jeśli zrobimy to samo przeciwko /etc/systemd/system
, spodziewalibyśmy się, że nie znajdziemy żadnych plików należących do RPM (co w rzeczywistości ma miejsce w moim systemie CentOS 7.x.):
$ rpm -qf /etc/systemd/system/* /etc/systemd/system/*/* | grep -v 'not owned'
$
Pamiętaj, że czasami możesz znaleźć przypadkowe zbłąkane pliki /usr/lib/systemd/system
, takie jak Virtualbox (vboxadd *):
$ rpm -qf /usr/lib/systemd/system/* |sort -u | grep 'not owned'
file /usr/lib/systemd/system/initrd.target.wants is not owned by any package
file /usr/lib/systemd/system/shutdown.target.wants is not owned by any package
file /usr/lib/systemd/system/vboxadd.service is not owned by any package
file /usr/lib/systemd/system/vboxadd-service.service is not owned by any package
file /usr/lib/systemd/system/vboxadd-x11.service is not owned by any package
Są inni.
/usr/lib/systemd/system
Oczekuje się, że jest to katalog, który powinien zawierać tylko pliki jednostek systemowych, które zostały tam umieszczone przez menedżera pakietów (YUM / DNF / RPM / APT / etc).
Pliki w tym miejscu /etc/systemd/system
są ręcznie umieszczane przez operatora systemu na potrzeby instalacji oprogramowania ad-hoc, które nie są w formie pakietu. Obejmuje to instalacje oprogramowania typu tarball lub własne skrypty.
/lib/systemd/system
kontra/usr/lib/systemd/system
. Cieszę się, że znalazłem tę odpowiedź./etc/systemd/system
generuje błąd, jeśli maskować go:Failed to execute operation: Invalid argument
; systemd próbuje zastąpić plik dowiązaniem symbolicznym do / dev / null. Nie powiedzenie tej odpowiedzi jest niepoprawne, po prostu coś do zapamiętania./lib/systemd/system
i/usr/lib/systemd/system
dlatego zadałem to pytanie osobno unix.stackexchange.com/questions/550001/…