On 04/15/2013 05:02 AM, Kevin Chadwick wrote:
I have been using Debian for many years now. In all of that time I
have never wanted to "manage" init scripts. I always wonder. What
are people trying to do?
Hi Bob,
For an example of where one will want to "manage" the init scripts,
take a look at the thread in debian-user with subject "Serveur with
encrypted partition : 2 steps boot." started by er...@rail.eu.org .
If you are not using a printer, it is also security 101 to disable it's
listening service.
I quite like OpenRC but am currently looking into file-rc, which I would
prefer if direct changes to it were kept but I will have to find the
time to work out how to do that without using commands like update-rc.d
which are not my preference.
I guess I simply prefer the OpenBSD method of an include file that
would override runlevel.conf and may have to look into adding that to
file-rc or a fork at some point.
I lean more towards systemd as I am a desktop Arch user (I use Debian
Stable on my server.). Warning, I'm not talkign too much ina Debian
context here.
It has a concurrent startup, meaning it brings a system up and down
*very* quickly by starting independent units at the same time. Standard
SysV init generally cannot do this, though it's hard to account for how
initscripts will work, but I've not seen many distributions try and
fashion a fully concurrent init system through init scripts. OpenRC
allegedly also has concurrent startup, but when using it on Gentoo I've
never seen it boot as fast as systemd brings up Arch.
It also has a dependency-based startup. This I've generally seen done in
SysV Init. It's nice in systemd though, since you can more finely define
what kind of dependencies in unit files there are. This allows the
concurrency decide whether to start some units together or sequentially,
and in what order. This allows a daemons that must have networking up to
have networking up and ready before systemd starts them simultaneously.
Combining these two you get daemons started as soon as they can be
started and they'll have the environment they need when they start. This
is done in all init systems more or less, but systemd tries to get
everything going as close to "simultaneously" as it can without breaking
daemons. End result: Fast bootup that isn't broken.
Systemd is easy to administrate, more or less. Unit files are
declarative, not imperative, meaning you merely have to describe the
daemon (In very few terms, no less.) to systemd and systemd will worry
about the "how to run" of the daemon you described. The unit files are
very small and easy to read/understand/alter.
If you need initscripts, systemd can still handle them, it's as simple
as creating a unit file for them. Most systems that use systemd will
have a sysvinit-compatible unit or set of units so that systemd
shouldn't break your distribution should you switch.
"Runlevels" simply exist as a category of unit files called "targets."
It's much easier to set up targets in systemd than having to create
custom runlevel scripts that might end up getting ignored by SysV. It's
very easy to set these up in systemd.
There are bad parts of systemd:
Systemd has "assimilated" udev, in a manner of speaking. Udev can still
run completely without systemd, but for system builders they have to
take a lot of extra steps to seperate udev from systemd and install it.
Worse, some devs of systemd want to fully integrate udev into systemd
and make it so you can't use udev without systemd. This is bad for many
distributions as systemd may not be an option. Debian is an example:
Debian has a couple pet prijects to be ported to things
like HURD and BSD, which do not provide kernel features absolutely
necessary for systemd. Some Gentoo developers have forked udev for this
reason.
Systemd is not simple on a technical level. Whereas SysV is simply a
program that uses simple rules to decide when to execute shell scripts
(Whiich is where the complexity and actual functionality of an init is
found, ultimately.), systemd is a more complex program that uses simple
configuration files to determine how to run everything. This puts a lot
of capabilities on systemd instead of on the daemon.
Related to the above two downsides, systemd is not really a crowning
example of a developer following the UNIX Philosophy of "one simple task
and do it well."
If systemd is not the "official" init system for a distribution, it's a
lot more work setting it up to get it working on par with the system's
chosen init, as distributors will likely not provide *any* unit files
for it. This isn't hard to overcome considering how easy it is to roll a
unit file, but still.
Systemd requires a violation of the Filesystem Hierarchy Standard and
demands one put /run right in / instead of /var/run. This is really a
non-issue and most Linux distributions have wound up gradually moving
away from the FHS in some ways to make life easier on their devs.
Administrators might not like systemd's native logger, which outputs
solely in a binary form, requiring users to use "journalctl" to read
system logs. And you have to run it as root or be part of a special user
group to see the ENTIRETY of the journal. This means you might not be
able to simply run a LiveCD to read logs to see what went wrong with a
system. Fortunately you can use a normal system logger instead.
Some people do *not* like Lennart Poettering, the lead developer, who
also gave us "gems" like PulseAudio, which I still cannot stand to this day.
Even with initscripts support, it's still not like SysV init, so
deploying systemd takes a bit of a learning curve for *nix veterans,
having to unlearn a lot of SysV behavior to understand systemd.
And for Debian: Systemd is not likely to be officially deployed because
of its HURD and kFreeBSD projects, which can't use systemd. However,
nothing can stop normal Debian users from deploying it themselves, they
just might have to work more for it.
Sorry for being wordy.
Conrad
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/516c28ec.9030...@marupa.net
