1 |
Am Fri, 15 Dec 2017 07:38:01 +0100 schrieb J. Roeleveld: |
2 |
|
3 |
> On Friday, December 15, 2017 4:05:41 AM CET Kai Krakow wrote: |
4 |
>> Am Thu, 14 Dec 2017 08:54:59 +0100 schrieb J. Roeleveld: |
5 |
>> >> Some historical correctnesses about Canek: |
6 |
>> >> |
7 |
>> >> - He has been here for years - He has contributed here for years - |
8 |
>> >> He supports systemd and has offered more help and explanation about |
9 |
>> >> systemd to it's users on this list than any other single person, bar |
10 |
>> >> none - He has never, not once, slagged off SysV Init, OpenRC or any |
11 |
>> >> other init system, ot the creators or the users - He has never |
12 |
>> >> posted rude or inflamatory comments about anyone arguing against him |
13 |
>> >> - He has never resorted to ad-hominem and never posted any knee jerk |
14 |
>> >> opinions about any other poster wrt their stance on init systems |
15 |
>> > |
16 |
>> > +1 I may not agree with Canek on all things: |
17 |
>> > - I do dislike systemd, especially on Centos where disabling services |
18 |
>> > doesn't always work past a reboot |
19 |
>> |
20 |
>> Well, I think you're falling the pitfall expecting "disable" makes a |
21 |
>> unit unstartable. That is not the case. Disabling a unit only removes |
22 |
>> it from the list of units starting on your own intent. It can still be |
23 |
>> pulled it as a (required) dependency. |
24 |
> |
25 |
> Makes sense |
26 |
> |
27 |
>> If you really want it never being started, you need to mask the unit. |
28 |
>> It's then no longer visible to the dependency resolver as if it were |
29 |
>> not installed at all. |
30 |
> |
31 |
> This is not listed anywhere easy to find in google. |
32 |
> |
33 |
>> The verbs disable and enable are arguably a bit misleading, while the |
34 |
>> verbs mask and unmask are not really obvious. But if you think of it, |
35 |
>> it actually makes sense. |
36 |
> |
37 |
> Actually, it doesn't. But lets not discuss naming conventions. A lot of |
38 |
> tools have ones where I fail to see the logic. |
39 |
> It's a shame that option is not easily findable. And not knowing it |
40 |
> exists, means checking man-pages and googling for them doesn't happen |
41 |
> either. |
42 |
> |
43 |
>> If you "rc-update del" a service, you wouldn't prevent it from being |
44 |
>> started neither, just because OpenRC is still able to pull it in as a |
45 |
>> dependency. |
46 |
> |
47 |
> True, except with OpenRC, all the config is located together. Not mostly |
48 |
> in / usr/.... somewhere with overrides in /etc/... |
49 |
> I dislike all tools that split their config in this way. |
50 |
> |
51 |
>> So it's actually not an argument for why you'd dislike systemd. ;-) |
52 |
> |
53 |
> The lack of easily findable documentation on how to stop a service from |
54 |
> starting, even as a dependency, is a reason. (not singularly against |
55 |
> systemd). |
56 |
> Systemd, however, has an alternative. |
57 |
|
58 |
Maybe it's a point of how you view and understand the underlying |
59 |
workings. For me, it was quite obvious that "disable" wouldn't stop a |
60 |
unit from starting at all. There's also socket activation, and if a |
61 |
socket can still pull in the unit, systemd actually tells you that it can |
62 |
be pulled in and you need to disable the socket unit, too. |
63 |
|
64 |
After all, systemd is meant to automate most of the stuff, thus units are |
65 |
pulled in by udev or statically enabled units as needed. If you want to |
66 |
disable (and possibly break) some part of functionality, you have to |
67 |
pretend it's not there, thus "mask" it from visibility of the dependency |
68 |
system. That's also well documented in the man pages and blog articles by |
69 |
Lennart - which btw I've read _before_ deploying systemd. |
70 |
|
71 |
I guess the bigger problem here is transitioning from the old, static, |
72 |
non plug-and-play init systems to some new style as systemd provides it. |
73 |
Old thinking no longer applies, you have to relearn from scratch. It's |
74 |
like driving a car from the 70s and then a modern one: The modern one may |
75 |
have extras like breaking assistant, traction control, etc... And when |
76 |
this first kicks in, it may come at a surprise. But hey, it's not that |
77 |
bad and maybe there are even buttons to disable such functionality - at |
78 |
your own risk. |
79 |
|
80 |
But I agree with you that at first glance it is missing some overview: |
81 |
You cannot just look at /etc/systemd to see the full picture. There may |
82 |
be vendor enabled units which you don't see there. But "systemd status |
83 |
unit-file" will tell you. Actually, I like the fact that installing a |
84 |
piece of software also enabled the service I expect to be installed and |
85 |
working then. The problem here is more on the distribution side where |
86 |
dependencies of packages may pull in packages with services you'd never |
87 |
need - just for a small runtime dependency. And I can agree with you that |
88 |
it breaks the principle of least surprise then. But it really should be |
89 |
fixed by the packagers, not by systemd. Systemd is just the messenger |
90 |
here which provides the function of vendor presets. |
91 |
|
92 |
But, yes, if systemd was installed as part of a distribution upgrade, |
93 |
without giving you the chance to read the docs, many things will come at |
94 |
a surprise, and there's an overwhelming lot of changes and different and |
95 |
unexpected behavior. But is that really systemd's fault? |
96 |
|
97 |
|
98 |
-- |
99 |
Regards, |
100 |
Kai |
101 |
|
102 |
Replies to list-only preferred. |