Gentoo Archives: gentoo-user

From: Michael Mol <mikemol@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?
Date: Tue, 25 Dec 2012 13:16:04
Message-Id: CA+czFiA25=0+90bX3zJFKH-Wb2yGp0yOwKQow5z0qy+u4zE_uQ@mail.gmail.com
In Reply to: Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit? by "Canek Peláez Valdés"
1 On Dec 25, 2012 3:04 AM, "Canek Peláez Valdés" <caneko@×××××.com> wrote:
2 >
3 > On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury <redwolfe@×××××.com>
4 wrote:
5 > [ snip ]
6 > > From what has been happening with the systemd stuff, I do not see what
7 > > advantages it really offers over the SysV scheme and its successors like
8 > > OpenRC. Someone enlighten me please?
9 >
10 > I wrote the following some months ago; I think nothing much has
11 > changed since then (I added a couple of comments):
12 >
13 > Take this with a grain (or a kilo) of salt, since I'm obviously
14 > biased, but IMHO this are systemd advantages over OpenRC:
15 >
16 > * Really fast boot. OpenRC takes at least double the time that systemd
17 > does when booting, easily verifiable. In my laptop systemd is twice as
18 > fast as OpenRC; in my desktop is three times faster. (With a solid
19 > state hard drive, my laptop now boots even faster).
20 >
21 > * Really parallel service startup: OpenRC has never been reliable on
22 > parallel service startup; its documentation says it explicitly. Some
23 > will tell you that for them "it works", but just like the guys who
24 > have a separate /usr and refuse to use an initramfs, they just haven't
25 > been bitten by the inherent problems of it (just ask kernel developer
26 > Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just
27 > broken with parallel service startup.
28 >
29 > * Really simple service unit files: The service unit files are really
30 > small, really simple, really easy to understand/modify. Compare the 9
31 > lines of sshd.service:
32 >
33 > $ cat /etc/systemd/system/sshd.service
34 > [Unit]
35 > Description=SSH Secure Shell Service
36 > After=syslog.target
37 >
38 > [Service]
39 > ExecStart=/usr/sbin/sshd -D
40 >
41 > [Install]
42 > WantedBy=multi-user.target
43 >
44 > with the 84 of /etc/init.d/sshd (80 without comments).
45 >
46 > * Really good documentation: systemd has one of the best
47 > documentations I have ever seen in *any* project. Everything (except
48 > really new, experimental features) is documented, with manual pages
49 > explaining everything. And besides, there are blog posts by Lennart
50 > explaining in a more informal way how to do neat tricks with systemd.
51 >
52 > * Really good in-site customization: The service unit files are
53 > trivially overrided with custom ones for specific installations,
54 > without needing to touch the ones installed by systemd or a program.
55 > With OpenRC, if I modify a /etc/init.d file, chances are I need to
56 > check out my next installation so I can see how the new file differs
57 > from the old one, and adapt the changes to my customized version.
58 >
59 > * All the goodies from Control Groups: You can use kernel cgroups to
60 > monitor/control several properties of your daemons, out of the box,
61 > almost no admin effort involved.
62 >
63 > * It tries to unify Linux behaviour among distros (some can argue that
64 > this is a bad thing): Using systemd, the same
65 > configurations/techniques work the same in every distribution. No more
66 > need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by
67 > different distros.
68 >
69 > * Finally, and what I think is the most fundamental difference between
70 > systemd and almost any other init system: The service unit files in
71 > systemd are *declarative*; you tell the daemon *what* to do, not *how*
72 > to do it. If the service files are shell scripts (like in
73 > OpenRC/SysV), everything can spiral out of control really easily. And
74 > it usually does (again, look at sshd; and that one is actully nicely
75 > written, there are all kind of monsters out there abusing the power
76 > that shell gives you).
77 >
78 > These are the ones off the top of my head; but what I like the most
79 > about systemd is that it just works, and that it makes a lot of sense
80 > (at least to me).
81 >
82 > Most of systemd features can be implemented in OpenRC, although the
83 > speed difference will never be eliminated if OpenRC keeps using shell
84 > files; however, Luca Barbato said that using reentrant busybox the
85 > speed difference is greatly reduced (I haven't confirmed this, since I
86 > haven't even installed OpenRC in months).
87 >
88 > Now, this set of (IMO) advantages of systemd over OpenRC pile up over
89 > the advantages of OpenRC over SysV: the most important one (I believe)
90 > is that OpenRC has dependencies, so a service starts only when another
91 > has already started. AFAIK, SysV has lacked this since always.
92 >
93 > I don't think I have ever heard anyone saying that we should keep
94 > using SysV; like a lot of Unix legacies, it should just die. OpenRC is
95 > much better, but it still uses a Turing-complete language (and a
96 > really slow one) to simply tell services when to start and when to
97 > stop, and it doesn't reliably keep track of what services are really
98 > still running (anyone who has ever used the "zap" command in OpenRC
99 > knows this).
100 >
101 > systemd of course has dependencies, a reliable tracking of service
102 > status (thanks in part to the use of cgroups), and its service files
103 > can't enter in an infinite loop.
104 >
105 > Hope it helps.
106 >
107 > Regards.
108 > --
109 > Canek Peláez Valdés
110 > Posgrado en Ciencia e Ingeniería de la Computación
111 > Universidad Nacional Autónoma de México
112 >
113
114 Thank you. I think that may well be the cleanest set of favorable arguments
115 I've seen for systemd.
116
117 Now, question: could I not create a "/usr" service and make things
118 dependent on /usr come after it's been mounted? That seems the single, core
119 missing piece.

Replies