On Mon, Jul 14, 2014 at 09:50:18PM -0700, Keith Keller wrote: > > On 2014-07-15, Jonathan Billings <billings at negate.org> 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 at negate.org>