On 26/08/2014 9:36 AM, Vladimir Mosgalin wrote: > Hi Ken Teh! > > On 2014.08.25 at 12:58:21 -0500, Ken Teh wrote next: > >> I read the following article on systemd >> >> http://ifwnewsletters.newsletters.infoworld.com/t/9625863/474699771/826094/14/ >> >> The comments suggested one could still revert to sysvinit. Is this just wishful thinking on my part? > > Yes. As an exercise, why don't you revert EL6's upstart to sysvinit? > Note that enabling/disabling some services on EL6 *requires* you to use > upstart-specific initctl, you simply won't notice these services if you > will only look at chkconfig. > > systemd offers many benefits for system administrators, like: No, no it doesn't. > - simple and predictable service files Like my case of networking randomly failing to start. No debugging or errors logged, and no way of predicting a failure. > - ability to wrap a random application into service with just a few lines of config Yes and no. When you really start using systemd, you learn quickly how to create service files - because you end up writing a lot of them because basic options are missing. If your app doesn't utilise a config file, then you can bet you'll be copying across the default systemd service file and modifying it to suit your needs. There is no other way. > - no more extra-complicated init scripts using various hacks and magic > for non-C applications (if you ever tried to wrap some random python or > java application into service, you'll know what I'm talking about right > away) By complicated you mean working? I start several python daemons on boot with initscripts - and it is very simple - almost trivial. Compare to the guesswork of trying to find out why a service failed to start. > - automatic restart of services This is not always desirable. > - thanks to these features (service created with few lines of code, > automatic restart, some others) - no more need for runit, daemontools or > supervisord , you can have all the benefits of these systems while having > only one flat init system (systemd) for both system and your services > - reliable pid tracking, which even follows the forks - that's something > not current init system or others like runit are able to do. No more > hassle with complex pgrep's for applications that didn't leave pidfile > behind (again, applications that rename or fork themselves and non-C > applications can be extremely annoying here). But systemd has reliable > way of knowing all the pids that each service has created without any > hacks at all - thanks to cgroups support. None of which really works out of the box without you writing your own service file. We have used /var/run for PID files for decades - saying it isn't reliable is .... ignorance? > - ... many more, like various niceties for supporting lightweight > containers with blazing fast startup, where systemd cares about > organizing namespaces and initializing network by itself (not sure these > features are in EL7's systemd, though) None of these really matter in enterprise land. When the servers RAID card takes longer to boot than even the initscripts to run, the benefits are shown for what they are - trivial. > really, for everyone who spent many hours wrapping developers' > applications into services or had to bother with various hacks and > scripts "to let this stupid application daemonize more easily" like > forever, runit, supervisord or misses various features of solaris smf in > linux, systemd is a real bliss. Oh god no. Systemd replaces many things that should not be replaced. Plans are afoot to have systemd replace ntpd and the idea to replace the kernel consoles with userspace systemd foo. Lets also ignore the binary log formats which kills long time monitoring tools (logwatch etc) and systemd really is a solution hunting for a problem. Systemd would have a much better time if it kept its core goal small and focussed. The mess that it has evolved into has included blowing out its scope to just about everything on your system. This is the wrong way to do things. There is no excuse for violating the basic principles of system design and administration for 'wooo it boots faster'. -- Steven Haigh Email: [log in to unmask] Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299