<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
It's 0200. Any abrasiveness is completely unintentional. I hope this
comes across as clarifying from somebody who dived in to systemd (on
Fedora), and not some flag-waving "FLOS" zealot.<br>
<br>
Abrasiveness directed toward Canonical's Upstart is slightly
intentional, though :)<br>
<br>
On 07/17/2014 10:45 PM, Khalid Baheyeldin wrote:<br>
<blockquote
cite="mid:CA+TuoW0keCOs-ZDAQJjHajc+3rgCh-aj1zdy1Kr7-eD=1Y12JA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>On Ubuntu so far, upstart is the init system. It generally
stays out of the way. Only one time I needed to deal with it,
because MySQL would not start, and had to find out that it
logged to a different destination (/var/log/upstart). Other
than that, it is transparent.<br>
</div>
</div>
</blockquote>
<br>
Upstart had some serious shortcomings as an init system.<br>
<br>
It's hard to criticize systemd for not being planned (original
article said "FLOS" seemed ad-hoc) and yet consider upstart as an
alternative. It didn't have support for overrides for several
in-the-wild releases, which means you couldn't disable an init
script (or change when it runs) without actually modifying the
script -- and reconciling the changes during upgrades.<br>
<br>
<blockquote
cite="mid:CA+TuoW0keCOs-ZDAQJjHajc+3rgCh-aj1zdy1Kr7-eD=1Y12JA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Systemd is not like that. Wikipedia says that systemd
provides replacements for:<br>
</div>
<div>- SysV Init<br>
</div>
</div>
</blockquote>
<br>
This is a freebie for systemd, since upstart does this, too. That
was the point of the debate: SysV was starting to show it's age,
what do we replace it with.<br>
<br>
This is where the bulk of my experience with systemd lays so far.
I've written several unit files for both personal and work use. Took
me less than an hour to to write my first one, using nothing but man
pages. It's plain text, and about a dozen lines, commented. There's
no boiler-plate, no bash case statements, no environment
contamination. It compartmentalizes, and is capable of killing
mis-behaving services, even their forked, orphaned children.<br>
<br>
It's the sanest method of configuring startup. Instead of
re-inventing a start/stop bash script for every service, you write a
simple config file. Upstart was configured similarly, but handled
things far too simplistically -- It didn't clean the environment, it
allowed services to be started as children of your shell (which
caused significant issues when testing upstart at work).<br>
<br>
<blockquote
cite="mid:CA+TuoW0keCOs-ZDAQJjHajc+3rgCh-aj1zdy1Kr7-eD=1Y12JA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Cron<br>
</div>
</div>
</blockquote>
<br>
Systemd has an understanding of time. Instead of simply "at boot",
you can specify unit files to run seven minutes after boot, or
Sundays at 0700. Now systemd can easily handle the
"/etc/cron.{hourly,daily,...}.d/*" tasks, since it's already got
that functionality. But hey, you can run your crond and disable the
systemd cron units (actually -- you have to run your own crond
anyway, since systemd apparently doesn't handle crontabs yet. I
don't see why it shouldn't eventually).<br>
<br>
- syslog<br>
<br>
This is the weakest point with me, simply due to my lack of exposure
to it. It has a more detail and some extra metadata associated with
each logged line. Some program logs are simply their STDOUT, so you
might not even have timestamps. With systemd's journal, you have
that information if you want it.<br>
<br>
I haven't really leaned enough about the journal because I still
have syslog, and I'm used to it. Although after reading through
dmesg logs last week, I might finally sit down to give journal a
shot. Kernel timer offsets from boot are useless to me when I'm
looking for errors around 03:00.<br>
<br>
<blockquote
cite="mid:CA+TuoW0keCOs-ZDAQJjHajc+3rgCh-aj1zdy1Kr7-eD=1Y12JA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- pm-utils<br>
</div>
<div>- inetd</div>
<div>- acpid<br>
</div>
</div>
</blockquote>
<br>
I can't comment on these.<br>
<br>
<blockquote
cite="mid:CA+TuoW0keCOs-ZDAQJjHajc+3rgCh-aj1zdy1Kr7-eD=1Y12JA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>What I can't get is why Debian, the most community run of
them all, and one of the oldest, has decided to go with
something like systemd. <br>
</div>
</div>
</blockquote>
<br>
I don't understand why community and systemd must be opposed?<br>
<br>
<blockquote
cite="mid:CA+TuoW0keCOs-ZDAQJjHajc+3rgCh-aj1zdy1Kr7-eD=1Y12JA@mail.gmail.com"
type="cite">
<div dir="ltr">The corporate motive is not at play here. But
perhaps the FreeDesktop faction is more powerful than the UNIX
way faction and hence the vote to move to systemd.<br>
</div>
</blockquote>
<br>
It has been for years. The original article mentioned hal and udev.
There also ALSA, which realized that /dev/dsp can only go so far,
and made programs use a library instead of throwing-and-pray bits at
/dev/dsp.<br>
<br>
Interestingly, some folks in the FreeBSD camp have been tossing
around the idea of switching to Apple's launchd. From Wikipedia:<br>
<br>
<blockquote>The launchd daemon essentially replaces:<br>
<br>
init<br>
rc<br>
init.d script<br>
rc.d script<br>
SystemStarter (OS X)<br>
inetd / xinetd<br>
crond / atd<br>
watchdogd<br>
</blockquote>
<br>
If you think that's not Unix-like, I'd like to point out that OS X
is the only actual certified UNIX mentioned so far. :)<br>
<br>
-- <br>
Chris Irwin<br>
</body>
</html>