Systemd is a bad idea, in my humble opinion.
Systemd is well designed and implemented, but the costs exceed the benefits.
By its very nature, systemd must be opaque and hugely complicated.
One can not be sure of its functionality unless he reads the code.
Please help me understand three instances of systemctl behavior.
The third instance, especially, poses a serious problem to me using systemd.
1. man systemd.unit, MAPPING OF UNIT PROPERTIES TO THEIR INVERSES, says:
Quote:
|
Unit settings that create a relationship with a second unit usually show up in properties of both units, for example in systemctl show output.
|
Yet:
Code:
me@host:~$ systemctl show bluetooth.{target,service} --property=WantedBy,Wants # no WantedBy for bluetooth.service
Wants=bluetooth.service
WantedBy=
Wants=
WantedBy=
me@host:~$ systemctl cat bluetooth.{target,service} | grep Want # explicit WantedBy in bluetooth.service
WantedBy=bluetooth.target
2. man systemctl, Unit Commands, list-dependencies [UNIT...], says:
Quote:
|
Note that this command only lists units currently loaded into memory by the service manager. In particular, this command is not suitable to get a comprehensive list at all reverse dependencies on a specific unit, as it won't list the dependencies declared by units currently not loaded.
|
Yet:
Code:
me@host:~$ systemctl list-units bluetooth.{target,service} --all # units not loaded
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
me@host:~$ systemctl list-dependencies bluetooth.target # shows dependency
bluetooth.target
● └─bluetooth.service
me@host:~$ systemctl list-dependencies bluetooth.service --reverse --all # does not show dependency
bluetooth.service
The erratic behaviour exhibited in points 1 and 2 is bad enough, but now comes point 3.
3. man systemd, CONCEPTS, says:
Quote:
|
Then, it will verify if the transaction is consistent (i.e. whether the ordering of all units is cycle-free).
|
I understand that unit files dependencies may be ill-defined, there may be cycles, but still, systemctl could have displayed a dependencies tree with a limited number of levels.
There is no way to investigate unit files dependencies other than to systemctl cat unit by unit.
How is this acceptable?
Systemctl Features
