On Mon, Jul 14, 2014 at 09:50:18PM -0700, Keith Keller wrote:
>
> On 2014-07-15, Jonathan Billings <billings@xxxxxxxxxx> wrote:
> >
> > I've been using systemd ever since it was introduced in Fedora, and
> > the RHEL7 beta and CentOS7 final since it came out. I could tell you
> > about all the positive and negative experiences I've had.
>
> I think this could be very useful, especially coming from someone who
> was initially reluctant (as I and clearly others are).
Ok, I'll give some examples of my experiences. Warning: long post.
As a systems integrator, I'm less concerned with hand-crafted,
artisian init script hackery and more interested in consistency. I
rarely start init scripts by running the init script manually, but
rely on configuration management tools, which expect a uniform
interface. I'm concerned with confining services to use the resource
that are expected, and to make sure that they remain secure.
Prior to the systemd's release, I had created several custom services
to manage the infrastructure and to serve up the apps I supported.
They were all written using RHEL and CentOS-specific syntax. I had
started looking at replacing them with Upstart-specific services
around the time when systemd was announced. Both Upstart and systemd
have simpler configuration syntax, their own commands and better
support of dependency management.
When I started using and writing my own systemd units, I found them
quite simple, the documentation sufficient, and the features quite
useful. Finally getting proper ordering of services, being able to
set mountpoints and network activation (for example) as dependencies
of services, resource management, these all are huge wins for Linux
systems.
For example, cgroups. I had already started using cgroups in el6, and
you get automatic resource management with cgroups with systemd. This
is a hugely positive feature that you don't even realize is possible
until you start using it. This also extends to systemd-logind, so you
can set up "slices" for resource management of users. Possible in el6
using pam_cgroup and cgred, but must better implemented with logind,
since they're automatically created and added to a cgroup. Same for
services.
>From that perspective, now you can really think of a 'service' as a
unit, contained within what you define its resources to have. You can
also have containers that make it possible to even give a service its
own process namespace, with Docker or systemd-nspawn.
>From a purely configuration management perspective, the ability to
just drop simple text files into directories to set up all of these
features makes me happy. For example, instead of needing to modify
/etc/fstab (which I hate doing, since I try to avoid making my CfgMgmt
tool edit files), I can drop an NFS mointpoint definition into a
.mount unit file, which I can then refer to in a .service unit file
that requires the mountpoint.
Puppet, Chef and Bcfg2 (the CfgMgmt tools I've used) all support
systemd, so the hard work has already been done to start using it.
I was not particularly enamored with fancy SysVinit scripting, and
usually prefer as simple and baseline functionality as possible, so I
really see no loss switching to systemd. The fear of systemd being
monolithic actually makes me chuckle, since systemd actually breaks
out many of the functions of the SysVinit rc.sysinit into separate
units, to be managed and modified as needed (such as TTY allocation,
mounting filesystems, managing runlevels, etc.).
So, the things that have bothered me so far:
1.) The order of the 'service SERVICENAME start|stop|status' options
is reversed for 'systemctl start|stop|status SERVICENAME.service'. It
took me a while to get used to that. You can just keep using
'service' and get similar results, though. The output of the
systemctl status is pretty complex too. Also, I keep forgetting to
run 'systemctl status -l SERVICENAME.service' and the long lines are
chopped off until I remember to use -l.
2.) Daemons under systemd don't really need to daemonize anymore. In
the past, to start up a daemon process, you'd need to fork (or
double-fork) and disconnect STDIN, STDOUT and STDERR file
descriptors. This was just accepted knowledge. You don't need to do
that anymore in systemd service units. Heck, write to stdout or
stderr, it'll be recorded in the journal. Check out the
openssh-server service unit, you'll see that sshd is run with -D
there. Systemd supports daemonized services, it's just not necessary
anymore.
3.) Old SysVinit services that did something other than
start/stop/restart/status no longer work. While this was nice for
consistency, it means that porting to systemd will require alternative
methods. This really bugged me at first, but from the perspective of
a systems management person, I can see why it was kind of a hack, and
not consistently implemented.
4.) Debugging. Why is my unit not starting when I can start it from
the command line? Once I figured out journalctl it was a bit easier,
and typically it was SELinux, but no longer being able to just run
'bash -x /etc/rc.d/init.d/foobar' was frustrating. sytemd disables
core dumps on services by default (at least it did on Fedora, the
documentation now says it's on by default. Huh. I should test
that...)
--
Jonathan Billings <billings@xxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
