1 |
On Sat, Mar 17, 2012 at 8:20 PM, Pandu Poluan <pandu@××××××.info> wrote: |
2 |
> |
3 |
> On Mar 18, 2012 8:48 AM, "Canek Peláez Valdés" <caneko@×××××.com> wrote: |
4 |
>> |
5 |
>> On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras <realnc@×××××.com> |
6 |
>> wrote: |
7 |
>> > On 17/03/12 13:53, Alan Mackenzie wrote: |
8 |
>> >> |
9 |
>> >> Hello, Nikos. |
10 |
>> >> |
11 |
>> >> On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: |
12 |
>> >> |
13 |
>> >>>> Happy Computer Users, systemd is on your horizon. |
14 |
>> >> |
15 |
>> >> |
16 |
>> >>> No, we don't. I hope systemd arrives soon. It's the best init system |
17 |
>> >>> I |
18 |
>> >>> ever saw. |
19 |
>> >> |
20 |
>> >> |
21 |
>> >> What's so good about it? What will it do for me? |
22 |
>> >> |
23 |
>> >> I have this horrible sneaking suspicion that it will be more |
24 |
>> >> complicated |
25 |
>> >> than /sbin/init + OpenRC, just like udev + initramfs is more |
26 |
>> >> complicated |
27 |
>> >> than udev, and CUPS is more complicated than classical lpr. |
28 |
>> >> |
29 |
>> >> Why do you find it so good? |
30 |
>> > |
31 |
>> > |
32 |
>> > No idea. I only posted this because the OP didn't say what's bad about |
33 |
>> > systemd :-) I really don't know I should care whether my system runs |
34 |
>> > OpenRC |
35 |
>> > or systemd. |
36 |
>> |
37 |
>> Take this with a grain (or a kilo) of salt, since I'm obviously |
38 |
>> biased, but IMHO this are systemd advantages over OpenRC: |
39 |
>> |
40 |
>> * Really fast boot. OpenRC takes at least double the time that systemd |
41 |
>> does when booting, easily verifiable. In my laptop systemd is twice as |
42 |
>> fast as OpenRC; in my desktop is three times faster. |
43 |
>> |
44 |
>> * Really parallel service startup: OpenRC has never been reliable on |
45 |
>> parallel service startup; its documentation says it explicitly. |
46 |
>> |
47 |
>> * Really simple service unit files: The service unit files are really |
48 |
>> small, really simple, really easy to understand/modify. Compare the 9 |
49 |
>> lines of sshd.service: |
50 |
>> |
51 |
>> $ cat /etc/systemd/system/sshd.service |
52 |
>> [Unit] |
53 |
>> Description=SSH Secure Shell Service |
54 |
>> After=syslog.target |
55 |
>> |
56 |
>> [Service] |
57 |
>> ExecStart=/usr/sbin/sshd -D |
58 |
>> |
59 |
>> [Install] |
60 |
>> WantedBy=multi-user.target |
61 |
>> |
62 |
>> with the 84 of /etc/init.d/sshd (80 without comments). |
63 |
>> |
64 |
>> * Really good documentation: systemd has one of the best |
65 |
>> documentations I have ever seen in *any* project. Everything (except |
66 |
>> really new, experimental features) is documented, with manual pages |
67 |
>> explaining everything. And besides, there are blog posts by Lennart |
68 |
>> explaining in a more informal way how to do neat tricks with systemd. |
69 |
>> |
70 |
>> * Really good in-site customization: The service unit files are |
71 |
>> trivially overrided with custom ones for specific installations, |
72 |
>> without needing to touch the ones installed by systemd or a program. |
73 |
>> With OpenRC, if I modify a /etc/init.d file, chances are I need to |
74 |
>> check out my next installation so I can see how the new file differs |
75 |
>> from the old one, and adapt the changes to my customized version. |
76 |
>> |
77 |
>> * All the goodies from Control Groups: You can use kernel cgroups to |
78 |
>> monitor/control several properties of your daemons, out of the box, |
79 |
>> almost no admin effort involved. |
80 |
>> |
81 |
>> * It tries to unify Linux behaviour among distros (some can argue that |
82 |
>> this is a bad thing): Using systemd, the same |
83 |
>> configurations/techniques work the same in every distribution. No more |
84 |
>> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by |
85 |
>> different distros. |
86 |
>> |
87 |
>> * Finally, and what I think is the most fundamental difference between |
88 |
>> systemd and almost any other init system: The service unit files in |
89 |
>> systemd are *declarative*; you tell the daemon *what* to do, not *how* |
90 |
>> to do it. If the service files are shell scripts (like in |
91 |
>> OpenRC/SysV), everything can spiral out of control really easily. And |
92 |
>> it usually does (again, look at sshd; and that one is actully nicely |
93 |
>> written, there are all kind of monsters out there abusing the power |
94 |
>> that shell gives you). |
95 |
>> |
96 |
>> These are the ones off the top of my head; but what I like the most |
97 |
>> about systemd is that it just works, and that it makes a lot of sense |
98 |
>> (at least to me). |
99 |
>> |
100 |
>> Most of systemd features can be implemented in OpenRC (although the |
101 |
>> speed difference will never be eliminated if OpenRC keeps using shell |
102 |
>> files). My question is: why bother? systemd is already here, it |
103 |
>> already works, and it's actually supported in Gentoo. |
104 |
>> |
105 |
>> But again, remember that I'm biased: I keep an overlay to run Gentoo |
106 |
>> systems with only systemd; no OpenRC, no baselayout, no SysV. You guys |
107 |
>> can try it if you want: |
108 |
>> |
109 |
>> http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ |
110 |
>> |
111 |
>> Usual disclaimer: I take no responsibility if using my overlay results |
112 |
>> in your systems asploding. That said, I'm using it on all my machines |
113 |
>> without a hitch. |
114 |
>> |
115 |
>> Regards. |
116 |
> |
117 |
> Interesting... |
118 |
> |
119 |
> However, what if the service is complex? For example, I created a "gatewall" |
120 |
> service which, upon boot, initializes : |
121 |
> |
122 |
> * Routing tables and the RPDB |
123 |
> * ipset |
124 |
> * iptables |
125 |
> |
126 |
> while ensuring that upon shutdown, the settings of the above are |
127 |
> (optionally) saved. |
128 |
> |
129 |
> How do I specify such intelligence? |
130 |
|
131 |
Well, first of all you have options for starting a service, but also |
132 |
for stopping it. But besides that, please understand that while |
133 |
systemd does not use shell files *itself*, it doesn't stop you from |
134 |
using them if you so desire. In other words, put the "intelligence" on |
135 |
a script: |
136 |
|
137 |
/usr/local/bin/my-really-smart-and-complex-script.sh |
138 |
|
139 |
With proper execution settings (i.e., chmod 755 and with "#!/bin/sh" |
140 |
shebang), and then add a service file that exec's that: |
141 |
|
142 |
# cat /etc/systemd/system/mycomplexscript.service |
143 |
[Unit] |
144 |
Description=My complex script |
145 |
After=basic.target |
146 |
|
147 |
[Service] |
148 |
ExecStart=/usr/local/bin/my-really-smart-and-complex-script.sh |
149 |
|
150 |
Then you only run: |
151 |
|
152 |
# systemctl daemon-reload |
153 |
|
154 |
And you start your script with: |
155 |
|
156 |
# systemctl start mycomplexscript.service |
157 |
|
158 |
If you want to enable it by default, add a link to it in |
159 |
/etc/systemd/system/multi-user.target.wants, or add an install |
160 |
section: |
161 |
|
162 |
[Install] |
163 |
WantedBy=multi-user.target |
164 |
|
165 |
And enable it with systemctl (after daemon-reload again): |
166 |
|
167 |
# systemctl enable mycomplexscript.service |
168 |
|
169 |
systemd doesn't stop you from using scripts. But, if the service is |
170 |
properly designed, it shouldn't be necessary. For example, you could |
171 |
probably break your complex script in small service unit files, and |
172 |
make them depend among each other, so the correct startup sequence is |
173 |
achieved. |
174 |
|
175 |
Check the docs, it's really amazing. |
176 |
|
177 |
Regards. |
178 |
-- |
179 |
Canek Peláez Valdés |
180 |
Posgrado en Ciencia e Ingeniería de la Computación |
181 |
Universidad Nacional Autónoma de México |