On Thu, 20 Feb 2014 22:28:56 +0800, Thomas Goirand wrote:
> On 02/20/2014 09:02 PM, Tom H wrote:
Thanks for your answer and apologies for the delay in responding but my
$dayjob's been keeping me very busy.
>> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
>> doesn't have?
You're being unfair to sysvinit+sysv-rc+insserv, although I have to
admit that openrc is better and more cleanly designed from a user
perspective because the combination of rc-update, rc-service, and
rc-status is better than using service except to enable/disable a
service where you have to use update-rc.d - and, if you want an output
that's more human-friendly than "insserv -s", you have to install and
use chkconfig.
> Just to name a few:
> - getting rid of the ugly LSB headers
Beauty is in the eye of the beholder. The "Short-Description" and
"Description" LSB fields are useless, but I don't find Debian's LSB
headers and Gentoo's squiggle-delimited stanzas any more beautiful or
uglier than the other. What's important is that they do the job of
allowing their respective rc routines order the startup - and they both
do so.
<rant>As a sysadmin who works with different distributions, I find it
quite frustrating that sysv-rc uses "Required-Start" and Should-Start",
openrc "need" and "use", and systemd "Requires" and "Wants" to mean the
same thing. Although it's not difficult to keep track of what's what,
why should we have to?</rant>
> - cgroup supports to kill processes
IIRC, Patrick Lauer claimed to have written openrc's cgroup support in
one afternoon.
And IIUC that support'll have to rewritten once the kernel's cgroup
maintainer makes the changes that he's announced and non-systemd
sysinits have to use Ubuntu's in-development cgroup manager (since
systemd's cgroup manager's integrated into its pid 1).
> - rc_hotplug (a hotplugged service is one started by a dynamic dev
> manager when a matching hardware device is found).
AIUI openrc simply leverages udev to hotplug devices; but I'm only an
occasional Gentoo user so I might have misundertood the process.
> - Checks if a daemon is really started by start-stop-daemon
> - Dependency loop breaking system
What does this mean? That there are bugs in the dependency headers in
the 1000-odd initscripts in Debian where openrc can work through the
problem and insserv send you to the BTS?
> - Named runlevels (I already talked about that)
I don't see this as a must-have feature. The default runlevels of
sysinit, boot, default, single, reboot, shutdown where "sysinit" groups
the services that are started in single-user mode and "boot" groups the
services that are started by "default" and any user-defined runlevel but
aren't started in single-user mode. However, the only one that you can
switch to by name is "default" (with "rc default"). For the others, you
have to use "init <number>" just like sysv-rc.
In Gentoo, it makes sense to use named runlevels because if you install
rsyslog, for example, you have to run "rc-update add rsyslog default" to
ensure that rsyslog is started at boot. I guess that it makes more sense
that running "rc-update add rsyslog 3" but in Debian, the maintainer
scripts take care of this. If a Debian user wants to create a custom
runlevel, calling it "4" or "thomasg" isn't that big a deal.
There's also a weird relationship between named levels, possibly because
"default" is special-cased. I don't have a Gentoo box at hand to retest
this but I did do this in the past.
When you boot to the "default" runlevel, "who -r" return "3". If you run
"init 5", the runlevel switches to "5" instantaneously, and "rc-status
--all" lists all the same services as "started".
If you boot to the "default" runlevel, rename "/etc/runlevels/default"
to "/etc/runlevels/thomasg", and run "init 5", the runlevel switches to
"5" by shutting down the daemons in "thomasg", and "rc-status --all"
lists the sysinit and boot services as "started" and the thomasg
services as "stopped".
Perhaps you'd have to run "rc thomasg" before "init 5" for the "thomasg"
daemons not to be stopped but it's non-intuitive.
I know that it's a contrived, artificial (mis)manipulation that's
unlikely in a real-world situation but there does seem to be a
disconnect somewhere.
> - Stateful system (see rc-status)
see insserv
> - Dependency caching system (so you wont have to wait for its
> calculation at next boot)
see insserv
> And of course:
> - minimalistic declarative "runscripts", instead of huge init.d scripts.
> A quick example that I wrote myself is available here:
> http://thomas.goirand.fr/blog/?p=147
I've never seen a runscript formatted in this way in Gentoo.
For example, I downloaded the rsyslog initd script:
[~]# cat /root/portage/app-admin/rsyslog/files/7-stable/rsyslog.initd
#!/sbin/runscript
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/app-admin/rsyslog/files/7-stable/rsyslog.initd,v
1.1 2012/11/20 13:03:36 ultrabug Exp $
extra_started_commands="reload"
depend() {
provide logger
}
start() {
ebegin "Starting rsyslogd"
start-stop-daemon \
--start --quiet --exec /usr/sbin/rsyslogd --pidfile
"${PIDFILE}" \
-- ${RSYSLOG_OPTS} -i "${PIDFILE}" -f "${CONFIGFILE}"
eend $?
}
stop() {
ebegin "Stopping rsyslogd"
start-stop-daemon \
--stop --quiet \
--pidfile "${PIDFILE}"
eend $?
}
reload() {
if [ ! -f "${PIDFILE}" ]; then
eerror "rsyslogd not running"
return 1
fi
# Baselayout-1 users still use --stop and --oknodo
local USEROPT="--name rsyslogd"
if [ ! -f /etc/init.d/sysfs ]; then
USEROPT="--stop --oknodo"
fi
ebegin "Re-opening rsyslogd log files"
start-stop-daemon --signal HUP --pidfile "${PIDFILE}" ${USEROPT}
eend $?
}
Is the mini-runscript style as experimental as Petter's 2-line sysv-rc
script?
> You may find more examples inside the source code of openrc (in the
> Debian source package for example), under init.d.misc. Interestingly,
> in it you may see that simple things are very simple, but it's also
> possible to make complex runscripts when needed (yes, the hard
> reality, sometimes means that complex things are needed at boot time).
Thanks. I'll take a look when I have a chance to do so.
> What's coming:
> - monit integration in runscripts (so you can have monit to restart
> crashed services, and send emails when they do). We already have
> patches available for it, so it's taking a good shape.
> - s6 (or equivalent) process monitoring. This is still under
> discussion upstream.
>
> There's some goodies which are more Gentoo oriented, like their
> network integration, but I don't think it's worth mentioning as I
> don't think these features would be useful for Debian, unless someone
> works on adapting them (for example, to read /etc/network/interfaces
> instead of whatever Gentoo uses).
Gentoo split netifrc out of openrc last year so you'd have to maintain
yet another package if you want netifrc in Debian! Anyway, ifupdown and
netifrc are pretty much equivalent.
> Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which
> is IMO important (is there anyone still working on sysv-rc apart from
> a few Debian maintainers? my understanding is: we're alone now...).
Petter and Roger seem to be alive and kicking to me. :)
But the openrc team seems to be much more active.
Finally, there's the issue of parallel boot. Debian has it in squeeze
and wheezy with insserv. Has openrc fixed "rc_parallel"? And if openrc
hasn't fixed it, isn't it a regression vis-a-vis insserv?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530f71a1.90...@gmail.com
