1 |
On Tue, Feb 25, 2014 at 1:42 AM, Yuri K. Shatroff <yks-uno@××××××.ru> wrote: |
2 |
> On 24.02.2014 18:33, Mark David Dumlao wrote: |
3 |
> Sorry but I think I was quite clear: |
4 |
> |
5 |
>>>>> An init daemon generally does one thing well. |
6 |
> Following a "Unix way" design, Everything else should be done by something |
7 |
> else. |
8 |
... |
9 |
>> At least with systemd the parts are cleanly split off into separate |
10 |
>> executables. |
11 |
>> Yes, it's technically not needed for pid 1 to create tempfiles for |
12 |
>> other programs. |
13 |
>> That's why systemd-tmpfiles is its own tiny program, that does one "one |
14 |
>> thing" |
15 |
>> (create tempfiles for other programs) and nothing else. Yes, it's |
16 |
>> technically |
17 |
>> not needed for pid 1 to check your filesystems. That's why systemd-fsck is |
18 |
>> once again, a separate utility, that does "one thing" (run fsck) well. |
19 |
>> Yes, |
20 |
>> it's technically not needed for pid 1 to remount your filesystems |
21 |
>> readwrite. |
22 |
>> Again there's a separate utilty for that, that does nothing but just that. |
23 |
> |
24 |
> |
25 |
> Okay, but can I take them out and substitute mine own easily? How? Is there |
26 |
> a well-defined standard? Is there a well-defined objective, a target at |
27 |
> which the systemd software set will be considered stable 'version 1.0'? I am |
28 |
> asking again, if a bug is found in the systemd infrastructure, is it |
29 |
> possible (i.e. how much effort it would take) to fix it temporarily on a |
30 |
> running system? |
31 |
> |
32 |
|
33 |
It's almost as if you don't bother reading the docs on something, then |
34 |
comment that they're impossible. |
35 |
|
36 |
Yes you can take them out and substitute yours, in fact I just |
37 |
mentioned that I could replace them with plain old init scripts. |
38 |
systemd services are controlled by the same unit files that control |
39 |
other services. |
40 |
|
41 |
|
42 |
>> OpenRC is often spoken of in the same breath as systemd, as if they were |
43 |
>> the same kind of thing. That sounds fair but think about it for a second: |
44 |
> |
45 |
> |
46 |
> Sorry but did I mention OpenRC? |
47 |
> |
48 |
|
49 |
There is a context to this conversation that you appear to be selectively |
50 |
ignoring, wherein openrc, sysvinit, and systemd are being compared, and |
51 |
only one of them is being demonized as anti-Unix. I compared systemd above |
52 |
_both_ to openrc and to sysvinit. The point being ethat systemd is not |
53 |
comparable to _just_ init, but to the whole init ball of wax. |
54 |
|
55 |
> |
56 |
>> openrc - as most people talk about it - isn't even pid 1. as most people |
57 |
>> talk about it, openrc includes the functions.sh, the net.eth0 scripts, |
58 |
>> the script |
59 |
>> for starting your /sys, /proc, mounting local and network filesystems, |
60 |
>> setting |
61 |
>> the hostname and so on. |
62 |
> |
63 |
> |
64 |
> Obviously. That is why OpenRC *can* be treated as a "Unix way" thing, |
65 |
> because the whole bunch are pretty interchangeable, independent and do their |
66 |
> own things well, don't they? |
67 |
> |
68 |
|
69 |
interchangeable: |
70 |
I also pointed out that the systemd parts, like openrc parts, are |
71 |
interchangeable, and do their own things well. I did mention, for example, |
72 |
that I could replace systemd-fsck with an init script. Heck I could disable |
73 |
it entirely if I didn't care about fsck (for instance, in a container). Likewise |
74 |
the mount unit the network units, etc etc can be disabled or replaced |
75 |
if wanted. |
76 |
|
77 |
independent: |
78 |
I do not think independent is an important concept for Unixness, as most of |
79 |
the parts of postfix, dovecot, xorg, qmail, squid, etc are not independent. |
80 |
|
81 |
|
82 |
What you DIDN'T and have not been able to point out is what this one thing |
83 |
that pid 1 is supposed to do. |
84 |
|
85 |
What you also have not been able to demonstrate is that openrc or other |
86 |
init systems' parts follow the same criteria. There's was a long-standing bug, |
87 |
for instance, in that functions.sh has not been separated from openrc. |
88 |
I believe Canek was one of the people pushing to have it done so - to |
89 |
better support systemd - something that violates "independence" and |
90 |
"interchangeability". |
91 |
|
92 |
|
93 |
> Sorry, do you mean *everything* in /etc/ is to be configured? That's a |
94 |
> convention to put the init stuff in /etc/. You could as well put it in /usr, |
95 |
> /boot, wherever. In FreeBSD, the local init stuff resides in /usr/local/etc. |
96 |
> In Solaris, elsewhere. In AIX, elsewhere. Why do you look at everything from |
97 |
> a single linux's angle? Please note, I never say the 'linux way' but the |
98 |
> "Unix way". |
99 |
|
100 |
/etc scripts ARE meant to be configured. At the very minimum, from the |
101 |
perspective of gentoo, they are treated by the conf-update tool as config files. |
102 |
You are expected to copy and customize init scripts for custom or local |
103 |
daemons. |
104 |
|
105 |
> And you might also notice, an init system does not really much depend on the |
106 |
> init daemon. It's pretty possible to run a SysV init daemon on a BSD system, |
107 |
> or the opposite, because all the init daemon does is start some init |
108 |
> scripts. Maybe /etc/rc, maybe /etc/init.d/* ... |
109 |
|
110 |
This is besides the point. Different programs are free to rely on different |
111 |
standards and different features. That openrc can't work or depend on |
112 |
systemd is not systemd's fault, in the same way that not all parts of |
113 |
postfix can work or depend on all parts of qmail. |
114 |
|
115 |
None of this says anything about the unixiness of postfix or qmail, none |
116 |
of this says anything about the unixiness of init or systemd. |
117 |
|
118 |
|
119 |
> No, really. What does systemd *add* what is missing and impossible to do |
120 |
> with OpenRC? |
121 |
> |
122 |
|
123 |
That's really besides the point to me. This issue is supposed to be whether |
124 |
systemd is unix-like or not. 1, you haven't shown how the traditional init |
125 |
follows even your own notions of unixness. 2, you haven't show how systemd |
126 |
fails to follow the same notions of unixness as the traditional init. |
127 |
|
128 |
If you're really looking for one, I pointed out two earlier in this |
129 |
thread. systemd |
130 |
reliably stops services (openrc and sysvinit simply silently fail) and |
131 |
allows you |
132 |
to debug the exact command line in seconds (glance at the unit file) as opposed |
133 |
to minutes (parse the init script). |
134 |
|
135 |
> The init scripts altogether don't do one thing, and I never said this. A |
136 |
> single init script usually does. |
137 |
|
138 |
No seriously, a lot of init scripts - even individually - do not do one thing, |
139 |
nor do they do it well. |
140 |
|
141 |
> Why not always quite well? Because it |
142 |
> depends not only on the script, but on the software itself. Do you claim a |
143 |
> systemd unit file does the thing better than a shell script? No it just |
144 |
> can't, I see many (if not most) of the unit files just issue commands. |
145 |
> The problem of the current SysV init system is that during its history there |
146 |
> was a great number of different people writing different scripts in |
147 |
> different styles as per their understanding of 'well'. But these could |
148 |
> easily be conducted to a standard, actually e.g. FreeBSD has no problem with |
149 |
> init scripts. Neither do I think OpenRC does. |
150 |
|
151 |
init scripts fail because |
152 |
1) they don't do just one thing. |
153 |
for example, they try to create temp files and directories, and don't properly |
154 |
exit / fail when those conditions are broken. there is a common sysad |
155 |
problem where if you accidentally start a service as root you bork any |
156 |
chances of the script starting it. that's acceptable, ok. |
157 |
but worse than that, many init scripts _silently_ fail, because creating |
158 |
files and directories with the right permissions is not really its "one thing". |
159 |
|
160 |
2) they don't properly track process ids, because they rely on pid files rather |
161 |
than tracking all spawned / forked processes. |
162 |
It seems to me that - barring kernel hints - tracking all spawned and forked |
163 |
processes is the job of the process that spawned them and something |
164 |
that it would be in a position to inform the scripts of. in systemd I think |
165 |
pid1 does the spawning, so naturally pid1 does the tracking. It just so |
166 |
happens that it does so using cgroups. |
167 |
|
168 |
So yes, as of right now, in the real world, unit files are better than |
169 |
init scripts, |
170 |
EVEN IF they issue the same commands, simply for breaking and terminating |
171 |
more reliably. |
172 |
|
173 |
> In fact, by chance I'm here a 'sacrifice' because many things you (and other |
174 |
> posters) attributed to me I either didn't say at all or said quite |
175 |
> differently. ('Bloated systemd' is one example; comparing the whole systemd |
176 |
> infrastructure to a single init daemon is another, etc.) |
177 |
> |
178 |
|
179 |
I didn't attribute anything to you you didn't say. It just so happens, though |
180 |
that there is a context to this conversation, which, if you ignore, just |
181 |
tends to perpetuate a lot of confusion. I am responding to questions and |
182 |
points in that context for the benefit of the larger conversation, not |
183 |
just for you. |
184 |
|
185 |
-- |
186 |
This email is: [ ] actionable [ ] fyi [x] social |
187 |
Response needed: [ ] yes [ ] up to you [x] no |
188 |
Time-sensitive: [ ] immediate [ ] soon [x] none |